ASP.NET MVC versucht zu laden ältere version von Owin Montage

Als Kontext entwickle ich eine ASP.NET MVC 5-Anwendung, die OAuth-basierte Authentifizierung über Microsofts OWIN-Implementierung, für Facebook und Google nur in diesem Stadium. Derzeit (Stand v3.0.0, git-commit 4932c2f), die FacebookAuthenticationOptions und GoogleOAuth2AuthenticationOptions bieten keine Eigenschaft zu erzwingen, Facebook noch Google bzw. die Authentifizierung der Benutzer (über das Anhängen der entsprechenden query-string-Parameter) wenn Sie sich anmelden.

Zunächst, die ich überschreiben Sie die folgenden Klassen:

  • FacebookAuthenticationOptions
  • GoogleOAuth2AuthenticationOptions
  • FacebookAuthenticationHandler (speziell AuthenticateCoreAsync())
  • GoogleOAuth2AuthenticationHandler (speziell AuthenticateCoreAsync())

entdeckt, dass die ~AuthenticationHandler Klassen gekennzeichnet sind, als internal.

Also zog ich eine Kopie der Quelle für das Katana-Projekt (http://katanaproject.codeplex.com/) und modifiziert die Quelle entsprechend.

Nach dem kompilieren habe ich gefunden, dass es mehrere Abhängigkeiten, die aktualisiert werden müssten, damit diese aktualisiert Baugruppen (Microsoft.Owin.Sicherheit.Facebook und Microsoft.Owin.Sicherheit.Google) im MVC-Projekt:

  • Microsoft.Owin
  • Microsoft.Owin.Sicherheit
  • Microsoft.Owin.Sicherheit.Cookies
  • Microsoft.Owin.Sicherheit.OAuth
  • Microsoft.Owin.Host.SystemWeb

Wurde dies durch den Ersatz der bestehenden Projekt-Verweise auf die Versionen 3.0.0 und aktualisieren im web.config. Gute Nachrichten: das Projekt erfolgreich kompiliert.

Debuggen, erhielt ich eine Ausnahme beim Start:

Eine Ausnahme des Typs " System.IO.FileLoadException " ist in [MVC-web-assembly].die dll wurde aber nicht behandelt werden, in Benutzer-code

Zusätzliche Informationen: Konnte nicht geladen, Datei oder assembly 'Microsoft.Owin.Security, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' oder eine Ihrer Abhängigkeiten. Die befindet assembly manifest definition entspricht nicht den Assemblyverweis. (Ausnahme von HRESULT: 0x80131040)

Die zugrunde liegende Ausnahme angegeben, dass Microsoft.AspNet.Identität.Owin wurde versucht zu laden v2.1.0 von Microsoft.Owin.Sicherheit beim Aufruf app.UseExternalSignInCookie() aus Startup.ConfigureAuth(IAppBuilder app) im Autostart.Auth.cs.

Leider, dass die Montage (und die andere Abhängigkeit, Microsoft.AspNet.Identität.Owin) sind nicht Teil des Projekts Katana Lösung, und ich kann nicht finden, alle zugängliches repository für diese Baugruppen online.

Sind die Microsoft.AspNet.Identität Baugruppen open-source, wie das Katana-Projekt?
Gibt es eine Möglichkeit, zu täuschen, die Assemblys zu verwenden, auf die verwiesen wird v3.0.0 Baugruppen anstelle von v2.1.0? Die /bin Ordner enthält die 3.0.0 Versionen der Owin-Baugruppen.

Habe ich aktualisiert die NuGet-Pakete für Microsoft.AspNet.Identität.Owin, und dies ist immer noch ein Problem.

Irgendwelche Ideen auf, wie dieses Problem zu beheben?

  • Klingt wie Sie müssen möglicherweise ein assembly binding redirect. Werfen Sie einen Blick auf diese als Leitfaden: rionscode.wordpress.com/tag/...
  • Danke, das habe ich gelesen und festgestellt, dass die Bindung leitet er spricht über die änderungen, die ich im web.config: <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> habe ich überprüft und verifiziert, dass die referenzierten Assemblys sind in der Tat 3.0.0.0, aber das Problem ist immer noch vorhanden.
  • hast du festlegen der assembly-Namen in Ihrer Bindung umleiten? Sie benötigen eine bindungsumleitung für jedes Paket, das Sie umgeleitet werden sollen, die richtige version. Auch hast du eigentlich aktualisieren Sie Ihre Verweise in Ihrem Projekt oder ersetzen Sie einfach die .dlls in deinem bin-Ordner?
  • Ja - es gibt zwei verbindliche leitet sich wie folgt: <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> ich auch sicher, dass das Projekt Referenzen wurden entsprechend aktualisiert.
InformationsquelleAutor d_mcg | 2014-06-06
  1. 10

    Ich aktualisiert, um OWin 3.0.1 und, dass das problem behoben:

    Tools -> NuGet-Paket-Manager -> Manage NuGet Pakete für Projektmappe

    Suchte ich für die Verweise in der Liste (unter NuGet.org) und installiert neue Referenzen für Microsoft.Owin sowie Microsoft.Owin.Security, Microsoft.Owin.Sicherheit.Google, Microsoft.Owin.Sicherheit.Facebook etc.

    Dann habe ich mir die version Nummer in meiner Pakete.config und Web.Config-Datei und festgestellt, dass diese aktualisiert hatte, richtig:

    Pakete.config Beispiel:

    <package id="Microsoft.Owin.Security.Google" version="3.0.1" TargetFramework="net45" />

    Web.Config Beispiel:

    <assemblyIdentity name="Microsoft.Owin.Security" culture="neutral" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
    InformationsquelleAutor Dave Hatt
  2. 0

    Habe ich gefunden, dass, während FacebookAuthenticationHandler markiert ist, als internal, seiner abstrakten Basis-Klasse AuthenticationHandler<TOptions> ist zum Glück public. Am Ende nahm ich die modifizierte version von FacebookAuthenticationHandler aus dem Katana-Projekt Quelle, umbenannt und einbezogen in meine eigene Lösung, so dass es verwendet immer noch die 2.1 Bibliotheken und verursacht keine Probleme mit den anderen NuGet-Abhängigkeiten.

    Ebenfalls für GoogleOAuth2AuthenticationHandler.

    So, mit dem Facebook Beispiel habe ich die folgenden Klassendefinitionen in meinem MVC-Projekt:

    //Overridden to add additional property 'ForceReauthentication'
public class FacebookOAuth2ExtendedOptions : FacebookAuthenticationOptions
...

//Reimplemented v2.1 source with modified method 'ApplyResponseChallengeAsync'
public class FacebookOAuth2CustomHandler : AuthenticationHandler<FacebookOAuth2ExtendedOptions>
...

//Reimplemented v2.1 source, modified to use 'FacebookOAuth2CustomHandler '
public class FacebookOAuth2CustomMiddleware : AuthenticationMiddleware<FacebookOAuth2ExtendedOptions>
...

    Schließlich in der Startup Klasse (App_Start/Startup.Auth.cs), melde ich die Authentifizierung mit meinem custom-middleware-Klassen:

    public void ConfigureAuth(IAppBuilder app)
{
    ...

    var fbOptions = new FacebookOAuth2ExtendedOptions()
    {
        AppId = facebookAppKey,
        AppSecret = facebookAppSecret,
        ForceReauthentication = true
    };
    app.Use(typeof(FacebookOAuth2CustomMiddleware), app, fbOptions);

    ...
}

    Hoffe, dies hilft anderen mit ähnlichen Problemen.

    InformationsquelleAutor d_mcg
Schreibe einen Kommentar