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

Я знаю, что сообщение об ошибке является распространенным, и есть много вопросов об этой ошибке, но пока никакие решения мне не помогли, поэтому я решил задать вопрос. Отличие от большинства подобных вопросов заключается в том, что я использую каталог 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 (о которых мне известно), я не знаю, о какой сборке упоминается в сообщении об ошибке.

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

MyObjectType a = new MyObjectType("parameter");

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, мне не удалось решить проблему в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

к

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

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

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

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

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

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

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

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

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

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

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