Тип определяется в сборке, на которую нет ссылок, как найти причину?

Question 1

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

Сообщение об ошибке:

CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Исходный файл:

c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs

Следуя предложениям здесь и здесь , я удалил все экземпляры Project.Rights.dll внутри C: \ Windows \ Microsoft.NET /*.* В соответствии с этим я проверил, установлены ли для рассматриваемых файлов .cs действие сборки «Компилировать» . Они делают. Я также дважды проверил, что файл .cs, содержащий тип «Project.Rights.OperationsProvider», развернут в каталоге App_Code.

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

Question 2

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

MyObjectType a = new MyObjectType("parameter");

Это выглядит достаточно просто, и вы, вероятно, правильно указали MyObjectType. Но, допустим, одна из перегрузок конструктора MyObjectType принимает тип, на который вы не ссылались. Например, существует перегрузка, определяемая как:

public MyObjectType(TypeFromOtherAssembly parameter) {
    // ... normal constructor code ...
}

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

Надеюсь, это, по крайней мере, направит вас в правильном направлении!

Question 3

Проверяйте целевую структуру в своих проектах.

В моем случае «Вы должны добавить ссылку на сборку» на самом деле означало, что у вызывающего и ссылочного проектов не одна и та же целевая структура. У вызывающего проекта был .Net 4.5, но у указанной библиотеки была цель 4.6.1.

Я уверен, что компилятор MS может быть умнее и записывать более содержательные сообщения об ошибках. Я добавил предложение на https://github.com/dotnet/roslyn/issues/14756

Question 4

В моем случае это было связано с тем, что при обновлении пакета NuGet были обновлены только ссылки на зависимость dll в некоторых, но не во всех проектах в моем решении, что приводило к конфликту версий. Используя инструмент в стиле grep для поиска текста в файлах * .csproj в моем решении, было легко увидеть проекты, которые все еще нуждались в обновлении.

Question 5

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

Удаление Project.Rights.dll - это противоположность тому, что вы хотите. Вам необходимо убедиться, что ваш проект может ссылаться на сборку. Поэтому он должен быть помещен либо в глобальный кэш сборок, либо в каталог ~ / Bin вашего веб-приложения.

Изменить: если вы не хотите использовать сборку, ее удаление также не является правильным решением. Вместо этого вы должны удалить все ссылки на него в своем коде. Поскольку сборка не нужна напрямую для написанного вами кода, а для чего-то еще, на что вы ссылаетесь, вам придется заменить эту сборку, на которую ссылаются, чем-то, что не имеет Project.Rights.dll в качестве зависимости.

Question 6

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

Кроме того, мне не удалось решить проблему в Visual Studio Configuration Manager - не удалось переключить и создать новые платформы и конфигурации для этой библиотеки. Я исправил это, исправив записи в ProjectConfigurationPlatformsразделе .slnфайла для этого проекта. Все его перестановки были установлены на Debug|Any CPU(я не уверен, как я это сделал). Я заменил записи для неработающего проекта на записи для рабочего проекта и изменил GUID для каждой записи.

Заявки на действующий проект

{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64 {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64

Записи для поврежденного проекта

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU

Исправлены поврежденные записи

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64 {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64

Я надеюсь, что это поможет кому-то.

Question 7

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

Question 8

У меня не получилось, когда я попытался добавить ссылку из вкладки .NET Assemblies. Однако это сработало, когда я добавил ссылку с BROWSE в C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

Question 9

одной из основных причин может быть свойство DLL, которое вы должны перед тем, как что-либо сделать, чтобы проверить, specific version propertyистинно ли оно, сделайте его ложным

Причина: возможно, исходный код соединен с другой (старой) версией при ее сборке, но эта библиотека обновлена с новым обновлением, версия теперь отличается в Assembly Cash, и вашему приложению запрещается получать новую DLL, и после отключения specific version propertyваш апплакатен будет бесплатным получить новую версию ссылок на DLL

Question 10

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

Question 11

Это также может означать, что вы используете библиотеку, которая предоставляет (общедоступные) типы, определенные в библиотеке. Даже если вы не используете их специально в своей библиотеке (той, которая не строится).

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

Question 12

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

Начальное состояние:
Исходный путь к файлу: /Folder1/Subfolder1/MyWebForm.aspx.cs Имя класса исходного кодового
файла: Folder1_Subfolder1_MyWebForm

После перемещения файла:
файла: Путь к файлу : /Folder1/MyWebForm.aspx.cs Имя класса файла
кода (без изменений, с отображаемой ошибкой): Folder1_Subfolder1_MyWebForm

Решение:
переименуйте свой класс кодового файлаFolder1_Subfolder1_MyWebForm
к одному соответствующим с новым путем :Folder1_MyWebForm

Все сразу - проблема решена, ошибок нет ..

Question 13

Тип «Domain.tblUser» определен в сборке, на которую нет ссылки. Вы должны добавить ссылку на сборку «Домен, Версия = 1.0.0.0, Культура = нейтральный, PublicKeyToken = null».

**Solved:**
 Add reference of my domain library layer to my web app libary layer

Примечание: убедитесь, что ваши ссылки верны в соответствии с вашим контейнером DI.

Question 14

В моем случае это было потому, что я использовал

Неявный оператор

между BLLи DALклассами. когда я хочу использовать BLLLayer In Application Layer, я получил эту ошибку. я изменил

неявный оператор

к

явный оператор

все будет хорошо. благодаря

Question 15

В моем случае указанная версия DLL была на самом деле новее, чем та, что была у меня раньше.

Мне просто нужно было вернуться к предыдущему выпуску, и это исправило.

Question 16

Для меня это было вызвано тем, что проект как прямо, так и косвенно (через другую зависимость) ссылался на две разные сборки Bouncy Castle, которые имели разные имена сборок. Одна из сборок Bouncy Castle была пакетом NuGet, другая - отладочной сборкой исходного кода, загруженного с GitHub. Оба были номинально версией 1.8.1, но в настройках проекта кода GitHub в качестве имени сборки задано BouncyCastle, тогда как у пакета NuGet имя сборки BouncyCastle.Crypto. Изменение настроек проекта, таким образом, выравнивание названий сборок, устранило проблему.

Question 17

У меня аналогичная проблема, и я удаляю RuntimeFrameworkVersion, и проблема устранена.

Попробуйте удалить 1.1.1 или

Question 18

У меня была эта проблема с недавно созданным решением, в котором использовались существующие проекты. По какой-то причине один проект не мог «видеть» другой проект, даже если он имел ту же ссылку, что и любой другой проект, и проект, на который он ссылается, также строился. Я подозреваю, что ему не удавалось обнаружить что-то, связанное с несколькими целевыми фреймворками, потому что он строился в одном фреймворке, а не в другом.

Очистка и восстановление не сработали, а перезапуск VS не помог.

В итоге сработало открытие «Командной строки разработчика для VS 2019», а затем выдача msbuild MySolution.slnкоманды. Это завершилось успешно, и впоследствии VS также начал успешно строить.

Question 19

Очистка вашего решения и перестройка сработали для меня (в Visual Studio это параметры, которые вы получаете, щелкнув правой кнопкой мыши в проводнике решений), ошибка исчезла в моем проекте.

Answer 1

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

Сообщение об ошибке:

CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Исходный файл:

c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs

Следуя предложениям здесь и здесь , я удалил все экземпляры Project.Rights.dll внутри C: \ Windows \ Microsoft.NET /*.* В соответствии с этим я проверил, установлены ли для рассматриваемых файлов .cs действие сборки «Компилировать» . Они делают. Я также дважды проверил, что файл .cs, содержащий тип «Project.Rights.OperationsProvider», развернут в каталоге App_Code.

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

Answer 2

6

Вы используете класс (скажем, A ), который предоставляет метод / свойство / что-то типа Project.Rights.OperationsProvider. Компилятору нужно знать, что это такое, тогда он будет искать эту сборку (Project.Rights). Если он не находит его (потому что у вас нет ссылки на него в проекте вашего веб-сайта) ... вы получите эту ошибку. Решение: НЕ удаляйте эту сборку из вашей системы !!! ДОБАВИТЬ ссылку на него.

Адриано Репетти

Answer 3

2

Попробуйте перейти к инструментам - параметрам - проектам и решениям - сборке и запуску - установите для обоих подробностей значение «Подробно». Это расскажет вам, что это за зависимость и где компилятор ее ищет.

данлудвиг

Answer 4

100

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

MyObjectType a = new MyObjectType("parameter");

Это выглядит достаточно просто, и вы, вероятно, правильно указали MyObjectType. Но, допустим, одна из перегрузок конструктора MyObjectType принимает тип, на который вы не ссылались. Например, существует перегрузка, определяемая как:

public MyObjectType(TypeFromOtherAssembly parameter) {
    // ... normal constructor code ...
}

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

Надеюсь, это, по крайней мере, направит вас в правильном направлении!

drew_w
источник

16

Примечание о методах расширения: если два класса имеют методы расширения с одинаковыми именами, параметры одного типа могут «заразить» использование метода расширения другого типа.

Athari

@Athari, спасибо, я бы никогда не догадался об этом

Дэйв Кузино

Просто случайно наткнулся на этот ответ после некоторого времени поисков. Это как раз моя проблема, и ваше объяснение было очень полезным. Спасибо огромное.

Дайан

1

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

Роберт Ягар

1

Это кажется действительно странным, но я получил эту ошибку, потому что у меня было несоответствие в случае одного из имен сборок (похоже, в nuget учитывается регистр?)! У меня была справочная библиотека C библиотеки B и A. Библиотека B также ссылалась на библиотеку A, но упаковала A как зависимость, используя имя «a», а не «A». Создавая библиотеку C, я продолжал получать эту ошибку, пока не исправил имя зависимости в B!

Толу

Answer 5

16

Примечание о методах расширения: если два класса имеют методы расширения с одинаковыми именами, параметры одного типа могут «заразить» использование метода расширения другого типа.

Athari

Answer 6

@Athari, спасибо, я бы никогда не догадался об этом

Дэйв Кузино

Answer 7

Просто случайно наткнулся на этот ответ после некоторого времени поисков. Это как раз моя проблема, и ваше объяснение было очень полезным. Спасибо огромное.

Дайан

Answer 8

1

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

Роберт Ягар

Answer 9

1

Это кажется действительно странным, но я получил эту ошибку, потому что у меня было несоответствие в случае одного из имен сборок (похоже, в nuget учитывается регистр?)! У меня была справочная библиотека C библиотеки B и A. Библиотека B также ссылалась на библиотеку A, но упаковала A как зависимость, используя имя «a», а не «A». Создавая библиотеку C, я продолжал получать эту ошибку, пока не исправил имя зависимости в B!

Толу

Answer 10

Проверяйте целевую структуру в своих проектах.

В моем случае «Вы должны добавить ссылку на сборку» на самом деле означало, что у вызывающего и ссылочного проектов не одна и та же целевая структура. У вызывающего проекта был .Net 4.5, но у указанной библиотеки была цель 4.6.1.

Я уверен, что компилятор MS может быть умнее и записывать более содержательные сообщения об ошибках. Я добавил предложение на https://github.com/dotnet/roslyn/issues/14756

Answer 11

16

В моем случае это было связано с тем, что при обновлении пакета NuGet были обновлены только ссылки на зависимость dll в некоторых, но не во всех проектах в моем решении, что приводило к конфликту версий. Используя инструмент в стиле grep для поиска текста в файлах * .csproj в моем решении, было легко увидеть проекты, которые все еще нуждались в обновлении.

Роджерсиллито
источник

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

Ryanman

3

В окне диспетчера пакетов Visual Studio для решения (не для отдельного проекта) есть вкладка « Консолидировать », на которой показано, какие пакеты имеют разные версии в разных проектах. Это явно лучше, чем инструмент, похожий на grep

Майкл Фрейдгейм

Answer 12

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

Ryanman

Answer 13

3

В окне диспетчера пакетов Visual Studio для решения (не для отдельного проекта) есть вкладка « Консолидировать », на которой показано, какие пакеты имеют разные версии в разных проектах. Это явно лучше, чем инструмент, похожий на grep

Майкл Фрейдгейм

Answer 14

7

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

Удаление Project.Rights.dll - это противоположность тому, что вы хотите. Вам необходимо убедиться, что ваш проект может ссылаться на сборку. Поэтому он должен быть помещен либо в глобальный кэш сборок, либо в каталог ~ / Bin вашего веб-приложения.

Изменить: если вы не хотите использовать сборку, ее удаление также не является правильным решением. Вместо этого вы должны удалить все ссылки на него в своем коде. Поскольку сборка не нужна напрямую для написанного вами кода, а для чего-то еще, на что вы ссылаетесь, вам придется заменить эту сборку, на которую ссылаются, чем-то, что не имеет Project.Rights.dll в качестве зависимости.

каменщик
источник

2

Я не могу использовать сборку, это требование. Мне нужно избавиться от него и сохранить класс в каталоге App_Code. Я знаю, как это звучит, поверьте. Получать задание изменить приложение таким образом, чтобы вся бизнес-логика хранилась внутри App_Code, а не в библиотеках DLL ... - это не весело.

afaf12

1

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

Адриано Репетти

У меня было подобное, и ваш пост очень помог. В моем случае у меня была ссылка на сборку «А». В этой сборке использовалась другая сборка «B». Я все время получал ошибку, что сборка «B» отсутствует, хотя я добавил ее в свой проект. Как только я скопировал сборку «B» в свой каталог bin, проблема была решена. Причина в том, что в моем проекте не использовалась сборка «B», а использовалась сборка «A», но она не нашла ее и, таким образом, выдала исключение. Благодарю.

ykh

Answer 15

2

Я не могу использовать сборку, это требование. Мне нужно избавиться от него и сохранить класс в каталоге App_Code. Я знаю, как это звучит, поверьте. Получать задание изменить приложение таким образом, чтобы вся бизнес-логика хранилась внутри App_Code, а не в библиотеках DLL ... - это не весело.

afaf12

Answer 16

1

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

Адриано Репетти

Answer 17

У меня было подобное, и ваш пост очень помог. В моем случае у меня была ссылка на сборку «А». В этой сборке использовалась другая сборка «B». Я все время получал ошибку, что сборка «B» отсутствует, хотя я добавил ее в свой проект. Как только я скопировал сборку «B» в свой каталог bin, проблема была решена. Причина в том, что в моем проекте не использовалась сборка «B», а использовалась сборка «A», но она не нашла ее и, таким образом, выдала исключение. Благодарю.

ykh

Answer 18

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

Кроме того, мне не удалось решить проблему в Visual Studio Configuration Manager - не удалось переключить и создать новые платформы и конфигурации для этой библиотеки. Я исправил это, исправив записи в ProjectConfigurationPlatformsразделе .slnфайла для этого проекта. Все его перестановки были установлены на Debug|Any CPU(я не уверен, как я это сделал). Я заменил записи для неработающего проекта на записи для рабочего проекта и изменил GUID для каждой записи.

Заявки на действующий проект

{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64 {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64

Записи для поврежденного проекта

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU

Исправлены поврежденные записи

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64 {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64

Я надеюсь, что это поможет кому-то.

Answer 19

Для меня это было похоже. VIsual Studio изменила идентификаторы GUID для некоторых моих проектов с FAE04EC0-301F-11D3-BF4B-00C04F79EFBC(C #) на 9A19103F-16F7-4668-BE54-9A1E7A4F7556(ASP.NET). После того, как я вернул их обратно, все пошло хорошо.

scor4er

Answer 20

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

Answer 21

У меня не получилось, когда я попытался добавить ссылку из вкладки .NET Assemblies. Однако это сработало, когда я добавил ссылку с BROWSE в C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

Answer 22

одной из основных причин может быть свойство DLL, которое вы должны перед тем, как что-либо сделать, чтобы проверить, specific version propertyистинно ли оно, сделайте его ложным

Причина: возможно, исходный код соединен с другой (старой) версией при ее сборке, но эта библиотека обновлена с новым обновлением, версия теперь отличается в Assembly Cash, и вашему приложению запрещается получать новую DLL, и после отключения specific version propertyваш апплакатен будет бесплатным получить новую версию ссылок на DLL

Answer 23

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

Answer 24

Это также может означать, что вы используете библиотеку, которая предоставляет (общедоступные) типы, определенные в библиотеке. Даже если вы не используете их специально в своей библиотеке (той, которая не строится).

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

Answer 25

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

Начальное состояние:
Исходный путь к файлу: /Folder1/Subfolder1/MyWebForm.aspx.cs Имя класса исходного кодового
файла: Folder1_Subfolder1_MyWebForm

После перемещения файла:
файла: Путь к файлу : /Folder1/MyWebForm.aspx.cs Имя класса файла
кода (без изменений, с отображаемой ошибкой): Folder1_Subfolder1_MyWebForm

Решение:
переименуйте свой класс кодового файлаFolder1_Subfolder1_MyWebForm
к одному соответствующим с новым путем :Folder1_MyWebForm

Все сразу - проблема решена, ошибок нет ..

Answer 26

Тип «Domain.tblUser» определен в сборке, на которую нет ссылки. Вы должны добавить ссылку на сборку «Домен, Версия = 1.0.0.0, Культура = нейтральный, PublicKeyToken = null».

**Solved:**
 Add reference of my domain library layer to my web app libary layer

Примечание: убедитесь, что ваши ссылки верны в соответствии с вашим контейнером DI.

Answer 27

В моем случае это было потому, что я использовал

Неявный оператор

между BLLи DALклассами. когда я хочу использовать BLLLayer In Application Layer, я получил эту ошибку. я изменил

неявный оператор

к

явный оператор

все будет хорошо. благодаря

Answer 28

В моем случае указанная версия DLL была на самом деле новее, чем та, что была у меня раньше.

Мне просто нужно было вернуться к предыдущему выпуску, и это исправило.

Answer 29

Для меня это было вызвано тем, что проект как прямо, так и косвенно (через другую зависимость) ссылался на две разные сборки Bouncy Castle, которые имели разные имена сборок. Одна из сборок Bouncy Castle была пакетом NuGet, другая - отладочной сборкой исходного кода, загруженного с GitHub. Оба были номинально версией 1.8.1, но в настройках проекта кода GitHub в качестве имени сборки задано BouncyCastle, тогда как у пакета NuGet имя сборки BouncyCastle.Crypto. Изменение настроек проекта, таким образом, выравнивание названий сборок, устранило проблему.

Answer 30

1

Я предлагаю вам сделать свой ответ более полезным, объяснив, как вы его исправили.

Стивен Кеннеди

Answer 31

У меня аналогичная проблема, и я удаляю RuntimeFrameworkVersion, и проблема устранена.

Попробуйте удалить 1.1.1 или

Answer 32

У меня была эта проблема с недавно созданным решением, в котором использовались существующие проекты. По какой-то причине один проект не мог «видеть» другой проект, даже если он имел ту же ссылку, что и любой другой проект, и проект, на который он ссылается, также строился. Я подозреваю, что ему не удавалось обнаружить что-то, связанное с несколькими целевыми фреймворками, потому что он строился в одном фреймворке, а не в другом.

Очистка и восстановление не сработали, а перезапуск VS не помог.

В итоге сработало открытие «Командной строки разработчика для VS 2019», а затем выдача msbuild MySolution.slnкоманды. Это завершилось успешно, и впоследствии VS также начал успешно строить.

Answer 33

Очистка вашего решения и перестройка сработали для меня (в Visual Studio это параметры, которые вы получаете, щелкнув правой кнопкой мыши в проводнике решений), ошибка исчезла в моем проекте.

Тип определяется в сборке, на которую нет ссылок, как найти причину?

Ответы:

Проверяйте целевую структуру в своих проектах.