Chcę przetestować podstawową klasę wtyczki, bezpośrednio odwołując się do projektu wtyczki i tworząc instancję klasy wtyczki. Kiedy tworzę testowy projekt aplikacji konsoli i dodam odniesienie do projektu do projektu wtyczki, pojawia się ikona ostrzegawcza (żółty trójkąt z wykrzyknikiem) obok odniesienia na liście Odnośniki.
Gdy zamiast tego dodaję odwołanie do biblioteki DLL, asemblera zestawu danych wyjściowych wtyczki, nie otrzymuję takiego ostrzeżenia. Co to ostrzeżenie może mi powiedzieć?
.net
mef
project-reference
ProfK
źródło
źródło
Odpowiedzi:
Jak wspomniano w komentarzach do pytania, może to powodować różne wersje .NET Framework między projektami. Sprawdź właściwości nowego projektu, aby upewnić się, że nie jest używana inna domyślna wersja.
źródło
Napotkano ten sam problem z aplikacją sieci Web ASP.Net i dwoma projektami klasy bibliotecznej, do których należało się odwoływać w aplikacji sieci Web. Nie podałem żadnych informacji o tym, dlaczego kompilacja nie powiodła się, a odwołania były nieprawidłowe.
Rozwiązaniem było zapewnienie, że wszystkie projekty miały takie same ramy docelowe:
W Visual Studio 2015- Kliknij prawym przyciskiem myszy projekt> Właściwości> Aplikacja> Struktura docelowa
Zapisz, wyczyść i przebuduj rozwiązanie. Odniesienia do projektu nie powinny już pojawiać się jako żółte ostrzeżenia, a rozwiązanie zostanie skompilowane.
Moja aplikacja sieciowa była ukierunkowana na .Net 4.5, podczas gdy dwa pozostałe zależne projekty klas bibliotek były ukierunkowane na .Net v4.5.2
źródło
W przypadku obu (lub wszystkich) projektów, których chcesz używać razem:
Kliknij prawym przyciskiem myszy projekt> Właściwości> Aplikacja> Docelowa platforma .NET
Upewnij się, że oba (lub wszystkie) projekty korzystają z tej samej wersji środowiska .NET.
źródło
za. Przejdź do Narzędzia> Menedżer pakietów Nuget> Typ konsoli Menedżera pakietów Aktualizacja-Pakiet-Ponowna instalacja (jeśli nie działa, przejdź do 2.b )
b. JEST TO KRYTYCZNE, ALE NAJWIĘKSZA MOŻLIWOŚĆ, KTÓRA DZIAŁA . Usuń <Target> Może z wieloma liniami </ Target> zwykle znajdującymi się w dolnej części .csproj.
Zapisz, załaduj i skompiluj rozwiązanie.
źródło
Ponownie zainstaluj wszystkie pakiety we wszystkich projektach bieżącego rozwiązania:
źródło
Upewnij się, że masz projekty kierowane na tę samą wersję frameworka . Najczęściej przyczyną jest to, że bieżący projekt (w którym dodajesz odniesienie do innego projektu) wskazuje inną wersję frameworku .net niż pozostałe .
źródło
Sprawdź NETFramework odnośnej biblioteki DLL i projektu, do którego dodajesz bibliotekę DLL. Np .: DLL ==> obsługiwane Wersja środowiska wykonawczego = „v4.0” Projekt ==> obsługiwane wersja środowiska wykonawczego = „v3.0”
Otrzymasz ikonę ostrzeżenia. Rozwiązanie: Zapewnij spójność wersji biblioteki DLL.
źródło
Dla mnie napotkałem ten problem, odwołując się do biblioteki klas .NET Standard 2.0 w aplikacji konsolowej .NET Framework 4.7.1. Tak, frameworki są różne, ale są kompatybilne (.NET Standard powinien jive zarówno z .NET Core, jak i .NET Framework.) Próbowałem wyczyścić, przebudować, usunąć i odczytać referencje projektu itp. Bez powodzenia . Wreszcie zamknięcie programu Visual Studio i ponowne otwarcie rozwiązało problem.
źródło
Minęło dużo czasu, odkąd zadano to pytanie, ale jeśli ktoś jest nadal zainteresowany - ostatnio natrafiłem na podobne ikony. Kompilowałem projekt C # .net przy użyciu VS 2008. Odkryłem, że VS nie może zlokalizować zestawów dla tych odniesień. Po dwukrotnym kliknięciu VS odświeżyłem referencje i usunąłem ikony na niektórych z nich [EDYCJA: którą Mógł TERAZ zlokalizować]. Dla pozostałych odniesień musiałem skompilować odpowiednie zespoły.
źródło
Dodając moje 2 centy do odpowiedzi @ kad81,
Przejdź do Visual Studio -> BUILD -> Configuration Manager
W rozwijanej „Aktywnej platformie rozwiązań” w prawym górnym rogu (moja wersja to VS 2012), jeśli jest to „Platformy mieszane”, zmień ją na odpowiednią platformę w oparciu o referencyjne zespoły stron trzecich.
Następnie w każdym projekcie na liście upewnij się, że wybierasz tę samą platformę dla całego projektu. (jeśli x86 nie istnieje, wybierz „”, a następnie możesz wybrać „x86”.)
Najpierw przebuduj projekty bibliotek, a następnie odwołuj się do projektów. Mam nadzieję że to pomoże.
źródło
Spróbuj zamknąć i otworzyć VS.
Wydaje się głupie, ale po 1 godzinie podążania za powyższym i znalezieniu wszystkiego w porządku. Zrestartowałem VS 2017 i problemy zniknęły.
źródło
W Asp.net Core czasami wyświetla alert, jeśli zmienisz przestrzeń nazw lub nazwę projektu. Aby usunąć tego rodzaju alerty, po prostu zwolnij projekt i załaduj go ponownie. Jeśli problem nadal występuje, oznacza to, że nie można znaleźć numeru referencyjnego zespołu.
źródło
Te ikony miałem z innego powodu. Mamy jedno duże rozwiązanie dla wszystkich naszych projektów (prawie 100). Dokonałem podselekcji projektów, którymi byłem zainteresowany i stworzyłem nowe rozwiązanie. Jednak referencje, w których referencje projektów zamiast referencji do skompilowanych bibliotek dll ...
Po kilku badaniach znalazłem ten link na GitHub który wyjaśnia, że jest to nowe zachowanie w VS2015.
Na stronie GitHub wyjaśniają obejście dotyczące konwertowania odwołań do projektów na odwołania binarne.
źródło
Aby naprawić niektóre niedziałające rzeczy, warto je usunąć czasami niektóre biblioteki, jak by to nie brzmiało dziwnie.
W każdym razie uważam, że problem jest zbyt szeroki i może być spowodowany różnymi czynnikami , więc chcę podzielić się moją sytuacją / rozwiązaniem.
Miałem projekt (przyniesiony przez klienta) z bibliotekami Xamarin Forms i Telerik. Ogólnie rzecz biorąc, chodziło o komponenty, których biblioteki nie znajdują się w folderze pakietów ani nie są dostępne za pośrednictwem Nuget (płatnych).
Cały projekt Referencje były „żółte”, wyglądało okropnie i przerażająco.
Rozwiązaniem było po prostu usunąć te Telerik referencje (w tym kilku kontroli w kodzie, które za pomocą tego). Zaraz potem wszystkie odniesienia w magiczny sposób uzyskały swój zwykły szary kolor, a błędy (głównie) zniknęły.
„Przeważnie” - ponieważ komunikaty o błędach „całkowicie czerwony wokół”, że „element nie jest nigdzie zdefiniowany” czasami się zdarzają. To dziwne i powoduje niedogodności, ale wciąż jestem w stanie skompilować i uruchomić projekt (y): wystarczy wyczyścić rozwiązanie, zrestartować Visual Studio, pomodlić się trochę, wyczyścić ponownie, usunąć foldery obj / bin, ponownie uruchomić ponownie, i to działa dobrze.
Kluczową sprawą jest usunięcie niedostępnych odniesień do bibliotek , ponieważ komunikaty o błędach mówią absolutnie inną rzecz. (Na przykład coś takiego jak „Xamarin.Build.Download.XamarinDownloadArchives nie znaleziono lub nie może czegoś znaleźć” itp., Ale to może oznaczać, że nie masz dostępnych odnośników.
Następnie usuń folder pakietów, załaduj ponownie / otwórz ponownie projekt / rozwiązanie, przejdź do „Zarządzaj pakietami Nuget” i kliknij przycisk „Przywróć”.
źródło
W programie Visual Studio 2019 ze wszystkimi projektami ukierunkowanymi na .Net Core 3.1 rozwiązaniem było:
źródło
Też napotkałem ten sam problem, ale moja sprawa była nieco inna niż powyższe. Próbowałem otworzyć projekt utworzony na innym komputerze. Okazało się, że ścieżka do folderu pakietu nie jest aktualizowana po dodaniu odwołania, więc ponowne uruchomienie VS, zmiana wersji .NET lub dowolne wspomniane zalecenie nie rozwiązuje problemu. Otworzyłem plik csproj w Notatniku ++ i poprawiłem wszystkie ścieżki do folderu pakietów. Następnie; wszystkie ostrzeżenia zniknęły. Mam nadzieję, że to pomoże.
źródło
w VS 2017 Wykonaj Clean, a następnie Build
źródło
Dziękuję wszystkim za pomoc. Oto opis tego, jak naprawiłem problem:
Kliknij prawym przyciskiem myszy swój projekt> Właściwości
W obszarze Aplikacja zmień docelową strukturę. W moim przypadku ImageSharp korzystał z .Net 4.6.1. Można to znaleźć w pliku packages.config.
Przejdź do referencji do projektu. Zauważysz, że SixLabors ma żółty trójkąt. Musisz zaktualizować pakiet NuGet.
Kliknij prawym przyciskiem myszy Referencje> Zarządzaj pakietami NuGet.
Zaktualizuj SixLabors.
Możesz mieć niewielkie aktualizacje kodu (patrz poniżej), ale to rozwiązało mój problem.
Konwertuj ImageSharp.Image na ImageSharp.PixelFormats.Rgba32?
źródło
W Visual Studio 2019 jednym z moich docelowych środowisk docelowych był rdzeń .net, ale odwoływał się do innego projektu, którego docelowym środowiskiem był standard .net. Zmieniłem wszystkie projekty, aby odwoływały się do standardu .net, a ikony zniknęły. Aby zobaczyć, jaki jest twój projekt, kliknij go prawym przyciskiem myszy, kliknij właściwości i spójrz na strukturę docelową. Możesz również normalnie kliknąć sam projekt i spojrzeć na znacznik <TargetFramework> w <PropertyGroup>
źródło
W rozwiązaniu obejmującym wiele projektów, jeśli każda inna rzecz zawiodła ... W projekcie startUp sprawdź. Zależności-> Zespoły i sprawdź, czy istnieje projekt z błędem, do którego istnieje odwołanie. Usuń go i przebuduj.
źródło