Infâme de l'assemblée de liaison d'erreur

Dans mon cas, j'ai eu ce problème parce que j'ai été l'exécution d'un projet web compilé pour x64 à l'aide de IISExpress. J'ai résolu le problème en vérifiant les paramètres suivants dans Visual Studio:

Outils | Options | Projets et Solutions | Projets Web | Utiliser la version 64 bits de IIS Express

Espère que cela aide quelqu'un d'autre avec le même scénario et la question

Essayez de régler une Copie Locale dans l'explorateur de solutions pour les assemblages et assurez-vous qu'ils sont en train d'être supprimé dans le dossier spécifié dans le journal de liaison.

Aussi, ils ont probablement été construit à l'aide de la V2 CLR. Si elles l'étaient, vous devrez activer le Mode Mixte de liaison en ajoutant ceci à votre web/app config

<configuration>
   <startup  useLegacyV2RuntimeActivationPolicy="true">
       <supportedRuntime version="v4.0"/>
  </startup>
</configuration> 

Je sais que c'est une vieille question, mais semble toujours être un populaire résultat lors de la recherche d'une solution pour une partielle de liaison erreur dans Visual studio. J'ai vécu très similaire à l'original de l'affiche, mais avec le EntityFramework.dll et Visual studio 2015 (.Web ASP projet de Formulaires), cependant, la solution que j'ai trouvé concerne un vaste problème. Puisque je n'ai pas trouver de réponse similaire à ma solution, j'ai pensé qu'il pourrait être utile de contribuer ce que j'ai trouvé, et j'espère que cela aide quelqu'un.

Dans mon web.config je suis usurper l'identité d'un utilisateur de domaine qui est un compte de service. Ce compte de service n'ont pas accès à mon dossier de fichiers Temporaires, donc lors du débogage, il n'a pas pu copier la dll, et ne pouvait donc pas se charger.

Ce que finalement, à bout nous a été d'aller et physiquement, la recherche dans le dossier temporaire mentionné dans le message d'erreur. Dans la question d'origine ci-dessus, vous remarquerez que les lignes de "Tentative de téléchargement de la nouvelle URL de type file:///C:/Windows/Microsoft.NET/Cadre/v4.0.30319/Temporaire ASP.NET les Fichiers..." Quand j'ai regardé dans le dossier mes fichiers Dll ne sont pas là.

La solution pour moi a été ceci: Puisque j'étais en utilisant l'environnement 64 bits, et d'usurper l'identité d'un compte de domaine, j'ai ajouté le compte de service de domaine de l'utilisateur à mon local C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET dossier de Fichiers avec l'écriture (et de modifier - pour faire bonne mesure) d'accès.

Bas de ligne - assurez-vous que vos fichiers temporaires dossier de subventions de l'accès en écriture à l'utilisateur de votre application s'exécute.

Dans mon cas, j'étais passé par mon site et a remplacé le nom du site avec un nouveau nom. Par hasard, j'ai remplacé le "PreviousWebSiteName avec le NewWebSiteName' dans le Web.config où le nom de l'assembly a été spécifié.

    <pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID">
  <controls>
    <add assembly="NewWebSiteName" namespace="App_Code.Controls" tagPrefix="blog" />
  </controls>
</pages>

Le site était encore la construction d'un assemblage avec l'ancien nom - je ne vise qu'à modifier le nom du site où il a été figurant sur les pages du site; je n'ai pas besoin de changer quoi que ce soit à l'interne. La restauration du Web.entrée config comme il était avant mon changement de dénomination (résultant en une entrée qui correspond au nom de l'assembly intégré) résolu l'erreur pour moi.

Dans mon cas, j'ai eu un peu de la merde dans mon web.config, en particulier une demi-commenté httpHandler qu'une fois que j'ai nettoyé tout ça, ma liaison problème a disparu.