Impossible de charger le fichier ou l'assembly 'Système, Version = 4.0.0.0, Culture = neutre, PublicKeyToken = b77a5c561934e089' ou l'une de ses dépendances
J'ai cette exception générée sur certaines machines utilisateur (~ 1 sur 20):
Impossible de charger le fichier ou le système d'assemblage, version = 4.0.0.0, Culture = neutre, PublicKeyToken = b77a5c561934e089 'ou l'un de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
J'ai trouvé plusieurs références à cette erreur sur le Web et sur ce site, mais rien n'y fait.
J'ai une application complémentaire qui utilise WCF pour se connecter au serveur. Le complément construit avec .NET Framework 3.5 avec VS 2008.
L'erreur est reproductible sur l'une des machines de test dans un seul compte utilisateur. J'installe mon application et je ne peux reproduire cela qu'à partir d'un compte sur cette machine partout où cela fonctionne correctement. De plus, il n'est reproductible qu'avec une seule version de l'application hôte pour laquelle j'ai créé un complément (je suppose parce qu'il utilise differnet .NET Frameworks).
J'ai vérifié les journaux de fusible et je vois ce qui suit:
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
Running under executable C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = Home\User
LOG: DisplayName = System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
(Fully-specified)
LOG: Appbase = file:///C:/Program Files/SolidWorks Corp/SolidWorks/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling Assembly : System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Donc, pour certaines raisons, il essaie d’utiliser le chargeur v2.0.50727\mscorwks.dll pour charger la version = 4.0.0.0 de System.dll. Sur la machine de construction, je me réfère à la version 2.0.0.0 de System.dll
Toute aide est très appréciée.
Merci, Artem
J'ai eu ce même problème - certains utilisateurs pouvaient tirer de git et tout fonctionnait bien. Certains tireraient et obtiendraient une exception très similaire:
Impossible de charger le fichier ou l'assembly '..., Version = ..., Culture = neutre, PublicKeyToken = ...' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Dans mon cas particulier, c'était AjaxMin, donc l'erreur réelle ressemblait à ceci, mais les détails importent peu:
Impossible de charger le fichier ou l'assembly 'AjaxMin, Version = 4.95.4924.12383, Culture = neutre, PublicKeyToken = 21ef50ce11b5d80f' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Cela s'est avéré être le résultat des actions suivantes sur une solution:
La restauration de paquet NuGet a été activée pour la solution.
Un projet a été ajouté et un paquet Nuget y a été installé (AjaxMin dans ce cas).
Le projet a été déplacé dans un autre dossier de la solution.
Le paquet Nuget a été mis à jour vers une version plus récente.
Et lentement mais sûrement, ce bug a commencé à apparaître pour certains utilisateurs.
La raison en était que les packages/respositories.config au niveau solution conservaient l'ancienne référence de projet et contenaient maintenant une nouvelle deuxième entrée pour le projet déplacé. En d'autres termes, il y avait ceci avant le reorg:
<repository path="..\Old\packages.config" />
Et ceci après le reorg:
<repository path="..\Old\packages.config" />
<repository path="..\New\packages.config" />
Ainsi, la première ligne fait maintenant référence à un projet qui, bien que sur disque, ne fasse plus partie de ma solution .
Lorsque Nuget Package Restore est activé, les deux fichiers packages.config sont en cours de lecture. Chacun indique leur propre liste de packages Nuget et leurs versions. Jusqu'à ce qu'un paquet Nuget soit mis à jour vers une version plus récente, il n'y avait pas de conflit.
Cependant, une fois qu'un paquet Nuget a été mis à jour, seuls les projets actifs ont eu la liste de leurs référentiels mis à jour. NuGet Package Restore a choisi de ne télécharger qu'une seule version de la bibliothèque, la première rencontrée dans repositories.config, la plus ancienne. Le compilateur et IDE ont procédé comme s'ils avaient choisi le plus récent. Le résultat était une exception d'exécution indiquant que la balise DLL était manquante.
La réponse est évidemment de supprimer toutes les lignes de ce fichier qui ont référencé des projets qui ne figurent pas dans votre solution.
Je l’ai obtenu après avoir déclassé un projet de .net 4.5 à .net 3.5.
Pour résoudre ce problème, je devais accéder au projet - Propriétés - Fenêtre Paramètres et supprimer tous mes paramètres, enregistrer le projet, quitter et redémarrer Visual Studio, revenir à la fenêtre Projet - Propriétés-Paramètres et saisir à nouveau tous mes paramètres et leurs valeurs par défaut. valeurs
Vous utilisez .net 4? - Peut-être que sur les clients, seul le "profil client .net Framework 4" est installé. Essayez d'installer le package complet !! Téléchargez-le ici
Cela a fonctionné pour moi . Allez à Projet-> Propriétés-> Cadre cible-> Changer de cadre comme 3.5 à 4.0
J'ai répondu trop tard, mais cela a fonctionné dans mon cas. Si vous rencontrez ce problème dans votre projet, veuillez ajouter la ligne suivante dans votre fichier web.config:
<compilation batch="false" >
Cela a fonctionné dans mon cas. Si vous avez déjà une balise de compilation dans votre web.config, ajoutez-y seulement la propriété batch = "false".
Même si j'ai l'expérience de choses plus étranges, je peux voir qu'il n'y a pas de dll dans le GAC d'où la dll est chargée, mais Windows> Le module indique que la version de system.dll = 4.0.0.0 chargée
J'ai eu le problème sous Linux et j'avais besoin de les installer. Je ne sais pas lequel a réellement résolu le problème, mais cette erreur a disparu après cela:
apt-get install mono-utils mono-runtime-sgen mono-runtime-common \
mono-runtime-boehm mono-runtime-dbg mono-xbuild
Vous pouvez activer les packages NuGet et mettre à jour vos dll. afin que cela fonctionne .. ou vous pouvez mettre à jour le paquet manuellement en passant par le gestionnaire de paquets dans votre vs si vous savez quelle version vous avez besoin pour votre solution.
Je l'ai déjà vu plusieurs fois, et le problème est généralement résolu en exécutant une réparation sur .NET Framework (quelle que soit la version utilisée par l'application).
Dans mon cas, j'ai pu trouver un problème avec ScriptManager en définissant Debug = true dans le fichier web.config.