Не удалось загрузить файл или сборку ... параметр задан неверно

недавно я встретил следующее исключение в решении C#:

Ошибка 2 не удалось загрузить файл или сборку " Newtonsoft.формат JSON, Версия=3.5.0.0, культура=нейтральная, PublicKeyToken=b9a188c8922137c6 ' или одна из его зависимостей. Неверный параметр. (Исключение из Значение HRESULT: 0x80070057 (значение e_invalidarg))

Это не зависит ни от моего кода, ни от имени сборки (например,Newtonsoft.Json в данном случае).

когда я удаляю эту dll из решения компилятор сообщает о другом в том же исключении. Поэтому я предполагаю, что что-то должно быть выключено/включено на моем ПК :)

26 ответов


выглядит как поврежденная сборка, на которую ссылаются.

снимите как:

  1. папка \bin вашего проекта

  2. папка temp (должна быть C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Files в windows 7)

и посмотреть, если ошибка все еще происходит


в зависимости от того, используете ли вы X64, вам может потребоваться очистить еще пару мест. Просто очистки моего каталога пользователей было недостаточно.

  1. %TEMP%\Temporary ASP.NET файлы
  2. C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET файлы
  3. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET файлы
  4. C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Файлы
  5. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET файлы

этот список будет расти, как если бы у вас были установлены другие версии фреймворка.


для

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET файлы

только тогда проблема была решена.


чтобы знать, что очистить наверняка-добавьте следующий раздел реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).

тогда вы увидите результат ниже. Это говорит вам, где asp.net пытается загрузить ваши DLL. Очистите этот каталог.

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**.

очистите временные файлы фреймворка для вашего проекта в: -

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET файлы\


вы также можете очистить каталог пакетов и разрешить NuGet для для повторной загрузки недостающих пакетов

это решило проблему для меня


удалить все файлы из этих папок .

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET файлы ASP.NET C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary Файлы


получение свежего набора двоичных файлов из системы управления версиями помогло.

спасибо


просто очистите эту папку: (только Windows x64)

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET файлы


спасибо Алекс ваш второй пункт помог мне исправить это.

похоже, что если вы не запускаете visual studio в качестве администратора в Windows 7, он хранит ваши временные файлы локально, а не C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET файлы.

см. следующее сообщение в блоге: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx


У меня была та же проблема здесь - выше решения не работали. Проблема была с ActionMailer. Я запустил следующую команду удаления и установки nuget

uninstall-package ActionMailer
install-package ActionMailer

решил мои проблемы, надеюсь, поможет кому-то еще.


Я просто удаляю временные данные приложения из этого пути

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

очистка C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET файлы работали на меня. Думая об автоматизации процесса удаления, чтобы избежать этой проблемы в будущем.


Если вы используете SQL Server 2012 Data Tools, который использует оболочку VS2010 по состоянию на 1 мая 2013 года, проверьте параметры Configuration Manager. Изменение имени сервера из рабочего процесса в xCPWorkflow было достаточно, чтобы произвести то же самое параметр неверен (исключение из HRESULT: 0x80070057 (E_INVALIDARG)) сообщение.


Это может произойти при ссылке на библиотеки DLL-оболочки COM. В проекте Visual Studio в разделе Ссылки выберите библиотеки DLL-оболочек COM и убедитесь, что они имеют следующие значения свойств: "внедрить типы взаимодействия": False и "конкретная версия": False.


вы можете либо очистить, построить или перестроить приложение или просто удалить временный ASP.NET файлы at C:\Users\YOUR имя пользователя\AppData\Local\Temp

Это работает как волшебство. В моем случае у меня была проблема с привязкой сборки, говорящая не удалось загрузить файл bla bla bla

вы также можете увидеть решение 2 как http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St


Я вижу, что многие технари опубликовали об очистке временных каталогов ASP .Net run-time, относящихся к каждой .Net framework, размещенной на вашем компьютере, как в этой ответ. Но я считаю, что мы должны знать четкую логистику о том, почему нам нужно слепо очистить все временные рабочие каталоги всех .NET-фреймворков. По-моему, так не должно быть.

Я бы посоветовал, что вы должны попробовать точечный поляне подход каталог устранение этой проблемы. Как вы узнаете, какой каталог очистить?

  1. перейдите в IIS и щелкните правой кнопкой мыши на узле веб-сайта в левой навигационной панели, чтобы открыть контекстное меню. В контекстном меню укажите Manage Application ->Advanced Settings... открыть Advanced Settings окно.
  2. Проверьте пул приложений, на который назначен ваш сайт. В моем случае это DefaultAppPool как показано ниже:

enter image description here

  1. теперь переходим к Application Pools узел в левой панель навигации в IIS. Теперь проверьте, какая версия .Net CLR запускается пулом приложений. В моем случае это v4.0 как показано ниже:

enter image description here

поскольку версия CLR, размещаемая в моем пуле приложений, - v4.0, поэтому я prcisely очистил только временные файлы в папке, относящейся к ASP .NET v4.0 только как показано ниже:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

и это все. Моя проблема решена.

выучил урок: это указывает на то, что все временные файлы, используемые вашим сайтом, не разбросаны по нескольким каталогам, но они сразу же попадают в пул приложений. Поэтому вам нужно очистить только эту конкретную папку.


проблема связана с версией среды выполнения .Net библиотеки ссылочных классов (расширенные ссылки, выберите библиотеку и проверьте "версию среды выполнения". У меня была проблема с Antlr3.Среда выполнения после обновления моего проекта visual studio до v4.5. Я использовал NuGet для удаления Microsoft ASP.NET Web Optimisation Framework (из-за цепочки зависимостей, которые помешали мне удалить Antlr3 напрямую)

затем я использовал NuGet для переустановки Microsoft ASP.NET оптимизация Web Рамки. Это переустановило правильные версии среды выполнения.


в моем случае я хотел скомпилировать COM-видимую DLL. Проблема заключалась в том, что более старая версия этой DLL находилась здесь:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

таким образом, Visual Studio загрузила эту версию вместо недавно скомпилированной, поскольку она пыталась зарегистрировать ее.


очистить все файлы из временной папки (C:\Users\user_name\AppData\Local\Temp\Temporary ASP.NET Files\project folder)


иногда вам также необходимо очистить эту папку: C:\Windows\Temp\Temporary ASP.NET


я столкнулся с той же ошибкой, потому что приложение не нашло зависимых фреймворков в . Я просто восстанавливаю свою Visual studio, которая добавила необходимую структуру в вышеуказанном месте, и она работает нормально.


в моем случае изменение номера порта IISExpress в моих свойствах проекта решило проблему.


Если кто-то еще использует набор инструментов WiX, я обнаружил, что мой проект установщика имеет ссылку на старый проект, который недавно был удален из решения. Мне потребовалось некоторое время, чтобы понять, так как в решении, которое я пытался построить, есть несколько проектов, и сообщение не указывало, какой проект не удалось построить (и очистить, который также не удался).


У меня были пользователи Siemens Teamcenter 10 Client for Microsoft Office, получающие ту же ошибку о другой DLL. Ни один из других ответов не работал. Решением было удалить папки в

C:\Users\%username%\AppData\Local\assembly\

У меня была эта проблема при создании контроллера в MVC. Я изменил версию .net framework. Проблема была решена