System io filenotfoundexception не удалось загрузить файл или сборку

Обновлено: 04.07.2024

Я ненавижу указывать на очевидное, но System.IO.FileNotFoundException означает, что программа не нашла указанный вами файл. Итак, что вам нужно сделать, это проверить, какой файл ищет ваш код на производстве.

Чтобы посмотреть, какой файл ищет ваша программа на производстве (посмотрите на свойство FileName исключения), попробуйте следующие методы:

записывать в журнал отладки,
использовать приложение Visual Studio для процесса или
использование удаленной отладки Visual Studio

Затем посмотрите файловую систему на компьютере и посмотрите, существует ли файл. Скорее всего, дело в том, что его не существует.

Я столкнулся с подобной ситуацией после публикации приложения ClickOnce, и один из моих коллег из другого домена сообщил, что он не запускается.

Затем мой коллега сообщил мне подробности об исключении, и это была недостающая ссылка на файл dll сторонней структуры.

Добавлена ??ссылка и проблема решена.

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

Если в поточном enthronement (например, UI Dispatcher.Invoke), System.IO.FileNotFoundException выдается, если dll (файл) диспетчера потоков не возвращается. Итак, если ваш основной поток пользовательского интерфейса A вызывает диспетчер потоков DL, а B вызывает ваш код потока C, но C бросает какую-то несвязанную причину (например, null Reference, как в моем случае), то C не возвращается, B делает не возвращаются, а A только обвиняет B с FileNotFoundException в том, что он потерялся .

Перед тем, как спуститься по пути версии dll . Проверьте ближе к дому и убедитесь, что ваш код потока не метался.

Внимательно проверьте все ссылки

Версия остается такой же на целевой машине и на локальной машине
Если на сборку ссылаются GAC, убедитесь, что загружена правильная версия

Для меня очистка всего решения путем удаления вручную, обновление (удаление и добавление) ссылок снова с синхронизированной версией с целевой машиной, а затем создание с помощью функции «Копировать локальное»> «Ложь для сборки GAC» решает проблему.

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

Вы можете использовать FusLogVw , чтобы узнать, кто загружается старые сборки, просто определите путь для журнала и запустите свое решение, затем проверьте (в FusLogvw) первую строку, где загружена сборка Unity, дважды щелкните ее и посмотрите на вызывающую сборку, и здесь вы идете.

Чтобы избежать необходимости находить файл журнала, вы можете указать собственный путь к журналу: «Настройки», установите флажок «Включить настраиваемый путь к журналу», введите собственный путь к журналу и обновите его. – RedGreenCode 21 January 2015 в 20:46

, если это не работает, пожалуйста, не злоупотребляйте мной. я также младший

Попробуйте очистить папки Debug и Release в вашем решении. Затем удалите и снова добавьте единство.

Эта проблема может быть вызвана множеством вещей . ваше решение решило мои проблемы и могло бы решить и другие. – Scott Rippey 29 September 2011 в 02:19 @ScottRippey Это сработало для меня. Сначала я удалил все файлы .pdb, а затем перезагрузил мой проект и перестроил его. – botenvouwer 12 February 2014 в 10:26

Перейти к: Решение -> Пакет
Нажмите вкладку «Дополнительно» (найдите ниже страницы)
Добавьте вашу dll в дополнительные сборки (таким образом мы можем добавить внешние DLL в sharepoint).

У меня нет «Solution - & gt; Пакет & quot; в моем проекте VS2010 – Muflix 1 July 2015 в 14:11

Эта проблема произошла со мной, когда одна из моих зависимых библиотек составляла DLL с «Any CPU», когда родительская библиотека ожидала компиляцию «x64».

В редакторе решений щелкните правой кнопкой мыши по проекту (а не по решению), на вкладке сборки выберите Платформа цели: «Любой процессор».

У меня было это сегодня, и в моем случае проблема была очень странной:

Обратите внимание на блуждающих символов в конце XML - так или иначе они были перенесены с номера версии на конец этого блока XML!

Изменен и выше, и вуаля! Все снова работало.

Вы должны удалить файл appname.dll из выходной папки. Отладка и удаление папок. Перестроить и скопировать в файл регенерированной DLL-файл.

На 99% Не удалось загрузить файл или сборку или одна из проблем с зависимостями вызвана зависимостями! Я предлагаю вам выполнить следующие действия:

Dependency walker замечательный, но копирование случайных DLL из Интернета в Windows - это . менее здорово. Лучше попытаться найти установщика, который предоставляет эти DLL. – RJFalconer 13 October 2016 в 12:34 Я получил несколько файлов ( API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL ), которые не были найдены, и привели меня к этому вопросу stackoverflow . В основном имейте в виду, можно посмотреть на ложные положительные для некоторых файлов, ссылка обеспечивает более подробную информацию. – cheriejw 15 May 2018 в 01:00

У меня была аналогичная проблема. ** Ответ Juntos правильный **, но вы должны отметить один важный совет!

Для единства 2.1.505.2 указаны различные AssemblyVersion и AssemblyFileVersion:

[/g1]

AssemblyFileVersion используется nuget, но CLR не заботится об этом! CLR будет использовать только AssemblyVersion!

Поэтому перенаправления должны применяться к версии, указанной в AssemblyVersion: 2.1.505.0

Проверьте файл Web.config / App.config в своем проекте. Посмотрите, верны ли номера версий.

Это сработало для меня.

Это сработало для меня, хотя это был web.config, а не app.config – samneric 12 January 2018 в 03:50

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

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

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

Откройте диспетчер IIS

Выберите пулы приложений

, затем выберите пул, который вы используете

перейдите к дополнительным настройкам (с правой стороны)

Измените флаг Включить 32-битное приложение false на true.

Вы также можете щелкнуть правой кнопкой мыши свой проект в VS. и удалите предпочтительную 32-битную галочку – eran otzap 12 October 2014 в 07:57 Благодарю. Это сработало. Ну, это было уже правда в моем случае, просто для попытки. Я сделал это ложно, и это сработало. – meekash55 27 January 2017 в 11:10

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

Не работает с версиями сообщества Visual Studio – Draex_ 8 September 2017 в 18:29 Я считаю, что должна быть другая проблема, не связанная с выпуском Visual Studio. Я тестировал расширение на VS 2017 и VS 2015 Community. Фактически он был разработан с помощью версии VS 2017 Community. – marss 9 September 2017 в 19:22 В редакторе сообщества нет инструментов архитектуры, но сам редактор DGML доступен. Вы можете установить его, выбрав «Установить редактор DGML». под "Индивидуальные компоненты" - & GT; «Инструменты кода» через установщик Visual Studio - & gt; изменять – marss 16 October 2017 в 18:37

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

Вот что сработало для меня:

Удалить ссылку
Переименовать DLL
Импортировать ссылку снова

Второй шаг был важен, по-видимому, так как он не работал без него.

I «Задать в качестве стартового проекта» разгруженную / необоснованную библиотеку / проект.

Затем развернул ее.

Я думаю, 't нашел .dll, потому что он не был в сборке сначала.

После работы для меня.

Хорошо, это может показаться очень глупым, но вот как я решил проблему, попробовав все другие решения и проведя ночь на эту глупость.

Я получал ту же ошибку с некоторой DLL, отсутствующей в Bin Folder. Я попытался удалить, восстановить все из Team Foundation Server, но не работал. Получил копию папки Bin с моей офис-мателокальной машины и заменил ее. Это тоже не сработало. Наконец, я вручную перешел на FTP-сервер, получил копию DLL, которая отображалась как отсутствующая, и затем она начала показывать, что следующий файл в последовательности списка файлов отсутствует.

Итак, я ftped server Получил все Bin Folder, вручную заменил каждый файл по одному. (Не Ctrl + All и заменить .. Я пробовал: он не работал.) И как-то это сработало .

Хотя многие разработчики относительно быстро справляются с подобными проблемами, потому что прекрасно знают архитектуру своего приложения и за несколько минут могут определить, что у пользователя не установлен сторонний компонент, не хватает нужных сборок в подпапке приложения или еще что-либо в этом духе, для неподготовленных (или утомленных) умов диагностика подобных проблем может занимать довольно много времени и отнимать массу нервов.

За загрузку сборок в CLR отвечает специальный загрузчик, получивший кодовое имя Fusion . Если в процессе загрузки сборок возникают проблемы, то для упрощения диагностики существует возможность включить логгирование этого процесса. Для этого необходимо задать следующие параметры в реесте: установить параметр HKLM \ Software \ Microsoft \ Fusion \ ForceLog в 1, а в значении параметра HKLM \ Software \ Microsoft \ Fusion \ LogPath указать путь хранения лог-файла (по умолчанию, этих параметров в реестре нет, соответственно, диагностика загрузки сборок не производится).

Для проверки ошибок загрузки сборок я создал простое решение ( solution ) с двумя проектами: консольным приложением TestFusion и библиотекой классов TestFusionLib . Я добавил в библиотеку класс TestClass , а в TestFusion добавил использование этого класса. После компиляции обоих проектов, я удалил из папки bin файл TestFustionLib и запустил TestFustion . exe .

Необработанное исключение: System.IO.FileNotFoundException: Невозможно загрузить файл или сборку "TestFusionLib, Version

=1.0.0.0, Culture = neutral , PublicKeyToken = null " или один из зависимых от них компонентов. Не удается найти указанный файл.

Имя файла: " TestFusionLib , Version =1.0.0.0, Culture = neutral , PublicKeyToken = null "

--- Подробный журнал ошибок.

=== Информация о состоянии предварительной привязки ===

Журнал: User = HOME\Sergey

Журнал: DisplayName = TestFusionLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Журнал: Appbase = file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/

Журнал: Initial PrivatePath = NULL

Вызов сборки: TestFusion, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

Журнал: данная привязка начинается в контексте загрузки default .

Журнал: файл конфигурации приложения не найден.

Журнал: используется файл конфигурации компьютера из C :\ WINDOWS \ Microsoft . NET \ Framework \ v 2.0.50727\ config \ machine . config

Журнал: политика в данный момент не применяется к ссылке (личная, пользовательская, частичная привязка сборки или привяз ка по местоположению).

Журнал: попытка загрузки нового URL file :/// D :/ Sources / VS 2008/ TestFusion / TestFusion / bin / Debug / TestFusionLib . DLL .

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib/TestFusionLi

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib.EXE.

Помимо просмотра и конфигурирования процесса логирования загрузки сборок вручную, в составе . NET Framework SDK поставляется полезная утилита с названием Fuslogvw . exe ( Fusion Log Viewer ) [3], которая в значительной степени упрощает подобный процесс диагностики.

Внимание! Утилиту Fuslogvw . exe необходимо запускать с правами Администратора, в противном случае вы не сможете изменить ни какие параметры.

Примечание . Путь к Fuslogvw.exe: %ProgramFiles%\MicrosoftSDKs\Windows\v6.0A\bin\Fuslogvw.exe

Если после неудачного запуска приложения (в нашем случае TestFusion . exe ) запустить Fuslogvw . exe (или нажать кнопку Refresh , если эта утилита уже была запущена), то мы увидим следующую картину:

Нас интересует вторая строка. Если на ней нажать View Log , получим следующие данные:

Операция выполнена со сбоем.

Результат привязки: hr = 0 x 80070002. Не удается найти указанный файл.

--- Подробный журнал ошибок.

=== Информация о состоянии предварительной привязки ===

Журнал: User = HOME\Sergey

Журнал: DisplayName = TestFusionLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Журнал: Appbase = file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/

Журнал: Initial PrivatePath = NULL

Журнал: Dynamic Base = NULL

Журнал: Cache Base = NULL

Журнал: AppName = NULL

Вызов сборки: TestFusion, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

Журнал: данная привязка начинается в контексте загрузки default .

Журнал: файл конфигурации приложения не найден.

Журнал: используется файл конфигурации компьютера из C :\ WINDOWS \ Microsoft . NET \ Framework \ v 2.0.50727\ config \ machine . config .

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib.DLL.

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib/TestFusionLib.DLL.

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib.EXE.

Журнал: попытка загрузки нового URL file:///D:/Sources/VS2008/TestFusion/TestFusion/bin/Debug/TestFusionLib/TestFusionLib.EXE.

Журнал: все попытки проверки URL закончились неудачно.

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

Отступление от темы. Диагностика проблем загрузки неуправляемых библиотек

В отладке подобных проблем первое, что нужно сделать, это скачать замечательную утилиту под названием Dependency Walker [5] и попытаться открыть ваш exe -файл с помощью этой утилиты на машине пользователя (или на машине с идентичной конфигурацией). Dependency Walker рекурсивно проходится по всем неуправляемым библиотекам и сразу же покажет вам, какой именно неуправляемой библиотеки не хватает.

Дополнительные ссылки

Я получаю следующую ошибку .

Я пробовал следующее:

Это ошибка? Есть ли обходной путь? Любая помощь приветствуется.

У меня была та же проблема, и я не нашел предлагаемых решений. Мое решение этой проблемы: проверьте App.config и packages.config, чтобы узнать, совпадают ли версии.

Первоначально мой app.config содержал:

Но файл packages.config содержал:

Я изменил запись app.config, чтобы она соответствовала packages.config для новой версии:

После изменения проблема была решена.

Я вытащил «4.3.0» из NuGet, но по какой-то причине VS настаивает на том, чтобы я ссылался на «4.1.2.0», у меня сработала аналогичная работа, только с другим номером версии . У меня была такая же проблема, как у @DavidRogers в проекте MSTest. Объединение различий между app.config и packages.config решило проблему. да, большое спасибо ! Это было решение для моего MSTest, который не нашел тестов [MSTest][Discovery] Failed to discover tests from assembly Reason:Could not load file or assembly 'System.Reflection, Version=4.1.1.0 etc Решение сработало для меня. Проблема началась после установки HtmlAgilityPack NUGET. И не запускался из-за неправильной информации о версии в пакетах. +1

Приведенное ниже больше не нужно, оно было исправлено около VS 15.3:

Был известная ошибка VS2017 , особенно в NuGet 4.0.

NuGet 4.x приносит с собой «ссылку на пакет» - больше никаких пакетов.config, - но старый конвейер 4.x не был полностью обновлен на момент запуска VS2017. Приведенный выше фрагмент, кажется, «разбудит» систему сборки для правильного включения ссылок на пакеты из зависимостей.

Какое обновление Visual Studio 17? Можете указать версию? У меня все еще проблема в 15.5.5 VS2017. Похоже, есть и другие причины.

Я недавно столкнулся с этой проблемой, и я пробовал много вещей, упомянутых в этой и других ветках. Я добавил ссылку на "System.Runtime" пакет для диспетчера пакетов nuget, исправил повторные привязки app.config и убедился, что app.config и package.config для сборки используется та же версия. Однако проблема не исчезла.

Наконец-то снял <dependentAssembly> бирку для сборки и проблема исчезла. Итак, попробуйте удалить следующее в вашем app.config .

Основываясь на вашем ответе, я проверил свои пакеты nuget и обнаружил, что между моими проектами требуется «Google.protobuf» (консолидация), Было бы полезно лучше объяснить, почему это сработает. Проблема с этим методом заключается в том, что всякий раз, когда вы обновляете какой-либо пакет nuget или добавляете новый пакет nuget, он будет добавлен снова.

Я решил эту ошибку, сославшись на NetStandard.Library и следующий файл app.config в NUnit-Project.

редактировать

Редактировать 2

В новых версиях Visual Studio (я думаю, 2017 15.8) возможно, что Studio создаст файл app.config. Просто установите флажок Автоматически создавать перенаправления привязки в Project-Properties - Application .

Редактировать 3

Я исправил это, удалив app.config с помощью

app.config был автоматически добавлен (но не нужен) во время рефакторинга

Это сработало для меня! Обязательно попробуйте это, если все остальное у вас не работает

Я исправил свою ошибку, установив NetStandard.Library в свой проект модульного тестирования.

Мы обнаружили, что AutoGenerateBindingRedirects может быть причиной этой проблемы.

Замечено: один и тот же проект нацелен net45 и netstandard1.5 был успешно построен на одной машине и не был построен на другой. На машинах были установлены разные версии фреймворка (4.6.1 - успешно и 4.7.1 - неудачно). После обновления фреймворка на первой машине до версии 4.7.1 сборка также не удалась.

Загляните в это прямо сейчас в проекте модульного теста после добавления MsTest V2 через Nuget. Переименование app.config (столь эффективное его удаление) помогло мне.

но один пакет также добавил ту же сборку в зависимости от другой версии:

удаление тега «добавить сборку» из моего файла web.config решило проблему.

В app.config или web.config добавьте

Похоже, проблема возникает из-за конфликта версий между packages.config и app.config. В app.config у вас есть перенаправления привязки сборки, автоматически генерируемые функцией AutoGenerateBindingRedirects. Если этот параметр включен каждый раз, когда вы загружаете пакет nuget, он будет, помимо создания новой записи в packages.config, добавлять эту информацию о перенаправлении привязки в app.config. Какова цель этого, объясняется здесь: Перенаправление привязки сборки: как и почему?

Там вы можете прочитать, что написал пользователь @Evk:

Зачем вообще нужны привязки перенаправления? Предположим, у вас есть приложение A, которое ссылается на библиотеку B, а также на библиотеку C версии 1.1.2.5. Библиотека B, в свою очередь, также ссылается на библиотеку C, но версии 1.1.1.0. Теперь у нас конфликт, потому что вы не можете загружать разные версии одной и той же сборки во время выполнения. Чтобы разрешить этот конфликт, вы можете использовать перенаправление привязки, обычно к новой версии.

Итак, БЫСТРОЕ ИСПРАВЛЕНИЕ: удалите все записи в app.config.

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

Читайте также: