Отримання "типу або імені простору імен не вдалося знайти", але все здається нормальним?

Я отримую:

Не вдалося знайти ім'я типу або простору імен

помилка для програми C # WPF у VS2010. Ця область коду склалася чудово, але раптом я отримую цю помилку. Я спробував видалити довідку про проект та usingзаяву, закрити VS2010 та перезапустити, але все-таки у мене є ця проблема.

Будь-які ідеї, чому це може статися, де, здається, я роблю правильно, що стосується довідки та usingзаяви?

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

Це може бути результатом несумісності між двома проектами .Net Framework версії.

Це може статися двома способами:

1. проект клієнтського профілю, що посилається на повний рамковий проект; або
2. старіша версія рамки, орієнтована на новішу версію рамки

Наприклад, це станеться, коли програма буде націлена на систему .Net 4 Client Profile, а проект, на який посилається, орієнтований на повну .Net 4 структуру.

Отже, щоб зробити це зрозумілішим:

• Проект A орієнтований на систему профілю клієнта
• Посилання на проект Проект B
• Проект B спрямований на всі рамки

Рішенням у цьому випадку є або оновити рамкову ціль програми (Проект A), або зменшити ціль посилальної збірки (Проект B). Добре, щоб програма з повним фреймворком посилалася / споживала структуру рамки профілю клієнта, але не навпаки (профіль клієнта не може посилатися на повну цільову структуру фреймворку).

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

• використання посилальних проектів .Net 4.0 (це звичайно, коли ви перейшли з VS2010 на VS2012 або VS2013 і потім додаєте новий проект)

• згадані проекти використовують більшу версію, тобто 4.5.1 або 4.5.3 (ви перенацілили наявні проекти на останню версію, але VS все ще створює нові проекти, орієнтовані на v4.5, а потім ви посилаєтесь на ті старіші проекти з новий проект)

Перевстановлення пакетів нута зробило для мене трюк. Після того, як я змінив версії .NET Framework, які синхронізувались для всіх проектів, деякі попередні пакети (особливо Entity Framework) все ще були встановлені для попередніх версій. Ця команда в Console Packages Manager перевстановлює пакети для всього рішення:

Update-Package –reinstall

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

Під час створення рішення я отримував ту саму помилку (тип або простір імен '' не вдалося знайти). Під ним я побачив попередження про те, що "посилання неможливо вирішити" та переконатися, що "збірка існує на диску".

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

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

Коли я клацнув правою кнопкою миші на проект і створив це лише замість всього рішення, я не отримав помилку.

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

Зробити це:

1. Я клацнув правою кнопкою миші своє рішення в Провіднику рішень і вибрав "Властивості"
2. Потім у "Загальних властивостях" я вибрав "Залежності проекту".
3. Потім у спадному меню Проекти я вибрав проект, який спирався на бібліотеку, і
4. Поставте прапорець біля бібліотеки, знайденої в розділі "Залежить від"

Це гарантує, що проект бібліотеки спочатку будується.

Спочатку я би переконався, що створена вашим проектом інформація не є пошкодженою. Зробіть чисту і відновіть своє рішення.

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

Більш складною ситуацією, в яку я зіткнувся, було: перший проект націлений на 4,0 повний фреймворк із Microsoft.Bcl.Asyncвстановленим пакетом. Проект два орієнтується на повний фреймворк 4.0, але не збирається при посиланні на клас 1 проекту.

Після того, як я встановив пакет Async NuGet на другому проекті, він склався чудово.

У моєму випадку я знаходжу в VisualStudio посилання на трикутник та знак оклику як це зображення,

потім я клацну правою кнопкою миші видалити її і знову правильно додати посилання на dll, проблема була вирішена.

Цей працював на мене. У вашому класі, де визначено назву класу, наприклад: Public class ABC, видаліть один символ і трохи почекайте. Ваш список помилок збільшиться, оскільки ви змінили ім'я. Тепер поверніть символу, який ви ввели. Це працювало для мене, сподіваюсь, воно буде працювати і для вас. Щасти!!!

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

PS: У моєму випадку я працював над веб-додатком, але ця проблема може виникати в різних проектах.

[Facepalm] Моє питання полягало в тому, що я додав залежність у способі C ++.

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

Якщо ні, ви можете "Додати довідку" та вибрати залежність на вкладці "Проекти".

Бум Шанкар.

У нас був дивний випадок цього, який я просто зафіксував у вирішенні. Перед основним проектом висловлювався прихований / пробільний символ перед заявою "користування". Цей проект створив би чудово і веб-сайт працював чудово, але проект тестового проекту, на який він посилався, не міг бути побудований.

Я зіткнувся з цією проблемою під час модернізації існуючих проектів з VS2008 до VS2012. Я виявив, що два проекти (єдині два, які я створив) орієнтувались на різні .Net Frameworks (3.5 та 4.0). Я вирішив це на вкладці Програми проектів, переконавшись, що в обох проектах ".NET Framework 4" у полі Target Framework.

У мене були ті ж помилки, моя історія була такою: після поганого злиття (через git) один із моїх .csproj-файлів мав дублювати compileзаписи, як-от:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

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

У мене була така ж проблема, як обговорювалося: VS 2017 підкреслює клас посилається на проект як помилку, але рішення створює нормально і навіть інтелісцентні роботи.

Ось як мені вдалося вирішити цю проблему:

1. Вивантажте згаданий проект
2. Відкрийте файл .proj у VS (я шукав дублікати, як хтось тут запропонував)
3. Знову перезавантажте проект (я не змінював і не зберігав файл proj, оскільки у мене не було дублікатів)

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

Я знаю, що це вибиває мертвого коня, але у мене була ця помилка та рамки, де добре. В основному моя проблема полягала в тому, що інтерфейс неможливо знайти, але він може створити і отримати доступ до нього просто. Тому я задумався: "Чому саме цей інтерфейс, коли інші працюють нормально?"

Зрештою, я фактично звертався до сервісу, використовуючи WCF з інтерфейсом кінцевої точки, який використовував Entity Version 6, а решта проектів використовувала версію 5. Замість використання NuGet я просто скопіював пакунки nuget в локальний сховище для повторного використання та перераховували їх по-різному.

наприклад, EntityFramework6.dll проти EntityFramework.dll .

Потім я додав посилання на проект клієнта та пуф, моя помилка усунулася. Я розумію, що це крайній випадок, оскільки більшість людей не змішують версії Entity Framework.

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

У моєму випадку я додав новий клас до одного проекту, але через те, що мої прив’язки управління версіями не встановлені, мені потрібно було зробити файл, який можна записати за межами Visual Studio (через VC). Я скасував збереження у Visual Studio, але після того, як я зробив файл, який можна записати за межами VS, потім натиснув Save All знову в VS. Це мимоволі призвело до того, що новий файл класу не буде збережено в проекті. Однак. Intellisense все-таки показав його синім кольором і дійсним у референційних проектах, навіть коли я намагався перекомпілювати файл, не був знайдений і отримав тип помилки не знайдено. Закриття та відкриття Visual Studio все ще показало проблему (але якщо я взяв до уваги, клас класу відсутній після повторного відкриття).

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

У мене було те саме питання. Одного разу вночі мій проект складе наступного ранку ПОМИЛКИ !.

Зрештою я з'ясував, що візуальна студія вирішила "підправити" деякі мої посилання і вказати їх деінде. наприклад:

System.ComponentModel.ISupportInitialize якось став "blahblah.System.ComponentModel.ISupportInitialize"

Досить груба річ для vs зробити, якщо ти як я

Це подія трапляється у Visual Studio 2017.

1. Перезапустіть Visual Studio
2. Чистий проект, який не вдалося створити.
3. Побудуйте проект.

Мій випадок був таким же, як обговорювалося тут, але нічого не вирішило, поки я не видалив System.Coreпосилання зі списку посилань (Все спрацювало нормально без нього)

сподіваюся, що це допоможе комусь, тому що це питання досить засмучує

Для вирішення цієї проблеми також можна допомогти видалити та відтворити *.sln.DotSettingsфайл пов'язаного рішення.

У моєму випадку у мене був клас, який був вказаний у відповідній папці джерела, але не був зареєстрований у Провідника рішень. Мені потрібно було клацнути правою кнопкою миші проект> Додати існуючий елемент і вручну вибрати той клас, який сказав, що він відсутній. Тоді все спрацювало нормально!

У моєму випадку проблема полягала в тому, що після зміни простору імен на такий самий, як і в іншому проекті (навмисно), назва збірки також була змінена VS, тому було дві збірки з такою ж назвою, одна переосмислила іншу

У моєму випадку у мене був файл, побудований за допомогою зовнішньої залежності (xsd2code), і якимось чином його файли дизайнера.cs не були правильно оброблені VS. Створення нового файлу у Visual Studio та вставлення коду в нього зробило для мене трюк.

Для тих, хто отримує цю помилку, коли намагається опублікувати свій веб-сайт на Azure, жодне з перспективних на сьогодні рішення не допомогло мені. Я був у тому ж човні - моє рішення будувало чудово самостійно. Мені довелося це робити

1. Видаліть усі нутеві пакети з мого рішення.
2. Закрийте і знову відкрийте моє рішення.
3. Повторне додавання всіх пакунків.

Трохи болісно, ​​але це був єдиний спосіб, коли я міг змусити свій веб-сайт публікувати в Azure.

Я отримав цю помилку, намагаючись створити збірку за допомогою збірки служб Team Visual Studio, яка працює на моїй локальній машині як агент.

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

Проблема DLL зберігалася в рамках проекту як Lib/MyDLL.DLLі посилається на це у файлі csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

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

У будь-якому випадку, якщо повідомлення, яке ви отримуєте, Could not resolve this reference. Could not locate the assemblyпереконайтеся, що DLL знаходиться в доступному для msbuild місці.

Я наче обдурив і знайшов повідомлення, яке сказав Considered "Reference\bin\xxx.dll"і просто скопіював замість цього місця.

У моєму випадку додавання dll в якості посилання дало значення type or namespace name could not be found помилку. Однак копіювання та вставлення файлу dll безпосередньо у папку бін вирішило помилку.

Поняття не маю, чому це спрацювало.

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

Скачайте цю допомогу :)

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

Я працював над версією спільноти VS 2017 і мав той самий випуск з нульовими пакетами CefSharp.

Пакети було завантажено та відновлено успішно, проект можна було скласти та успішно запустити - лише розмітка вказувала на те, що простори імен не розпізнані.

Все, що я повинен був зробити, це відкрити References розділ і натиснути на один із жовтих знаків оклику.

Через кілька секунд помилки розмітки відійшли.