Файл метаданих VS 2017 '.dll не вдалося знайти

Я знаю, що є ще одне запитання з точно такою ж проблемою, але я пройшов усі ці відповіді, і жодне мені не допомогло. :( ( Це було питання. )

Я щойно створив новий проект ASP.NET MVC і приєднався до декількох '.dll' у вирішенні. Тепер, коли я намагаюся побудувати проект, я отримую повідомлення про помилку, показане нижче, у 3 з 5 бібліотек.

Error   CS0006  Metadata file 'C:\Users\...\source\Database\bin\Debug\DataAccessLayer.dll' could not be found   Logic   C:\Users\...\source\Logic\CSC   1   Active

Error   CS0006  Metadata file 'C:\Users\...\source\Logic\bin\Debug\Logic.dll' could not be found    PTS2-MVC    C:\Users\...\source\PTS2-MVC\CSC    1   Active

Error   CS0006  Metadata file 'C:\Users\...\source\PTS2-MVC\bin\PTS2-MVC.dll' could not be found    PTS2-MVC.Tests  C:\Users\...\source\PTS2-MVC.Tests\CSC  1   Active

Коли я переходжу до папки bin \ debug цієї .dll, я бачу, що вона порожня, а інша .dll, де я не отримую повідомлення про помилку, не порожня. Але я не знаю, як це виправити або що я зробив, щоб це сталося.

Найпоширеніша відповідь повинен піти на властивості цього рішення і перейти до конфігурації і зніміть прапорець -> застосувати -> Перевірка і застосувати знову, але це не робота

Проблема полягала в тому, що в моєму проекті були інші звичайні повідомлення про помилки, і, мабуть, після того, як я їх виправив, і коли Я ОЧИСЛИВ і побудував свій проект, тоді всі .dll вдалося.

Переконайтеся, що у вас немає інших повідомлень про помилки у вашому проекті, і якщо вони є, виправте їх першими!

Етапи виправлення цієї помилки: Файл MetaData .dll не вдалося знайти.

1. Очистити всі проекти.

2. Вивантажити всі проекти.

3. Перезавантажте всі проекти.

4. Рішення ReBuild.

Потім проблема вирішена.

У моєму випадку сталася помилка, але вона не була належним чином проаналізована VS і показана у вікні "Список помилок". Щоб знайти його, ви багато переглядаєте "Вивід" у вікні збірки, аналізуєте повідомлення, починаючи зверху вниз, і вирішуєте фактичну помилку. M $, будь ласка, виправте! Це величезна втрата часу колективними розробниками світів.

Перевірте назву папки проекту. У моєму випадку моя папка проекту була названа з пробілами. Коли я клонував проект із Team Foundation Server за допомогою git bash, пробіли в назві папки були перетворені на: "% 20". Повернення їх до пробілів вирішило проблему для мене.

У мене виникла ця проблема з рішенням, що містить кілька проектів.

Це сталося завдяки продублюванню .csproj та додаванню копії до рішення. A .csproj файл містить <ProjectGuid>елемент. Я встановив GUID скопійованого проекту на новий.

Оновлення: який GUID ви використовуєте, не має значення, він просто повинен відрізнятися від GUID іншого проекту. Ви можете створити новий GUID всередині Visual Studio: Tools -> Create GUIDі скопіювати частину між фігурними дужками, тобто {...}. Використовуйте це як нове значення для <ProjectGuid>елемента.

Я також виконав наступні кроки (необов’язково, але вони не болять):

1. Закрийте розчин
2. Видалити папку bin
3. Видалити всі папки obj
4. Відкрийте рішення та побудуйте

Я виправляю цю проблему, виконавши такі дії:

1. Чисте рішення
2. Закрийте Visual Studio
3. Видалення / bin з каталогу проекту
4. Перезапустіть Visual Studio
5. Відновити рішення

У мене така сама проблема, проблема полягала в тому, що шлях до рішення має пробіли в назві, і проти з якихось причин не вирішує пакет ... завантажте моє сховище ще раз, просто перейменувавши рішення без пробілів у назві.

наприклад:

/Repo/Project Name/src

має бути

/Repo/ProjectName/src

Для мене прибирання та будівництво не працювали. Розвантаження проекту не спрацювало. Перезапуск Visual Studio або навіть ПК не спрацював. Ось що вдалося:

Перейдіть до кожного з проектів, що спричиняють помилку, а у розділі «Список літератури» видаліть посилання на проблемний проект і додайте його знову. Це вирішує проблему.

Здається, проблема пов’язана з переміщенням проекту (наприклад, перемістіть його всередину папки), а потім іншим проектом, який посилається на нього, неправильний шлях і не може його знайти.

У мене була та ж проблема, навіть без жодних інших помилок, що відображаються у поданні "Список помилок" після "Відновити рішення". Однак у поданні "Вивід" я побачив помилку, яка стояла за цією проблемою:

Основне посилання "C: ... \ myproj.dll" не вдалося вирішити, оскільки воно було побудоване в рамках ".NETFramework, Версія = v4.6.1". Це вища версія, ніж поточна цільова структура ".NETFramework, Версія = v4.5"

Як тільки я це виправив, питання було вирішено.

Інша річ, яку слід перевірити, - це цільовий фреймворк будь-яких проектів, на які посилаються, щоб переконатися, що проект, що викликає, використовує ту саму або пізнішу версію фреймворку.

У мене виникла ця проблема, я спробував усі запропоновані раніше відповіді, а потім на здогадок перевірив рамки. Один із проектів, на які посилаються, був націлений на 4.6.1, коли проект, що викликав, був лише 4.5.2.

Запуск цієї команди в bash для видалення всіх смітників працював у мене

$ find . -iname "bin" -o -iname "obj" | xargs rm -rf

Не можу гарантувати, що це спрацює на когось іншого

Також пам’ятайте, що всі файли bin буде видалено - тож вам доведеться перебудувати всі проекти. Очевидно, що краще використовувати компакт-диск у відповідному каталозі перед його використанням.

Очищення мого рішення спричинило цю проблему з Visual Studio 2017. Розвантаження / перезавантаження проектів або більше очищення не мало значення. Працювало лише закриття та перезапуск Visual Studio.

Перевірте, чи всі проекти завантажені. У моєму випадку один із проектів був вивантажений, і перезавантаження проекту видаляє помилки.

У моєму випадку мені довелося відкрити файл .csproj і додати посилання вручну, наприклад, так (Microsoft.Extensions.Identity.Stores.dll відсутній):

<Reference Include="Microsoft.Extensions.Identity.Stores">
  <HintPath>..\..\..\..\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.identity.stores\2.0.1\lib\netstandard2.0\Microsoft.Extensions.Identity.Stores.dll</HintPath>
</Reference>

Закрийте Visual Studio, знайдіть файл .suo рішення, видаліть його, знову відкрийте Visual Studio.

Що мені вдалося:

Консоль менеджера пакетів (Visual Studio 2019 Comunity):

Install-Package NuGet.CommandLine
nuget locals all -clear

Відновити рішення.

У моєму випадку я стикався з такою ж помилкою. Одним із рішень мого проекту було посилання на збірку з іншого місця розташування NuGet. Я просто змінив його для правильного розташування, щоб вирішити цю помилку та відновити. і вау, проект успішно побудував, а всі інші помилки зникли.

У мене була та сама помилка. У моєму випадку я створив бібліотеку (назвемо її commsLibrary), яка посилається на інші бібліотеки, включаючи їх як проекти у своє рішення. Пізніше, коли я будував проект і додавав свою бібліотеку commsLibrary , щоразу, коли я буду будувати, я отримував файл метаданих, помилка не може бути знайдена. Тож я додав бібліотеки, які моя бібліотека comms посилалася на поточний проект, тоді він зміг будувати.

Потрапивши на стільки неприємностей, ось рішення, яке я знайшов.

1. відкрийте папку проекту.
2. знайти Your_Project_Name.csproj [Файл проекту Visual C # (.csproj)]

3. відкрийте цей файл у будь-якому текстовому редакторі та знайдіть зниклий файл ItemGroup.

   <ItemGroup> <None Include="..." /> </ItemGroup>

4. видаліть групу ItemGroup і знову відкрийте свій проект та побудуйте

5. Якщо це посилання важливо для вас, додайте ще раз.

У мене була та ж проблема, і я спробував рішення з файлу метаданих '.dll' не вдалося знайти

але жодне з них не спрацювало.

Тому після спроб та помилок я виправив це, вивантаживши та перезавантаживши проект, зробивши це, скинувши файл конфігурації та виправивши проблему.

Я побудував 10 проектів з 25 проектів, що вирішуються індивідуально, один за одним на основі залежностей. Потім побудуйте рішення. Це виправлено для мене

У мене була та сама проблема. Моя проблема полягала в тому, що хтось із команди перемістив папку класу, і проект шукав її.

Для мене було 44 помилки; 43 закінчується .dll (пошук залежності), а перший у списку помилок закінчується .cs (пошук фактичного класу). Я спробував чисту збірку та чистку, вивантаження, перезавантаження, збірку, але нічого не працює. У підсумку я знайшов клас у проекті і просто видалив його, оскільки він у будь-якому випадку відображався як недоступний, а потім чиста збірка.

Це зробило для мене фокус! Сподіваюся, це допомагає.

У мене було 2 файли (і 2 класи) в одному проекті з такою ж назвою.

У моєму випадку я видалив один файл безпосередньо з командного меню командного провідника, яке спричинило цю проблему. Коли я перевірив Explorer Explorer, він все ще відображав видалений файл як файл без посилань. Коли я видалив цей файл із провідника рішень, я зміг успішно створити проект.

Для мене працювало:

Видаліть, а потім переінсталюйте згаданий пакет Nuget, який має помилку.

У моєму випадку я запустив тести і отримав помилку CS0006. Виявилося, що я запускаю тести в режимі випуску. Перехід у режим налагодження виправив цю помилку.

Ця проблема трапляється, коли ви перейменували своє рішення, і .net framework не може знайти старе рішення.

Щоб вирішити цю проблему, вам потрібно знайти та замінити стару назву рішення та всі залежності від нього новою назвою. Якщо вам потрібно переглянути фізичний файл за допомогою провідника файлів, зробіть це.

Файли , які , як правило , уражаються AssemblyInfo.cs, ім'я та простір імен по замовчуванню. Обов’язково оновіть їх новою назвою..slnProperties > Application > Assembly

Відкрийте провідник файлів, якщо папка зі старою назвою все ще існує, її потрібно видалити. Потім очистіть і будуйте рішення, поки помилка не зникне. (Якщо потрібно, почистіть і побудуйте проект по одному, особливо постраждалий проект.)

У моєму випадку проблема полягала в тому, що я посилався на проект, де коментував усі .csфайли.

Наприклад, ProjectApp посилається на ProjectUtility. У ProjectUtility у мене було лише 1 .csфайл. Я вже не використовував його, тому прокоментував весь файл. У ProjectApp я не викликав жодного коду з ProjectUtility, але мав using ProjectUtility;один із .csфайлів ProjectApp . Єдиною помилкою, яку я отримав від компілятора, була помилка CS0006 .

Я .csпрокоментував файл у ProjectUtility, і помилка зникла. Тому я не впевнений, що відсутність коду у проекті змушує компілятор створювати недійсну збірку або взагалі не генерувати DLL. Для мене виправлення полягало в тому, щоб просто видалити посилання на ProjectUtility, а не коментувати весь код.

Якщо вам було цікаво, чому я прокоментував весь код із вказаного проекту замість того, щоб видалити посилання, я зробив це, оскільки тестував щось і не хотів модифікувати ProjectApp.csprojфайл.