VSTS 2010 SGEN : erreur : impossible de charger le fichier ou l'assembly (Exception de HRESULT: 0x80131515)
Je suis confronté à un étrange problème avec VS2010. Nous utilisons TFS pour construire notre API dll et nous avons utilisé pour faire référence à eux dans nos projets avec un lecteur réseau mappé qui a été entièrement confiance. Nous avons travaillé comme ça pendant au moins deux ans, et tout a fonctionné parfaitement.
Aujourd'hui, j'ai converti une webapp pour vs2010 et quand je compile en Release, c'est de me donner:
SGEN : erreur : impossible de charger le fichier ou l'
assemblée 'file:///L:\Api\Release
API_20100521.1\Release\CS.API.Exceptions.dll " ou une de ses dépendances. L'opération
n'est pas pris en charge. (Exception de
HRESULT: 0x80131515)
La chose étrange est que cela fonctionne quand elle est sous le Débogage de profil...
J'ai essayé d'ajouter le
<runtime>
<loadFromRemoteSources enabled="true" />
</runtime>
dans l'app.config et toujours pas de chance (Voir http://social.msdn.microsoft.com/Forums/en/msbuild/thread/d12f6301-85bf-4b9e-8e34-a06398a60df0 et http://msdn.microsoft.com/en-us/library/dd409252(SV.100).aspx)
Je suis assez certain que cette question est à partir de visual studio ou msbuild, que notre code ne sera pas exécuté à partir d'un partage réseau lorsqu'en prod, parce que tous les référencée dll sont copiés dans le dossier bin.
Si quelqu'un a une solution (ou juste une idée pour un chemin de recherche) s'il vous plaît laissez-moi savoir !
Edit : Il s'avère que c'est en travaillant en mode Debug, parce que la génération de la sérialisation des assemblées a été Désactivée. Comme le titre le dis, c'est vraiment un SGEN problème puisque c'est cet utilitaire qui dit que le chemin n'est pas digne de confiance...
Vous devez vous connecter pour publier un commentaire.
J'ai été en mesure de corriger cette erreur en trouvant l'assemblée DLL dans l'Explorateur Windows, clic droit, sélectionnez Propriétés, puis en appuyant sur le bouton "débloquer". La DLL a un flux qui est marquant dans un fichier externe et en cliquant sur le débloquer vous supprimez cette désignation.
dir -Recurse | Unblock-File
J'ai juste eu le même problème sur un serveur de build TFS où une accumulation faisait référence à la dll à partir d'un partage réseau.
Le problèmes est que le CLR v4 modèle de politique de sécurité a changé depuis les versions précédentes et ne sont pas "bac à sable" assemblées comme avant.
Pour résoudre votre problème il suffit de trouver l'emplacement de sgen.exe et créer un sgen.exe.config dans le même dossier avec le contenu suivant:
sgen.exe est généralement à
Vous pouvez lire sur certains des changements autour de CAS politiques .NET 4.0 dans ce billet de blog: Lien
Eu le même problème et la configuration de changement n'a pas fonctionné. Seulement lorsque j'ai mis Générer l'Assembly de Sérialisation à off dans les propriétés du projet fait le travail.
J'ai eu le même message d'erreur et trouvé ma DLL a été "bloqué". Ouvrir le fichier DLL dans l'explorateur, clic droit -> propriétés -> appuyez sur "Débloqué".
http://cantgrokwontgrok.blogspot.com/2009/10/visual-studio-unknown-build-error.html
J'ai eu exactement ce même problème et résolu par l'ajout du sgen.exe.la config dans C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Outils
avec cette simple config comme d'autres l'ont dit
Pour ceux d'entre vous exécutez une version 64 bits de la TSF service de build, j'ai dû créer le fichier de configuration dans le chemin d'accès suivant:
Et le contenu de fichier:
J'ai eu le même problème, chargé de l'assembly dans le GAC et travaillé
L'ajout de l'extrait de code ci-dessous pour l'application.fichier de configuration a fonctionné dans mon cas. Je suis sous Windows XP, avec VS2010 service pack 1.
Comme un FYI si vous exécutez Windows 7 sgen.exe le fichier peut être trouvé à:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Outils
J'ai dû créer un sgen.exe.config et le placer là et puis, ce problème a disparu.
Ni le
unblock
ni laconfig
a fonctionné pour moi.Ce qui a fait le tour pour moi a été cette astuce sur
caspol
.J'ai couru
Et j'étais prêt à aller, pas même un VisualStudio redémarrage nécessaire.
J'ai eu un problème similaire et j'ai enfin eu le dessus en supprimant leurs licences.licx fichier dans le dossier des Propriétés de la solution.
Juste au cas où, comme moi, Débloquer n'était pas une solution, comme le Débloquer n'apparaît pas sur mon fichier dll propriétés. Conservé à la recherche et ont fini par fermer mon fichier de solution et de la ré-ouverture à l'aide de la local C: copier à la place de réseau de chemin d'accès UNC du projet de la sln fichier. A été en mesure de publier après d'aller dans cette voie.