Тип визначається у збірці, на яку немає посилань. Як знайти причину?

Я знаю, що повідомлення про помилку є загальним, і в SO є багато запитань щодо цієї помилки, але досі мені не допомогли рішення, тому я вирішив поставити запитання. Різниця в більшості подібних питань полягає в тому, що я використовую каталог 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 Assembly. Однак це спрацювало, коли я додав посилання з BROWSE до C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

однією з головних причин може бути властивість DLL, яку потрібно виконати перед тим, як зробити будь-яку річ, щоб перевірити, specific version propertyчи відповідає вона істині, помилково

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

Можливо, бібліотеці (файлу DLL), яку ви використовуєте, потрібна інша бібліотека. У моєму випадку я посилався на бібліотеку, яка містила модель сутності бази даних, але я забув посилатися на бібліотеку фреймворку сутності.

Це також може означати, що ви використовуєте бібліотеку, яка надає (загальнодоступні) типи, визначені в бібліотеці. Навіть коли ви не використовуєте їх спеціально у своїй бібліотеці (тій, яка не будується).

Це, напевно, заважає писати код, який використовує клас (який у своєму підписі має типи з бібліотеки, на які не посилається), який ви не можете використовувати.

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

Початковий стан:
Оригінальний шлях до файлу: /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 = нуль".

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

Примітка: Переконайтесь, що ваші посилання правильні відповідно до вашого контейнера DI

У моєму випадку це було тому, що я використовував

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

між BLLі DALкласами. коли я хочу використовувати BLLшар у рівні програм, я отримав цю помилку. я змінив

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

до

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

це буде добре. Дякую

У моєму випадку версія dll, на яку посилався, була насправді новішою, ніж та, що була у мене раніше.

Мені просто потрібно було повернутися до попереднього випуску, і це виправило.

Для мене це було викликано проектом як прямо, так і опосередковано (через іншу залежність), що посилається на дві різні споруди Надувного замку, які мали різні назви збірок. Однією з збірок 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 це параметри, які ви отримуєте, клацнувши правою кнопкою миші у своєму провіднику рішень), у моєму проекті помилки немає