Warum erhalte ich ein Warnsymbol, wenn ich einen Verweis auf ein MEF-Plugin-Projekt hinzufüge?

Ich möchte die Kernklasse eines Plugins testen, indem ich direkt auf das Plugin-Projekt verweise und die Plugin-Klasse instanziiere. Wenn ich ein Testkonsolen-App-Projekt erstelle und dem Plugin-Projekt eine Projektreferenz hinzufüge, wird neben der Referenz in der Referenzliste ein Warnsymbol (gelbes Dreieck mit Ausrufezeichen) angezeigt.

Wenn ich stattdessen einen Verweis auf die DLL hinzufüge, die Assembly-Build-Ausgabe des Plugins, erhalte ich keine solche Warnung. Was könnte diese Warnung mir sagen?

Wie in den Kommentaren der Frage erwähnt, können unterschiedliche .NET Framework-Versionen zwischen den Projekten dies verursachen. Überprüfen Sie die Eigenschaften Ihres neuen Projekts, um sicherzustellen, dass keine andere Standardversion verwendet wird.

Das gleiche Problem trat bei einer ASP.Net-Webanwendung und zwei Bibliotheksklassenprojekten auf, auf die in der Webanwendung verwiesen werden musste. Ich hatte keine Informationen darüber, warum der Build fehlgeschlagen ist und die Referenzen ungültig waren.

Die Lösung bestand darin, sicherzustellen, dass alle Projekte das gleiche Ziel-Framework hatten:

Klicken Sie in Visual Studio 2015 mit der rechten Maustaste auf Projekt> Eigenschaften> Anwendung> Zielframework

Lösung speichern, bereinigen und neu erstellen. Die Projektreferenzen sollten nicht mehr als gelbe Warnungen angezeigt werden, und die Lösung wird kompiliert.

Meine Webanwendung zielte auf .NET 4.5 ab, während die beiden anderen Projekte für abhängige Bibliotheksklassen auf .NET v4.5.2 abzielten

Für beide (oder alle) Projekte, die Sie zusammen verwenden möchten:

Klicken Sie mit der rechten Maustaste auf das Projekt> Eigenschaften> Anwendung> Ziel .NET Framework

Stellen Sie sicher, dass beide (oder alle) Ihrer Projekte dieselbe .NET Framework-Version verwenden.

1. Stellen Sie sicher, dass alle Versionen für jedes Projekt gleich sind. Klicken Sie auf jedes Projekt und sehen Sie die Version hier. Projekt> Eigenschaften> Anwendung> Ziel .NET Framework

2. ein. Gehen Sie zu Tools> Nuget Package Manager> Package Manager-Konsolentyp Update-Package -Reinstall (falls dies nicht funktioniert, fahren Sie mit 2.b fort ).

   b. Dies ist kritisch, aber die größte Möglichkeit, die funktionieren wird . Entfernen Sie <Ziel> Möglicherweise mit mehreren Zeilen </ Ziel>, die normalerweise im unteren Teil von .csproj zu finden sind.

3. Speichern, laden und erstellen Sie die Lösung.

Installieren Sie alle Pakete in allen Projekten der aktuellen Lösung neu:

Update-Package -Reinstall

Stellen Sie sicher, dass die Projekte auf dieselbe Framework-Version abzielen . In den meisten Fällen liegt der Grund darin, dass das aktuelle Projekt (in dem Sie einen Verweis auf ein anderes Projekt hinzufügen) auf eine andere .net-Framework-Version verweist als die anderen .

Überprüfen Sie NETFramework der referenzierten DLL und des Projekts, in dem Sie die DLL hinzufügen. Beispiel: DLL ==> supportRuntime version = "v4.0" Project ==> supportRuntime version = "v3.0"

Sie erhalten ein Warnsymbol. Lösung: Stellen Sie die Konsistenz der DLL-Version her.

Ich bin auf dieses Problem gestoßen, als ich auf eine .NET Standard 2.0-Klassenbibliothek in einer .NET Framework 4.7.1-Konsolenanwendung verwiesen habe. Ja, die Frameworks sind unterschiedlich, aber sie sind kompatibel (.NET Standard soll sowohl mit .NET Core als auch mit .NET Framework kompatibel sein.) Ich habe versucht, die Projektreferenz usw. zu bereinigen, neu zu erstellen, zu entfernen und zu lesen usw., ohne Erfolg . Durch Beenden von Visual Studio und erneutes Öffnen wurde das Problem behoben.

Es ist lange her, dass diese Frage gestellt wurde, aber wenn jemand noch interessiert ist, bin ich kürzlich auf ähnliche Symbole gestoßen. Ich habe ein C # .net-Projekt mit VS 2008 kompiliert. Ich habe festgestellt, dass VS die Assemblys für diese Referenzen nicht finden konnte. Wenn ich auf VS doppelklickte, wurden die Referenzen aktualisiert und die Symbole auf einigen dieser [BEARBEITEN: die es JETZT finden konnte] entfernt. Für verbleibende Referenzen musste ich die jeweiligen Baugruppen zusammenstellen.

Hinzufügen meiner 2 Cent zur @ kad81 Antwort,

Gehen Sie zu Visual Studio -> BUILD -> Configuration Manager

Wenn es sich in der Dropdown-Liste "Active Solution Platform" in der oberen rechten Ecke (meine ist VS 2012) um "Mixed Platforms" handelt, ändern Sie sie auf der Grundlage Ihrer Referenz-Assemblys von Drittanbietern auf die entsprechende Plattform.

Stellen Sie dann in jedem Projekt in der Liste sicher, dass Sie für alle Projekte dieselbe Plattform auswählen. (Wenn x86 nicht vorhanden ist, wählen Sie "", dann können Sie "x86" auswählen.)

Erstellen Sie zuerst die Bibliotheksprojekte neu und verweisen Sie dann auf Projekte. Hoffe das hilft.

Versuchen Sie, VS zu schließen und zu öffnen.

Scheint albern, aber nach 1 Stunde Befolgen der obigen Anweisungen und dem Auffinden, dass alles in Ordnung ist. Ich habe VS 2017 neu gestartet und die Probleme waren weg.

In Asp.net Core wird manchmal eine Warnung angezeigt, wenn Sie den Projektnamenbereich oder -namen ändern. Um diese Art von Warnungen zu entfernen, entladen Sie einfach das Projekt und laden es erneut. Wenn das Problem weiterhin besteht, können Sie Ihre Assembly-Referenz nicht finden.

Ich hatte diese Symbole aus einem anderen Grund. Wir haben eine große Lösung für alle unsere Projekte (fast 100). Ich habe eine Unterauswahl der Projekte getroffen, an denen ich interessiert war, und eine neue Lösung gefunden. Allerdings sind die Referenzen Projektreferenzen anstelle von Verweisen auf die kompilierten DLLs ....

Nach einigen Recherchen habe ich diesen Link auf GitHub gefunden, der erklärt, dass dies ein neues Verhalten in VS2015 ist.

Auf der GitHub-Seite wird eine Problemumgehung zum Konvertieren von Projektreferenzen in Binärreferenzen erläutert.

Um einige nicht funktionierende Dinge zu reparieren, ist es sinnvoll , manchmal einige Bibliotheken zu entfernen . Wie würde das nicht komisch klingen?

Wie auch immer, ich glaube, das Problem ist zu groß und kann durch verschiedene Faktoren verursacht werden. Ich möchte daher meine Situation / Lösung mitteilen.

Ich hatte ein Projekt (vom Kunden mitgebracht) mit Xamarin Forms und Telerik Bibliotheken. Die Sache bezog sich im Allgemeinen auf die Komponenten, deren Bibliotheken weder im Paketordner enthalten sind noch über Nuget verfügbar sind (kostenpflichtige).

Das ganze Projekt Referenzen waren "gelb", es sah schrecklich und beängstigend aus.

Die Lösung bestand nur darin, diese Telerik- Referenzen zu entfernen (einschließlich einiger Steuerelemente im Code, die diese verwendeten). Gleich danach bekamen alle Referenzen auf magische Weise ihre normale normale graue Farbe und die Fehler verschwanden (meistens).

"Meistens" - weil "all red around" Fehlermeldungen zu "das Element ist nirgendwo definiert" manchmal immer noch auftreten. Das ist seltsam und bringt Unannehmlichkeiten mit sich, aber ich kann die Projekte trotzdem kompilieren und ausführen: Sie müssen nur die Lösung bereinigen, Visual Studio neu starten, ein wenig beten, erneut bereinigen, obj / bin-Ordner entfernen, erneut starten und es funktioniert gut.

Der Schlüssel ist , nicht verfügbare Bibliotheksreferenzen zu entfernen , da die Fehlermeldungen absolut etwas anderes aussagen. (Zum Beispiel etwas wie "Xamarin.Build.Download.XamarinDownloadArchives nicht gefunden oder kann etwas nicht finden" usw., aber das könnte bedeuten, dass Sie keine Referenzen zur Verfügung haben.

Entfernen Sie dann den Paketordner, laden Sie das Projekt / die Lösung neu / öffnen Sie es erneut, gehen Sie zu "Nuget-Pakete verwalten" und klicken Sie auf die Schaltfläche "Wiederherstellen".

Unter Verwendung von Visual Studio 2019 mit allen Projekten, die auf .Net Core 3.1 abzielen, bestand die Lösung darin:

1. Reinigen / Bauen / Wiederaufbauen.
2. Starten Sie Visual Studio 2019 neu

Ich hatte auch das gleiche Problem, aber mein Fall war etwas anders als oben. Ich habe versucht, ein Projekt zu öffnen, das auf einem anderen Computer erstellt wurde. Ich habe festgestellt, dass der Pfad zum Paketordner nicht aktualisiert wird, wenn Sie eine Referenz hinzufügen, sodass ein Neustart von VS, das Ändern der .NET-Version oder eine der genannten Empfehlungen das Problem nicht löst. Ich habe die csproj-Datei in Notepad ++ geöffnet und alle relativen Pfade zum Paketordner korrigiert. Dann; Alle Warnungen sind weg. Ich hoffe es hilft.

in VS 2017 Reinigen und dann erstellen

Vielen Dank für die Hilfe. Hier ist eine Aufschlüsselung, wie ich mein Problem behoben habe:

Klicken Sie mit der rechten Maustaste auf Ihr Projekt> Eigenschaften

Ändern Sie unter Anwendung das Ziel-Framework. In meinem Fall verwendete ImageSharp .Net 4.6.1. Sie finden dies in Ihrer packages.config.

Gehen Sie zu Ihren Projektreferenzen. Sie werden feststellen, dass SixLabors ein gelbes Dreieck hat. Sie müssen das NuGet-Paket aktualisieren.

Klicken Sie mit der rechten Maustaste auf Referenzen> NuGet-Pakete verwalten.

Aktualisieren Sie SixLabors.

Möglicherweise haben Sie geringfügige Code-Updates (siehe unten), aber dies hat mein Problem behoben.

ImageSharp.Image in ImageSharp.PixelFormats.Rgba32 konvertieren?

In Visual Studio 2019 war eines meiner Projektzielframeworks .net-Kern, verwies jedoch auf ein anderes Projekt, dessen Zielframework .net-Standard war. Ich habe alle Projekte geändert, um auf den .net-Standard zu verweisen, und die Symbole wurden entfernt. Um zu sehen, was Ihr Projekt ist, klicken Sie mit der rechten Maustaste darauf und klicken Sie auf Eigenschaften und sehen Sie sich das Ziel-Framework an. Sie können auch normal auf das Projekt selbst klicken und das <TargetFramework> -Tag unter <PropertyGroup> anzeigen

Wenn in einer Multiprojektlösung alles andere fehlgeschlagen ist ... Überprüfen Sie im startUp-Projekt. Abhängigkeiten-> Baugruppen und prüfen Sie, ob das fehlerhafte referenzierte Projekt vorhanden ist. Entfernen Sie es und bauen Sie es neu auf.