DotNetOpenAuth.Asp Ne pourrais pas Charger de l'Assemblée ou de l'un de ses dépendances dans MVC4 Application des Tests Unitaires

Je suis face à de très étrange erreur dans mon projet. J'ai installé DotnetOpenAuth.Aspnet et Microsoft.AspNet.Les pages web.OAuth bibliothèques packages nuget. Quand je lance le projet il n'y a pas de problème. Mais Quand j'écris un test pour les contrôleurs, il est en train de lancer une exception comme suit.

Méthode d'essai MvcApplication2.Les Tests.ControllerTest.should_return_not_empty_content jeté exception:

    System.IO.FileLoadException: Could not load file or assembly 'DotNetOpenAuth.AspNet, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' 
or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Un autre étrange point est que Si je créer un projet dans VS 2010 en tant que MVC3 application et les tests sont de passage. Pas d'échec. Mais Quand je fais exactement la même configuration en VS2012 c'est le tir à la même erreur que ci-dessus.
Lorsque je fais une recherche sur stackoverflow j'ai vu ce solution mais cela n'a pas fonctionné non plus.

Vous pouvez trouver l'ensemble des projets et des tests dans les lignes suivantes. C'est juste un app un projet de test. Très facile à lire.

Aussi j'ai ajouté un exemple de code ici pour contrôleur et de l'échec du test.

Le pastebin lien pour le code de prévisualisation est http://pastebin.com/1PCpq3hW

Toute aide serait appréciée.

Vs2010 et 2012 à défaut et de réussir projets

Un journal détaillé résultat comme suit

 
*** L'Assemblée Liant Entrée De Journal (13.12.2012 @ 22:27:31) *** 

L'opération a échoué. 
Lier résultat: hr = 0x80131040. Aucune description n'est disponible. 

Assemblée manager chargé de: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll 
L'exécution en vertu de l'exécutable C:\Program Files (x86)\JetBrains\ReSharper\v7.0\Bin\JetBrains.ReSharper.TaskRunner.CLR4.exe 
--- Un journal d'erreurs détaillé de la façon suivante. 

=== lier les informations d'état === 
JOURNAL: Utilisateur = DÉVELOPPEUR-PC\DÉVELOPPEUR 
JOURNAL: DisplayName = DotNetOpenAuth.AspNet, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246 
(Complètement spécifié) 
JOURNAL: Appbase = file:///D:/Développement/Coachius/CoachiusWeb.Tests/bin/Debug 
JOURNAL: Initiale PrivatePath = NULL 
JOURNAL: Dynamique de la Base = NULL 
JOURNAL: le Cache de la Base = NULL 
JOURNAL: AppName = NULL 
Appel de l'assemblée : CoachiusWeb, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. 
=== 
JOURNAL: Cette liaison commence en charge par défaut le contexte. 
JOURNAL: l'Utilisation de fichier de configuration d'application: D:\Development\Coachius\CoachiusWeb.Tests\bin\Debug\CoachiusWeb.Tests.dll.config 
JOURNAL: l'Utilisation de fichier de configuration d'hôte: 
JOURNAL: l'Utilisation de la machine fichier de configuration de C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
JOURNAL: Post-politique de référence: DotNetOpenAuth.AspNet, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246 
JOURNAL: GAC de Recherche a été infructueuse. 
JOURNAL: la Tentative de téléchargement de la nouvelle URL file:///D:/Development/Coachius/CoachiusWeb.Tests/bin/Debug/DotNetOpenAuth.AspNet.DLL. 
JOURNAL: Assemblée téléchargement est réussi. De procéder à l'installation de fichier: D:\Development\Coachius\CoachiusWeb.Tests\bin\Debug\DotNetOpenAuth.AspNet.dll 
JOURNAL: Entrant course-de-configuration de la source de phase. 
JOURNAL: Nom de l'Assembly est: DotNetOpenAuth.AspNet, Version=4.1.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246 
WRN: en Comparant le nom de l'assembly a abouti à la discordance: Version Mineure 
ERR: L'assemblée de référence ne correspond pas à l'assemblée de la définition que l'on trouve. 
ERR: course-de-configuration de la source de la phase a échoué avec hr = 0x80131040. 
Erreur: Échec pour terminer l'installation de l'assemblée (hr = 0x80131040). Sondage terminé.
Cross a publié sur ici

OriginalL'auteur gokhanartuk | 2012-12-13

  1. 10

    J'ai résolu avec 

     <configuration>
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
    </configuration>

    OriginalL'auteur IamStalker

  2. 5

    Je pense que j'ai peut-être trouvé une solution possible.

    Voir ce lien

    Les principaux éléments d'information ici sont des lignes 3 et 7. Fondamentalement, Microsoft.Web.Les pages web.OAuth besoins DotNetOpenAuth.Base de 4.0.0.0, mais le DotNetOpenAuth.De base j'ai est la version 4.3.0.0.

    OriginalL'auteur Andy Evans

  3. 1

    Cela est dû à un très vilain bug dans VS 2012. Dans VS 2012 dans les projets de test, de l'assemblée de redirection dans l'app.fichier de configuration ne fonctionne pas.

    Cela explique pourquoi cela fonctionne dans VS 2010 et pas de VS 2012.

    Il est assez ennuyeux.

    Un travail autour de est pour ajouter un .fichier testsettings et de l'associer dans le menu test pour le projet. Vous devez aller à un dossier de solution pour que, sinon vous ne verrez pas dans le menu.

    Attention, beaucoup de ressource sur l'internet dit runsettings avec un forçage ancienne version de travail fera l'affaire, il ne sera pas. Il va se planter votre VS /processus de test. Vous avez besoin d'un fichier testsettings.

    Ce que vous faites, c'est d'utiliser VS2010 coureur, qui n'ont pas ce bug. D'autre part, il est plus lent.

    J'espère que Microsoft corrige cela rapidement, le problème n'est pas seulement avec OpenAuth mais littéralement, avec toutes les DLL à l'aide d'une version différente d'une autre DLL.

    Bienvenue dans l'Enfer des DLL de la version de l'année 2012.

    Si VS 2912 mise à Jour de 1 n'a pas à résoudre ce problème?
    Non, il n'a pas de résoudre. Je ne sais pas quand ils vont l'inclure.

    OriginalL'auteur Sidar Ok

  4. 0

    Recherchez bindingRedirects dans votre site web.le fichier de configuration et assurez-vous qu'ils existent dans votre unité de test de l'application.fichier de configuration.

    Cher André, je l'ai déjà fait ce que vous dites. Mais il n'a pas de travail. Si vous pouviez juste de vérifier les projets que j'ai donné le lien. Vous verrez ce que je veux dire. Et vous verrez aussi bindingredirects de configuration dans les deux fichiers.
    J'ai également modifié par l'ajout de journal détaillé des résultats à obtenir à partir de la fusion des journaux.

    OriginalL'auteur Andrew Arnott

  5. 0

    A ajouter des assemblées de votre projet de test?
    Ils doivent s'affichent dans le dossier lors de la compilation. Puisque votre projet de test est le pays hôte, elle a besoin de la même assemblées pour le test (en fonction de la configuration, mais en règle générale)

    Si oui, alors vous pouvez regarder une nouvelle étape dans le réel détails de liaison.

    Voir mon annonce ici sur l'activation de la fusion de l'exploitation forestière.
    Comment faire pour activer la liaison d'assembly échec d'enregistrement (Fusion).NET

    L'activer, vérifier le dossier et de regarder pour lier les échecs - vous verrez ce que l'assemblée est en train d'essayer de la charger (en général). Si vous n'avez pas d'activer les réussites et les échecs et ensuite regardez toutes les versions de montage. Parfois, vous verrez plusieurs versions chargé qui vous aide à identifier le problème, ou une version inattendue.

    OriginalL'auteur Adam Tuliper - MSFT

  6. 0

    J'ai changé les versions à 4.1.0.0 et il a travaillé pour moi

     <dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780CCD10D57B246" culture="neutral" />
    <bindingRedirect oldVersion="1.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780CCD10D57B246" culture="neutral" />
    <bindingRedirect oldVersion="1.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
  </dependentAssembly>

    OriginalL'auteur Shaun Morehammered Denovan