Простір імен не розпізнається (навіть якщо він є)


145

Я отримую цю помилку:

Не вдалося знайти ім’я типу або простору імен "AutoMapper" (не вистачає директиви чи посилання на збірку?)

Найсмішніше, що я вже маю таку посилання у своєму проекті:

ProjectThatFails

І це мій код:

using System.Collections.Generic;
using DataContract;
using SelectorDAL;
using AutoMapper;

namespace SpecimenSelect
{
    public class SpecimenSelect : ISpecimenSelect
    {
        public SpecimenSelect()
        {
            SetupMaps();
        }

        private static void SetupMaps()
        {
            Mapper.CreateMap<SpecimenDetail, SpecimenDetailContract>();
        }

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

Ось знімок екрана одного:

ProjectThatWorks

і ось цей код (який складається добре):

using System.Collections.Generic;
using AutoMapper;
using DataContract;
using SelectorDAL;

namespace PatientSelect
{

    public class PatientSelect : IPatientSelect
    {
        public PatientSelect()
        {
            SetupMaps();
        }

        private void SetupMaps()
        {
            Mapper.CreateMap<Patient, PatientContract>();
            Mapper.CreateMap<OrderedTest, OrderedTestsContract>();
            Mapper.CreateMap<Gender, GenderContract>();
        }

Здається, обидві посилання мають однакові дані на сторінці властивостей.

Що я пропускаю?

Я намагався:

  1. Перезапуск Visual Studio
  2. Посилання без використання оператора (тобто AutoMapper.Mapper.CreateMap)
  3. Очистіть і відновіть

Будь-які інші ідеї?


1
Чи опорний шлях невірний? Можливо, він був доданий абсолютним шляхом, але DLL з тих пір переміщено?
kevingessner

Відповіді:


259

Переконайтеся, що ваш проект не налаштований на використання профілю клієнта .NET Framework 4.

Ви можете перевірити / змінити це, клацнувши правою кнопкою миші проект (не рішення), виберіть Властивості -> Застосування -> Цільова рамка . Цільова рамка - це спадне меню на цій сторінці.

Це проблема у Visual Studio (я б навіть зайшов так далеко, щоб назвати це помилка). AutoMapper вимагає збірок, які виключаються з профілю клієнта .NET Framework 4. Оскільки ваш проект використовує цю версію фреймворку, він порушується.

Аналогічна помилка пошириться на процес збирання, коли версія .NET Framework для проекту, на який ви посилаєтеся, вище, ніж проект, що робить посилання. тобто проект, націлений на 4.5, на який посилається проект, націлений на 4.5.1, дасть вам таку саму помилку.

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


7
Саме в цьому і полягала проблема! Дякую тобі! Я згоден, що ця помилка є дуже оманливою. Я також не розумію, чому профіль нового клієнта є типовим для нового проекту. Більшість комп'ютерів матимуть повний .net-фреймворк? (Або MS просто поставила клієнтську рамку на оновлення Windows?) У будь-якому випадку всі комп'ютери, для яких я розробляю, матимуть повний фреймворк. Я хотів би, щоб був новий спосіб змінити за замовчуванням для нового проекту, щоб він не кусав мене, як це було. Все одно. Знову дякую! Я застряг і не думав шукати там.
Ваккано

У мене була точно така ж проблема! Типи не були розпізнані в моєму сервісному проекті Windows, навіть якщо я правильно додав посилання. Я змінив цільову рамку з .NET Framework 4 профілю клієнта на .NET Framework 4. Зауважте, що мені також довелося повторно додати свої посилання, щоб зробити його компільованим. Здається, це проблема у Visual Studio 2010. Дякуємо та вітаємо з Будапешта.
Варга Тамас

Добре, це трапилось і зі мною. Мій тестовий проект не розпізнавав згадані простори імен, хоча вони там були. Це було тому, що я змінив свою бібліотеку на платформу .NET 4.5, але тестовий проект залишився як 4.0. У будь-якому випадку, ваша відповідь веде мене на правильний шлях. Дякую, що вияснили це.
Jukka Puranen

Я зіткнувся з тією ж проблемою, коли я намагався використовувати .Net 2.0 збірку в проекті профілю клієнта .Net 3.5. і перехід на 3,5 повного профілю вирішує проблему.
Палані

Моє питання було подібним. Проекти використовували різні версії Framework. Основний проект використовував 4.5, а новостворений проект використовував 4.5.1. Було б добре, якби повідомлення про помилку було краще.
L_7337

27

Дозвольте мені задати дурне запитання: Чи можуть бути два файли automapper.dll ? Один із AutoMapperпростором імен і один без? Підтвердіть шляхи в обох проектах.

Я також помітив, що порядок usingкоманд різний. Це не має значення, але ви намагалися перемістити їх?


18

Якщо ваш клас не складається, навіть якщо він є в проекті, перевірте такі:

  1. чи однакове ім’я класу
  2. чи точно такий же простір імен
  3. чи властивості класу показують дії збірки = компілювати

6
Я скопіював .cs-файл із Explorer, а потім включив його до проекту. VS.Net встановив дію збірки як "Вміст" замість "Компілювати", тому не розпізнавав простір імен. Гарний улов!
AUSteve

1
Я додав клас за допомогою функції Add -> Class, і він встановив дію збірки на вміст. Просто цікаво, чому? Це мені все одно допомогло, щось таке просте, але ніколи раніше не зустрічалося. Ось чому я навіть не потурбувався шукати там, а замість цього погуглив його.
Аномалія

14

Це повинно бути найпростішим рішенням, якщо всі інші відповіді вам не допомагають

Я шукав, що не так у моєму налаштуванні, серед відповідей, випробував їх усіх - жоден не працював, тоді я зрозумів, що Visual Studio 2018 був розроблений Microsoft . Тому я зробив те, що робить більшість людей,

Перевтілена візуальна студія і вона спрацювала


Працював для мене, але видалив папку bin та obj перед перезавантаженням.
Chandan YS

За всі мої роки на stackoverflow це найкраща солона відповідь на помилку (яка насправді забезпечує рішення), і вона працювала при першому перезапуску. безсоння ftw!
Collin White

12

Я вирішив цю проблему, клацнувши правою кнопкою миші на папці, що містить файли, і вибрав « Виключити з проекту», а потім ще раз клацнути правою кнопкою миші та вибравши « Включити у проект» (спочатку потрібно включити Показувати всі файли, щоб вилучена папка була видимою)


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

Клацніть правою кнопкою миші на що? "Виключити з проекту" видаляє папку з Explorer Explorer. Немає "Включити у проект"
Флоріан, зима

2
@FlorianWinter Щоб натиснути правою кнопкою миші виключену папку, вам потрібно ввімкнути Показати всі файли . Це можна ввімкнути за допомогою Провідника рішень, він знаходиться поруч із кнопкою Згорнути все .
користувач3251328

Не знаю чому, але це спрацювало у VS2019, коли я додав у проект новий файл, що містить новий клас, але не зміг створити новий екземпляр цього класу в іншому проекті, який уже мав посилання на проект, що містить новий клас. ..¯\_(ツ)_/¯
matt.fc

7

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

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


2
Це було проблемою і для нас, і саме довжина шляху була причиною проблеми. Компанія VS повинна зробити кращу роботу з надання кращої помилки в цьому випадку, оскільки помилка, яку ми отримали, була досить оманливою.
VoodooChild

Завдяки вашій відповіді на думку прийшла ідея. Я переглянув шлях свого проекту і зрозумів, що коренева папка, створена деревом-джерелом, має "% 20" замість _ у імені. Я змінив його на _ і зараз все працює нормально.
Фернандо

5

У моєму випадку посилання на dll було побудовано у вищій версії .Net Framework. Після того, як я додав посилання, я міг його використовувати. Але як тільки я зробив збірку, з'явиться помилка "відсутня посилання". Я оновлюю dll, помилка піде, але вона ніколи не будуватиметься. Ця публікація змусила мене перевірити рамкову версію, і, таким чином, я міг її вирішити, побудувавши проект, що посилається на цю ж версію.


3

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

Я зіткнувся з цим під час використання VS 2005, можна було б очікувати, що МС вже зараз вирішить цю конкретну проблему ..


ви могли б виправити це питання?
Fran_gg7

3

Питання вже присуджено, але є ще не описані додаткові деталі, які потрібно перевірити.

У мене теж була така поведінка, де проект B посилався на проект A, але простір імен проекту B не було розпізнано в проекті A. Після деякого копання я виявив, що шлях був занадто довгим. Зменшуючи шлях проектів (і A, і B), посилання стали видимими та доступними.

Я перевірив цю теорію, створивши проект C на значно меншій глибині шляху. Я посилався на проект C у проекті А. Посилання працювали правильно, як очікувалося. Потім я видалив проект C з рішення, просто перемістив проект C на глибокий шлях, такий же, як проект B, і додав проект C назад до рішення, і спробував скласти. Тоді я більше не мав видимості проектувати об’єкти C.


2

У моєму випадку я скопіював бібліотеку класів, і не змінив "Назва збірки" у властивостях проекту, тому одна DLL перезаписала іншу ...


2

Це сталося зі мною у Visual Studio 2019. Для мене я намагався посилатися на інший проект у своєму рішенні. Ось такі кроки, які я вжив, якщо це допомагає комусь іншому:

  1. Переконайтеся, що проект, на який я хотів посилатися, перелічений у розділі Посилання
  2. Переконайтеся, що обидва проекти використовували правильну версію .NET Framework
  3. Побудували проект (натиснув зелену стрілку "Пуск")

Я був розгублений, тому що я все-таки отримував помилку після кроків 1 і 2, але побудова проекту, здавалося, усунула його.


1

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


1

У моєму випадку я отримав помилку лише у VS 2015. Під час відкриття проекту у VS 2017 помилка не була.


1

Божевільний. Я знаю.

Тут спробували всі варіанти. Перезапуск, чистка, перевірка вручну в створених DLL-файлах (це безцінне для розуміння, чи насправді ви самі зіпсували)

Я змусив його працювати, встановивши для Verbosity MSBuild значення "Детально" у параметрах.


для мене це була конфігурація збірки, встановлена ​​AnyCpu на PlatformTarget, коли ім'я конфігурації було x86. Ця настройка допомогла мені це з’ясувати.
Дбл

1

На це питання вже відповіли за оригінальний плакат, але якщо хтось стикається з цим у проекті MS-Test:

у візуальній студії виберіть меню Тест -> Налаштування тестування -> Архітектура процесора за замовчуванням та переконайтесь, що архітектура відповідає тій іншій збірці, на яку ви посилаєтесь. Якщо інша збірка - x64, а ваші тестові налаштування - x86, ви можете відчути симптоми, які мали оригінальний плакат.


0

Я працював над проектом Xamarin, і як завжди, видаливши папку obj і перебудувавши проблему, простір імен, який мій VS не розпізнавав, був кодом у моєму власному проекті BTW



0

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

Простір імен, який не вдалося вирішити в моєму випадку, був Company.Project.Common.Models.EF . Я додав файл у новому просторі імен Company.Project.BusinessLogic.Common .

Більшість файлів мали а

using Company.Project;

А потім посилання на моделі як Common.Models.EF . Усі файли, які також мали

using Company.Project.BusinessLogic;

Не вдалося, оскільки VS не міг визначити, який простір імен використовувати.

Рішення полягало в тому, щоб змінити другий простір імен на Company.Project.BusinessLogic.CommonServices


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.