Récemment, j'ai rencontré l'exception suivante chez C # Solution:
Erreur 2 Impossible de charger le fichier ou l'assembly 'Newtonsoft.Json, Version = 3.5.0.0, Culture = neutre, PublicKeyToken = b9a188c8922137c6 'ou une de ses dépendances. Le paramètre est incorrect. (Exception de HRESULT: 0x80070057 (E_INVALIDARG))
Cela ne dépend ni de mon code ni du nom de Assembly (comme Newtonsoft.Json
dans ce cas).
Lorsque je supprime cette dll de la solution, le compilateur en dit une autre dans la même exception. Donc je suppose que quelque chose devrait être allumé/éteint sur mon PC :)
On dirait qu'un assemblage corrompu est référencé.
Clarifier les deux:
le dossier\bin de votre projet
le dossier temporaire (devrait être C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Files
dans Windows 7)
et voir si l'erreur se produit encore
Selon que vous utilisez X64, vous devrez peut-être nettoyer quelques emplacements supplémentaires. Nettoyer mon répertoire utilisateur ne suffisait pas.
Cette liste augmentera comme si vous aviez d'autres versions du framework installées.
Je devais effacer
C: /Windows/Microsoft.NET/Framework/v4.0.30319/ Fichiers ASP.NET temporaires
Ce n'est qu'alors que le problème a été résolu.
Pour savoir ce qu'il faut effacer avec certitude, ajoutez la clé de registre suivante:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).
Ensuite, vous verrez la sortie comme ci-dessous. Cela vous indique où asp.net tente de charger vos DLL. Effacer ce répertoire.
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\app\AtlasAdvisor\web\web.config
LOG: Using Host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
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/3c8629f7/dfa387b6/Avanade.ViddlerNet.DLL.**
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet/Avanade.ViddlerNet.DLL**.
Effacez les fichiers de structure temporaires de votre projet dans: -
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Fichiers ASP.NET temporaires \
Vous pouvez également effacer le répertoire des paquets et autoriser NuGet à télécharger à nouveau les paquets manquants.
ça a résolu le problème pour moi
Supprimer tous les fichiers de ces dossiers.
C: /Windows/Microsoft.NET/Framework/v4.0.30319/Tests ASP.NET temporaires C: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Des dossiers
Il suffit de vider ce dossier: (uniquement pour Windows x64)
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires
Obtenir une nouvelle série de fichiers binaires à partir du contrôle de code source a aidé.
Merci
Merci Alex, ton deuxième point m'a aidé à résoudre ce problème.
Il semble que, sauf si vous exécutez visual studio en tant qu'administrateur dans Windows 7, vos fichiers temporaires sont stockés localement plutôt que dans les fichiers C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET.
Voir l'article suivant sur le blog: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx
Je viens de supprimer mes données temporaires d'application de ce chemin
C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files
Résolution de problème
J'ai eu le même problème ici - les solutions ci-dessus ne fonctionnaient pas. Le problème était avec ActionMailer. J'ai exécuté les commandes suivantes de désinstallation et d'installation de nuget
uninstall-package ActionMailer
install-package ActionMailer
Résolu mes problèmes, espérons pouvoir aider quelqu'un d'autre.
Vous pouvez nettoyer, créer ou reconstruire votre application ou simplement supprimer fichiers ASP.NET temporaires dans C:\Utilisateurs\VOTRE NOM D'UTILISATEUR\AppData\Local\Temp.
Cela fonctionne comme par magie. Dans mon cas, je rencontrais un problème de liaison avec l’Assemblée: Impossible de charger le fichier bla bla bla
vous pouvez également voir la solution 2 sous la forme http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St
Je constate que de nombreux techniciens ont posté pour effacer les répertoires temporaires de ASP .Net au moment de l’exécution de chaque framework .Net hébergé sur votre machine, comme dans this answer. Mais je crois que nous devrions connaître la logistique précise pour laquelle nous devons effacer aveuglément tous les répertoires de travail temporaires de tous les frameworks .Net. Selon moi, cela ne devrait pas être le cas.
Mon conseil serait que vous devriez essayer une approche d'épuration d'annuaire pointue pour résoudre ce problème. Comment sauriez-vous quel répertoire effacer?
Manage Application
-> Advanced Settings...
pour ouvrir la fenêtre Advanced Settings
.DefaultAppPool
comme indiqué ci-dessous:Application Pools
dans la barre de navigation de gauche dans IIS. Maintenant, vérifiez quelle version .Net CLR est exécutée par votre pool d'applications. Dans mon cas, il s'agit de la v4.0 comme indiqué ci-dessous:Comme la version CLR hébergée par mon pool d'applications est la v4.0, j'ai donc précisément effacé uniquement les fichiers temporaires du dossier relatif à ASP .NET v4.0 uniquement comme ci-dessous:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Et c'est tout. Mon problème a été résolu.
Leçon apprise: cela indique que tous les fichiers temporaires utilisés par votre site Web ne sont pas dispersés dans plusieurs répertoires, mais qu'ils sont référés en même temps par votre pool d'applications. Donc, vous devez effacer ce dossier spécifique uniquement.
Si vous utilisez les outils de données de SQL Server 2012, qui utilisent le shell VS2010 au 1er mai 2013, vérifiez vos paramètres Configuration Manager. Un nom de serveur modifié de Workflow en xCPWorkflow suffisait pour produire exactement le même Le paramètre est incorrect (exception de HRESULT: 0x80070057 (E_INVALIDARG)) message.
Effacer les fichiers C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET a fonctionné pour moi. Vous envisagez d'automatiser le processus de suppression pour éviter ce problème à l'avenir.
Cela peut arriver lors de la référence aux dll de wrapper COM. Dans votre projet Visual Studio, sous Références, sélectionnez les dll du wrapper COM référencées et assurez-vous qu'elles possèdent les valeurs de propriété suivantes: "Embed Interop Types": False et "Specific Version": False.
Dans mon cas, la modification du numéro de port IISExpress dans les propriétés de mon projet a résolu le problème.
Parfois, vous devez également nettoyer ce dossier: C:\Windows\Temp\Temporary ASP.NET
Dans mon cas, je voulais compiler une DLL visible COM. Le problème était qu'une ancienne version de cette DLL se trouvait ici:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Ainsi, Visual Studio a chargé cette version au lieu de la version nouvellement compilée, car elle a essayé de l’enregistrer.
Effacer tous les fichiers du dossier temporaire (dossier C:\Users\nom_utilisateur\AppData\Local\Temp\Temporary Fichiers ASP.NET\project)
Si quelqu'un d'autre utilise les outils WiX, j'ai découvert que mon projet d'installation faisait référence à un ancien projet récemment supprimé de la solution. Il m’a fallu un certain temps pour comprendre car la solution que j’essayais de construire contenait plusieurs projets et que le message n’indiquait pas quel projet échouait à la construction (et à l’autre, qui échouait également).
Le problème concerne la version d'exécution .Net d'une bibliothèque de classes référencée (références développées, sélectionnez la bibliothèque et vérifiez la "version d'exécution". J'ai eu un problème avec Antlr3.Runtime, après la mise à niveau de mon projet Visual Studio vers la version 4.5. I utilisé NuGet pour désinstaller Microsoft ASP.NET Web Optimization Framework (en raison d'une chaîne de dépendances qui m'a empêché de désinstaller Antlr3 directement)
J'ai ensuite utilisé NuGet pour réinstaller le cadre d'optimisation Web Microsoft ASP.NET. Cela a réinstallé les versions d'exécution correctes.
Des utilisateurs de Siemens Teamcenter 10 Client pour Microsoft Office ont eu la même erreur à propos d'une autre DLL. Aucune des autres réponses n'a fonctionné. La solution consistait à supprimer les dossiers de
C:\Users\%username%\AppData\Local\Assembly\
J'ai rencontré la même erreur parce que l'application n'a pas trouvé de frameworks dépendants dans le dossier C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\
. Je viens de réparer mon studio Visual qui a ajouté la structure requise à l'emplacement ci-dessus et tout fonctionnait bien.
J'ai eu ce problème lors de la fabrication du contrôleur dans MVC. J'ai changé la version .net framework. Le problème a été résolu