Не вдалося знайти файл метаданих під час створення проектів

Щоразу, коли я запускаю Visual Studio 2008, вперше, коли я намагаюся запустити проект, я отримую помилку CS0006 Файл метаданих ... не вдалося знайти. Якщо я перероблю повне рішення, воно працює.

Деякі відомості про рішення:

• Я будую в режимі налагодження і Visual Studio скаржиться на те, що не знайшов dll: s у папці випуску.

• Проекти, на які скаржиться Visual Studio, використовуються багато інших проектів у рішенні.

• Я змінив вихідний шлях для всіх проектів на ...... \ build \ debug \ ProjectName та ...... \ build \ release \ ProjectName відповідно. (Просто для отримання всіх файлів збирання в одному каталозі)

• У мене така ж проблема з іншим рішенням.

• Розчин створювався з нуля.

• У вирішенні 9 проектів. Одна бібліотека WPF та 8 класів, що використовують dotnet 3.5.

Будь-які ідеї щодо того, що викликає цю проблему?

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

Зазвичай це викликано проектом, на який посилається інше рішення, ніж той, що видає помилку. Якщо ви очистите інше рішення або роздрібніть код, ви, швидше за все, побачите цю помилку. Рішення полягає в прокручуванні списку помилок "метаданих не знайдено" та перегляді посилань на проекти. 9/10 разів ви побачите ламану посилання на проект, який відсутній у цьому рішенні. Додайте проекти для виправлення посилальних помилок та відновлення. Це повинно це виправити.

(Я просто зіткнувся з цим сьогодні, і в минулому, і це ВЖЕ завжди працювало)

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

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

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

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

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

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

Я виявив, що якщо ви клацніть правою кнопкою миші на своєму рішенні в Провіднику рішень і виберіть "Побудувати замовлення", ви побачите порядок, який VS використовує для відновлення вашого рішення. Це, ймовірно, з удару.

Ви можете виправити порядок складання, натиснувши на вкладку Залежності та вибравши проекти, які залежать від інших проектів у рішенні, та перевіривши проекти, від яких вони залежать. Після того, як ви все в порядку і зробите рішення за рішенням, вам слід добре піти.

Те, як я минув це в минулому у VS2005, а також зараз у VS2008, це переконатися, що всі залежності є правильними, а посилання вказують на проекти, а не на DLL. Потім пройдіть і складіть кожен проект вручну в залежності від порядку. Після створення останнього ви зможете запустити повне складання рішення та його штраф.

Ця відповідь є для подальшого ознайомлення для інших, оскільки я знаю, що це питання старіє понад 15 місяців.

Ура

У мене є кілька моментів, які я хотів би зробити.

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

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

Ви повинні мати на увазі, що спосіб Visual Studio генерує порядок побудови не зовсім такий, як те, як це робить MSBuild. Це тому, що MSBuild в першу чергу залежить від файлу проекту, щоб визначити, що це залежність, тоді як Visual Studio також може зберегти їх у файлі soltuion. Тому іноді можна побачити ситуації, коли Visual Studio ідеально будує рішення, але MSBuild просто не може цього зробити.

У мене було кілька випадків, коли мені доводилося вручну підлаштовувати порядок відображення проектів у файлі рішення, а також порядок, у якому проекти були перераховані в елементі ProjectReferences в проекті веб-сайту у файлі рішення.

Сподіваюсь, що наведена інформація допомагає.

Якщо ви використовуєте, наприклад, контексти даних LinqtoSQL, а файл .designer.cs відсутній, ви отримаєте файл Metadata не вдалося знайти помилку.

Відтворити файл дизайнера.cs легко.

Відкрийте dbml за допомогою перегляду xml. Додайте порожній рядок, потім видаліть його, а потім збережіть. Це має відновити файл дизайнера.cs.

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

У мене виникає подібна проблема щоразу, коли я оновлюю проект від SVN.
Ще одне рішення для ASP.NET:

1. Закрийте IDE.
2. Видаліть файли в C:\WINDOWS\microsoft.net\framework\v…\Temporary ASP.NET File\.

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

Спершу переконайтеся, що прапорець "побудувати" позначено у Збірка -> Менеджер конфігурацій для кожного проекту.

Якщо у вас вже вибрані всі проекти в меню Build -> Configuration Manager, і перезапуск фокусу VS для вас не працює, ніж вам потрібно знайти посилання на файл (и) (може бути dll або cs) в свого проекту та видаліть ці посилання вручну. Ці файли / посилання / посилання мають відображатися жовтим значком. Помилка, безумовно, визначає, який проект рішення ви повинні шукати.

Причина цієї помилки полягає в тому, що ви видалили файли (файли) вручну в Windows Explorer і VS не оновлював посилання та намагався знайти файл, який більше не існує!

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

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

Сталося те саме. У мене є кілька рішень, що стосуються одних і тих самих бібліотечних проектів (.net 3.5). Я помітив, коли один був вбудований у конфігурацію налагодження / нормальний, а інший, використовуючи іншу директиву компілятора (sqlite / локальний режим), це станеться. Просто набудьте обидва проекти, що будуються з однаковими директивами, і вам слід добре.

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

Я застряг у проблемі збереження, коли хотів включити dll-файл, згенерований Matlab. І я нарешті вирішив це, скопіювавши .ctf файл, що означає, я думаю, сертифікат, і .netmodule, необхідний для належної роботи .dll, разом з файлом .dll. І це насправді спрацювало! Отже, я пропоную перевірити, чи потрібні .dll будь-які інші файли, щоб ужитися.

Windows 7 Ultimate 32 Visual Studio 2008 SQL Server v2005

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

Після того, як я скинув посилання бази даних на правильну настройку, я зміг створити без подальшої проблеми. Крім того, це була моя перша спроба відновити цей проект після розгалуження вихідного коду у VSS.

Щасти

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

EE - У моєму випадку проблема полягала в проекті, який має структуру Entity, відкрийте схему перетягування будь-якої таблиці на 2 см :) і збережіть, VS оновить всі свої посилання на БД ... побудуйте ці проекти та побудуйте рішення , Buildssss.

Єдине, що мене виправило (оскільки я не запускаю VS2010 в обліковому записі адміністратора) - це ручне переміщення змінної середовища VS120COMNTOOLS із системних змінних до змінних користувачів.

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

Детальний підхід:

Ну, моя наступна відповідь - це не просто стислий виклад усіх рішень, але він пропонує і більше.

Розділ (1):

Загальні рішення:

У мене було 4 помилки подібного типу ("файл метаданих не вдалося знайти"), а також 1 помилка із записом "Не вдалося відкрити вихідний файл (" Не визначена помилка ")".

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

1. Перезапустіть VS та спробуйте створити його ще раз.

2. Перейдіть до "Провідник рішень" . Клацніть правою кнопкою миші рішення. Перейдіть до " Властивості" . Перейдіть у "Менеджер конфігурацій" . Перевірте, чи встановлені прапорці в розділі "Побудувати" , чи немає. Якщо будь-який або всі вони не встановлені, перевірте їх і спробуйте створити його ще раз.

3. Якщо вищезазначені рішення не працюють, дотримуйтесь послідовності, зазначеної в кроці 2 вище, і навіть якщо всі прапорці встановлені, зніміть їх, зніміть ще раз та спробуйте створити заново.

4. Залежності замовлення та проекту:

   Перейдіть до "Провідник рішень" . Клацніть правою кнопкою миші рішення. Перейдіть до розділу "Залежності проекту ..." . Ви побачите 2 вкладки: "Залежності" та "Порядок побудови" . Цей порядок побудови - це той, в якому будується рішення. Перевірте залежність проекту та порядок складання, щоб перевірити, чи намагається якийсь проект (скажімо, «проект1»), який залежить від інших (скажімо, «проект2»), створити перед цим (проект2). Це може бути причиною помилки.

5. Перевірте шлях відсутнього .dll:

   Перевірте шлях зниклого .dll. Якщо шлях містить пробіл або будь-який інший недійсний символ шляху, видаліть його та спробуйте створити його ще раз.

   Якщо це причина, то відрегулюйте порядок складання.

   ---

Розділ (2):

Мій конкретний випадок:

Я спробував усі етапи вище з різними перестановками та комбінаціями з перезапуском VS кілька разів. Але, це мені не допомогло.

Отже, я вирішив позбутися від іншої помилки, на яку я натрапив ("Вихідний файл не вдалося відкрити (" Невизначена помилка ")").

Я натрапив на блог: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

Я спробував кроки, згадані в цьому блозі, і я позбувся помилки "Не вдалося відкрити вихідний файл (" Невизначена помилка ")", і на диво я також позбувся інших помилок ("файл метаданих не вдалося знайти") .

Розділ (3):

Мораль історії:

Спробуйте всі рішення, як зазначено в розділі (1) вище (та будь-які інші рішення), щоб позбутися від помилки. Якщо нічого не виходить, згідно з блогом, згаданим у розділі (2) вище, видаліть записи всіх вихідних файлів, яких більше немає в керуванні джерелами та файловій системі, з вашого файлу .csproj .