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

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

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

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

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

Источник

28 ответов

Решение

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

Очистить оба:

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

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

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

Источник

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

  1. % TEMP% \ Временные файлы ASP.NET
  2. C:\Windows\Microsoft.NET\Framework\v2.0.50727\ Временные файлы ASP.NET
  3. C:\Windows\Microsoft.NET\Framework\v4.0.30319\ Временные файлы ASP.NET
  4. C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ Временные файлы ASP.NET
  5. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ Временные файлы ASP.NET

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

Источник

Я должен был очистить

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Временные файлы 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 \ Временные файлы ASP.NET \

Источник

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

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

Источник

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

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

Источник

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

Спасибо

Источник

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

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET

Источник

Спасибо, Алекс, твое второе замечание помогло мне исправить это.

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

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

Источник

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

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

Решение проблемы

Источник

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

uninstall-package ActionMailer
install-package ActionMailer

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

Источник

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

Источник

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

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

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

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

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

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

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

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

Источник

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

Источник

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

Источник

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

Источник

Вы можете очистить, собрать или перестроить свое приложение или просто удалить временные файлы ASP.NET в C:\Users\ ВАШЕ ИМЯ ПОЛЬЗОВАТЕЛЯ \ AppData\Local\Temp

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

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

Источник

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

Источник

Эта проблема связана с.Net исполняемой версией указанной библиотеки классов (разверните ссылки, выберите библиотеку и проверьте "Runtime Version". У меня возникла проблема с Antlr3.Runtime после обновления проекта Visual Studio до версии 4.5. I использовал NuGet для удаления Microsoft ASP.NET Web Optimization Framework (из-за цепочки зависимостей, которые помешали мне удалить Antlr3 напрямую)

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

Источник

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

Источник

У меня была аналогичная проблема при открытии диспетчера пакетов Nuget, я удалил все временные файлы и построил проект, он работал нормально.

Источник

У меня была такая же проблема с «Chocolatey Server (Simple)», работающим на IIS, и мне пришлось выполнить следующие шаги.

  1. Очистите «C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files» в соответствии с рекомендациями.
  2. Удалите приложение «Chocolatey Server (Simple)» через choco
  3. Удалите каталог «C:\tools\chocolatey.server» из каталога шоколадного пакета. Важно, потому что в противном случае Web.config содержит старые зависимости, что приводит к ошибке. Простая переустановка не обновит существующий Web.config (как это было в моем случае).
  4. Перезапустите IIS и настройте Chocolatey Server в соответствии с рекомендациями авторов. Шоколадная страница сервера теперь должна быть видна без каких-либо ошибок.
Источник

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

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

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

Источник

Я столкнулся с той же ошибкой, потому что приложение не нашло зависимых платформ в C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\ папка. Я просто ремонтирую свою Visual Studio, которая добавила необходимые рамки в указанном выше месте, и она работает нормально.

Источник

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

Источник

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

Источник

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

C:\Users\%username%\AppData\Local\assembly\
Источник
Другие вопросы по тегам