Typ jest zdefiniowany w zestawie, do którego nie ma odwołania, jak znaleźć przyczynę?

Wiem, że komunikat o błędzie jest powszechny i ​​jest wiele pytań na temat SO dotyczących tego błędu, ale jak dotąd żadne rozwiązania nie pomogły, więc postanowiłem zadać pytanie. Różnica w stosunku do większości podobnych pytań polega na tym, że używam katalogu App_Code.

Komunikat o błędzie:

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'.

Plik źródłowy:

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

Postępując zgodnie z sugestiami tu i tutaj , usunąłem wszystkie wystąpienia Project.Rights.dll wewnątrz C: \ Windows \ Microsoft.NET /*.* Zgodnie z tym , sprawdziłem, czy dane pliki .cs mają akcję kompilacji ustawioną na "Kompiluj" . Robią. Sprawdziłem również dwukrotnie, czy plik .cs zawierający typ „Project.Rights.OperationsProvider” został wdrożony w katalogu App_Code.

Z jakiegoś powodu aplikacja nie szuka typu w katalogu App_Code. Ponieważ usunąłem wszystkie wystąpienia Project.Rights.dll (o których wiem), nie wiem, o którym zestawie wspomina komunikat o błędzie.

Kiedy pojawia się ten błąd, nie zawsze jest oczywiste, co się dzieje, ale jak mówi błąd - brakuje odniesienia. Jako przykład weźmy następujący wiersz kodu:

MyObjectType a = new MyObjectType("parameter");

Wygląda to dość prosto i prawdopodobnie poprawnie odwołałeś się do „MyObjectType”. Ale powiedzmy, że jedno z przeciążeń dla konstruktora „MyObjectType” przyjmuje typ, do którego się nie odwołujesz. Na przykład istnieje przeciążenie zdefiniowane jako:

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

To przynajmniej jeden przypadek, w którym pojawi się ten błąd. Dlatego poszukaj tego typu wzorca, w którym odwołałeś się do typu, ale nie do wszystkich typów właściwości lub parametrów metody, które są możliwe dla funkcji wywoływanych dla tego typu.

Miejmy nadzieję, że to przynajmniej poprowadzi Cię we właściwym kierunku!

Sprawdź ramy docelowe w projektach.

W moim przypadku „Musisz dodać odwołanie do zestawu” w rzeczywistości oznaczało, że projekty wywołujące i referencyjne nie mają tej samej struktury docelowej. Projekt wywołującego miał .Net 4.5, ale przywoływana biblioteka miała cel 4.6.1.

Jestem pewien, że kompilator MS może być mądrzejszy i rejestrować bardziej znaczący komunikat o błędzie. Dodałem sugestię do https://github.com/dotnet/roslyn/issues/14756

W moim przypadku było to spowodowane tym, że wykonanie aktualizacji pakietu NuGet spowodowało tylko zaktualizowanie odwołań do zależności dll w niektórych, ale nie we wszystkich projektach w moim rozwiązaniu, co spowodowało konflikt wersji. Używając narzędzia w stylu grep do wyszukiwania tekstu w plikach * .csproj w moim rozwiązaniu, łatwo było zobaczyć projekty, które nadal wymagały aktualizacji.

Gdy pojawi się ten błąd, oznacza to, że używany kod odwołuje się do typu, który znajduje się w zestawie, ale zestaw nie jest częścią projektu, więc nie może go użyć.

Usunięcie Project.Rights.dll jest przeciwieństwem tego, co chcesz. Musisz upewnić się, że projekt może odwoływać się do zestawu. Dlatego musi być umieszczony w Global Assembly Cache lub w katalogu ~ / Bin Twojej aplikacji internetowej.

Edycja - jeśli nie chcesz używać zestawu, usunięcie go również nie jest właściwym rozwiązaniem. Zamiast tego musisz usunąć wszystkie odniesienia do niego w swoim kodzie. Ponieważ zestaw nie jest bezpośrednio potrzebny przez napisany kod, ale zamiast tego przez coś innego, do którego się odwołujesz, będziesz musiał zastąpić ten zestaw, do którego się odwołujesz, czymś, co nie ma Project.Rights.dll jako zależności.

W moim przypadku odwoływałem się do biblioteki, która była budowana na niewłaściwej platformie / konfiguracji (właśnie utworzyłem bibliotekę, do której się odwołujesz).

Ponadto nie udało mi się rozwiązać problemu w programie Visual Studio Configuration Manager - nie mogę przełączyć i utworzyć nowych platform i konfiguracji dla tej biblioteki. Naprawiłem to, poprawiając wpisy w ProjectConfigurationPlatformssekcji .slnpliku dla tego projektu. Wszystkie jego permutacje zostały ustawione naDebug|Any CPU (nie jestem pewien, jak to zrobiłem). Nadpisałem wpisy dla zepsutego projektu tymi dla działającego projektu i zmieniłem identyfikator GUID dla każdego wpisu.

Wpisy do funkcjonującego projektu

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

Wpisy dotyczące uszkodzonego projektu

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

Naprawiono uszkodzone wpisy

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

Mam nadzieję, że to komuś pomoże.

Po prostu zdarzyło mi się, że różne projekty odwoływały się do różnych kopii tej samej biblioteki dll. Upewniłem się, że wszystkie odwoływały się do tego samego pliku na dysku, a błąd zniknął zgodnie z oczekiwaniami.

To nie zadziałało, gdy próbowałem dodać odwołanie z karty .NET Assemblies. Jednak zadziałało, gdy dodałem odniesienie z BROWSE do C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

Jedną z głównych przyczyn może być własność DLL, którą musisz wcześniej zrobić, aby sprawdzić, specific version propertyczy prawda jest fałszywa

Powód: być może kod źródłowy został dołączony do innej (starej) wersji podczas jej budowania, ale ta biblioteka została zaktualizowana o nową aktualizację, wersja jest teraz inna w specific version propertykasie zestawu , a aplikacja nie może pobierać nowej biblioteki DLL, a po wyłączeniu applacaten będzie darmowy aby uzyskać nową wersję referencji DLL

Być może używana biblioteka (plik DLL) wymaga innej biblioteki. W moim przypadku odwołałem się do biblioteki, która zawierała model jednostki bazy danych - ale zapomniałem odwołać się do biblioteki struktury jednostek.

Może to również oznaczać, że używasz biblioteki, która udostępnia (publiczne) typy zdefiniowane w bibliotece. Nawet jeśli nie używasz ich specjalnie w swojej bibliotece (tej, która nie buduje się).

To prawdopodobnie uniemożliwia pisanie kodu, który używa klasy (która w swoim podpisie ma typy z biblioteki, do których nie ma odniesienia), której nie możesz użyć.

Dla mnie powodem pojawienia się błędu było to, że formularz sieciowy, w którym zgłoszono błąd, został przeniesiony z innego folderu, ale nazwa jego klasy pliku kodowego pozostała niezmieniona i nie odpowiadała rzeczywistej ścieżce.

Stan początkowy:
Oryginalna ścieżka do pliku: /Folder1/Subfolder1/MyWebForm.aspx.cs Oryginalna nazwa klasy pliku kodu
: Folder1_Subfolder1_MyWebForm

Po przeniesieniu
pliku : Ścieżka do pliku: /Folder1/MyWebForm.aspx.cs Nazwa klasy pliku
kodu (niezmieniona, z wyświetlonym błędem): Folder1_Subfolder1_MyWebForm

Rozwiązanie:
Zmień nazwę swoją codefile klasę Folder1_Subfolder1_MyWebForm
do jednego odpowiadającego z nowej ścieżki :Folder1_MyWebForm

Wszystko naraz - problem rozwiązany, brak raportów o błędach.

Typ „Domain.tblUser” jest zdefiniowany w zestawie, do którego nie ma odwołania. Należy dodać odwołanie do zestawu „Domain, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null”.

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

Uwaga: upewnij się, że odniesienia są poprawne zgodnie z kontenerem DI

W moim przypadku to dlatego, że użyłem

Niejawny operator

między BLLa DALklasami. gdy chcę użyć BLLwarstwy w warstwie aplikacji, otrzymałem ten błąd. Zmieniłam

operator niejawny

do

jawny operator

będzie OK. Dzięki

W moim przypadku wersja biblioteki DLL, do której się odwołuje, była w rzeczywistości nowsza niż ta, którą miałem wcześniej.

Musiałem tylko wrócić do poprzedniej wersji i to naprawiło.

Dla mnie było to spowodowane tym, że projekt, zarówno bezpośrednio, jak i pośrednio (poprzez inną zależność), odwoływał się do dwóch różnych wersji Bouncy Castle, które miały różne nazwy zestawów. Jedna z kompilacji Bouncy Castle była pakietem NuGet, a druga była kompilacją debugowania źródła pobranego z GitHub. Oba były nominalnie wersją 1.8.1, ale ustawienia projektu kodu GitHub ustawiły nazwę zestawu na BouncyCastle, podczas gdy pakiet NuGet miał nazwę zestawu BouncyCastle.Crypto. Zmiana ustawień projektu, a tym samym wyrównanie nazw zespołów, rozwiązała problem.

Mam podobny problem i usuwam RuntimeFrameworkVersion, a problem został rozwiązany.

Spróbuj usunąć 1.1.1 lub

Miałem ten problem na nowo utworzonym rozwiązaniu, które wykorzystywało istniejące projekty. Z jakiegoś powodu jeden projekt nie mógł „zobaczyć” innego projektu, mimo że miał takie samo odniesienie jak każdy inny projekt, a projekt, do którego się odnosi, również był budowany. Podejrzewam, że nie udało mu się wykryć czegoś związanego z wieloma platformami docelowymi, ponieważ budował w jednym frameworku, ale nie w drugim.

Czyszczenie i odbudowywanie nie działały, a ponowne uruchamianie VS nie działało.

Ostatecznie zadziałało otwarcie „Developer Command Prompt for VS 2019”, a następnie wydanie msbuild MySolution.slnpolecenia. Zakończyło się to pomyślnie, a następnie VS również z powodzeniem rozpoczął budowę.

Wyczyść swoje rozwiązanie i odbuduj działało dla mnie (w programie Visual Studio są to opcje, które otrzymujesz po kliknięciu prawym przyciskiem myszy w eksploratorze rozwiązań), błąd zniknął w moim projekcie.