Infâme erreur de liaison
J'ai vraiment besoin d'aide parce que j'ai perdu tout espoir de corriger le problème.
J'utilise les bibliothèques Office Communications Server 64 bits. Il y a 3 dll que j'utilise dans le projet, Microsoft.Rtc.Collaboration.dll, Microsoft.Rtc.Internal.Media.dll et SIPEPS.dll. Je ne suis pas sûr de Microsoft.Rtc.Collaboration mais Internal.Media et SIPEPS sont tous deux x64. Sur la liste des assemblées du GAC, Rtc.Collaboration affiche MSIL sous Processor Arhitecture et les autres affichent AMD64.
Mon projet compile sans erreur avec ces références, mais au moment de l'exécution, je reçois l'erreur:
Impossible de charger le fichier ou l'assembly 'Microsoft.Rtc.Internal.Media' ou l'une de ses dépendances. Vous avez tenté de charger un programme avec un format incorrect.
J'ai essayé de compiler le projet avec le processeur défini sur Tout, mais rien ne change. Avec les paramètres x64 et x86, je reçois cette erreur.
Toute aide est appréciée.
UPDATE: Vous trouverez ci-dessous le journal de liaison de l’assemblage.
=== Pre-bind state information ===
LOG: User = CONTOSO\elodie
LOG: DisplayName = Microsoft.Rtc.Internal.Media
(Partial)
WRN: Partial binding information was supplied for an Assembly:
WRN: Assembly Name: Microsoft.Rtc.Internal.Media | Domain ID: 9
WRN: A partial bind occurs when only part of the Assembly display name is provided.
WRN: This might result in the binder loading an incorrect Assembly.
WRN: It is recommended to provide a fully specified textual identity for the Assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.Microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/
LOG: Initial PrivatePath = C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\bin
Calling Assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\web.config
LOG: Using Host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based Assembly bind).
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media/Microsoft.Rtc.Internal.Media.DLL.
LOG: Attempting download of new URL file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/bin/Microsoft.Rtc.Internal.Media.DLL.
ERR: Failed to complete setup of Assembly (hr = 0x8007000b). Probing terminated.
A remplacé les versions 64 bits des trois dll par leurs versions 32 bits, nettoyé le dossier des fichiers ASP.NET temporaire et compilé à nouveau. Travaille maintenant sans problèmes. Merci pour l'aide.
J'ai eu ce problème avec ASP.NET IIS et après avoir tout essayé, j'ai activé la version 32 bits pour mon pool d'applications et redémarré les pools d'applications. Ensuite cela a fonctionné.
Dans le gestionnaire IIS7: Pools d'applications -> DefaultAppPool -> Paramètres avancés -> Définissez "Activer les applications 32 bits" sur true.
Assurez-vous également que la bonne version .Net est sélectionnée.
J'ai également défini l'ISAPI 64 bits sur Autorisé sous "Restrictions ISAPI et CGI", mais je ne suis pas sûr que cela ait aidé.
Dans mon cas, j'ai eu ce problème parce que j'exécutais un projet Web compilé pour x64 à l'aide d'IISExpress. J'ai résolu le problème en vérifiant le paramètre suivant dans Visual Studio:
Outils | Options | Projets et solutions | Projets Web | Utilisez la version 64 bits de IIS Express
J'espère que cela aidera quelqu'un d'autre avec le même scénario et le même problème
Essayez de définir Copy Local dans la solution Explorer pour ces assemblys et assurez-vous qu'ils sont déposés dans le dossier spécifié dans le journal de liaison.
En outre, ils ont probablement été construits en utilisant le V2 CLR. Si tel était le cas, vous devrez activer la liaison en mode mixte en l'ajoutant à votre configuration Web/application.
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Je sais que c’est une vieille question, mais cela semble toujours être un résultat populaire lors de la recherche d’une solution concernant une erreur de liaison partielle dans Visual studio. J'avais rencontré un problème très similaire à celui de l'affiche d'origine, mais avec EntityFramework.dll et Visual studio 2015 (projet .ASP Web Forms), toutefois, la solution que j'ai trouvée est liée à un problème général. Étant donné que je n'ai trouvé aucune 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 aidera quelqu'un.
Dans mon web.config, je personnifie un utilisateur de domaine qui est un compte de service. Ce compte de service n'a pas accès à mon dossier de fichiers temporaires. Par conséquent, lors du débogage, il ne peut pas copier les dll, ni les charger.
Ce que nous avons finalement appris, c’était aller chercher physiquement dans le dossier temporaire mentionné dans le message d’erreur. Dans la question initiale ci-dessus, vous remarquerez les lignes "Tentative de téléchargement du nouveau fichier URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files ...". dans ce dossier, mes DLL n'étaient pas là.
La solution pour moi était la suivante: étant donné que j'utilisais un environnement 64 bits et que je personnifiais un compte de domaine, j'ai ajouté l'utilisateur du compte de service de domaine à mon fichier C: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary, ASP.NET. dossier avec accès en écriture (et modification - pour faire bonne mesure).
Ligne inférieure - assurez-vous que votre dossier de fichiers Temp accorde un accès en écriture à l'utilisateur sous lequel votre application est exécutée.
Pour résoudre ce problème, je me suis assuré que tous mes projets utilisaient la même version en exécutant la commande suivante et en vérifiant les résultats:
update-package Newtonsoft.Json -reinstall
Et, enfin, j'ai supprimé les éléments suivants de mon web.config:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
Dans mon cas, j'avais parcouru mon site et remplacé le nom du site par un nouveau nom. J'ai par inadvertance remplacé le 'PreviousWebSiteName' par le 'NewWebSiteName' dans Web.config où le nom d'assembly était 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 toujours en train de construire une assemblée avec l'ancien nom - je voulais seulement changer le nom du site où il apparaissait sur les pages du site; Je n'avais besoin de rien changer en interne. La restauration de l'entrée Web.config telle qu'elle était avant mon changement de nom (résultant en une entrée correspondant au nom de l'assembly généré) a résolu l'erreur pour moi.
J'obtenais l'erreur en essayant d'exécuter l'application Web à partir de Visual Studio, mais dans mon cas, la réponse était simple. Lorsque j'ai lu attentivement l'exception, j'ai pu constater que l'assemblage en question n'était plus utilisé par l'application, mais une copie se trouvait toujours dans le dossier bin. Après le retrait de l’assemblage fautif, l’erreur a disparu.
C'est une vieille question, mais c'était toujours le meilleur résultat quand j'ai eu le même problème aujourd'hui. J'avais basculé la compilation de mon projet dans Visual Studio sur x64 au lieu de "Tous les processeurs" (sur une machine 64 bits). Selon les autres réponses, il y aurait deux façons de résoudre le problème: tout changer en 32 bits ou tout en 64 bits. Dans ce cas, j'avais besoin de 64 bits.
La réponse de KabanaSoft a parfaitement fonctionné pour moi. Toujours correct à partir de Visual Studio 15.6.6.
Dans mon cas, j'avais des conneries dans mon web.config, en particulier un httpHandler à moitié commenté, qu'une fois que j'ai nettoyé tout cela, mon problème de liaison a disparu.