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

321

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?

ProfK
quelle
8
In den meisten Fällen enthalten Warndreiecke QuickInfos oder (falls dies nicht der Fall ist) einen Eintrag im Fehlerfenster. Vermutlich weisen die beiden Projekte inkompatible Abhängigkeiten auf.
Damien_The_Unbeliever
2
Irgendwelche Warnungen in der Konsole beim Versuch zu bauen?
Jite
231
Ich habe dies bei Projekten gesehen, die auf verschiedene .net-Framwork-Versionen
abzielen
4
@OP könnten Sie die Antwort von kad81 als die richtige auswählen
Andy
5
Das bringt mich immer . Hinzufügen eines neuen Projekts zu einer .NET 4-Lösung und der Standardwert ist 4.5.
Robin French

Antworten:

674

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.

kad81
quelle
13
Was ich auch wissen muss, ist, warum Visual Studio das Hinzufügen dieser Referenzen dann akzeptiert hat?
Anders Lindén
16
Ich benutze VS 2015 und das Problem ist immer noch da. Ich habe eine halbe Stunde verloren, bis ich hierher kam.
Alisson
14
nicht einmal Schwebetext oder Build-Fehler, die erklären, was das Problem ist
matao
6
Kann bestätigen, dass dies die Wurzel des Problems war. Kann auch bestätigen, dass Visual Studio 2017 mit Update 15.3 das Problem, dass keine aussagekräftige Nachricht angezeigt wird, immer noch nicht behoben hat. Sehr nervig.
Greg R Taylor
4
@matao Einverstanden! Es ist ärgerlich, dass ich keine Details über den Fehler bekommen konnte ...
nterry
74

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

kbarry
quelle
44

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.

user3578181
quelle
Perfekt, für mich gearbeitet! Ich hatte ein MVC-Projekt mit .NET Framework 4.5.2. Und meine Klassenbibliotheken, die darauf verweisen, waren .NET Framework 4.7.
Mike Upjohn
Man würde denken, dass neue Projekte, die zu einer bestehenden Lösung hinzugefügt werden, klug genug wären, um zu wissen, welche Version, aber leider nicht der Fall ist.
Ron
38
  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.

Aljohn Yamaro
quelle
1
Vielen Dank dafür, eine nette Fehlermeldung in Visual Studio über .Net-Versionen würde hier nicht in die Irre gehen!
Colmde
1
@colmde Interessanterweise wird im Ausgabefenster die folgende Meldung angezeigt, wenn Sie die Lösung bereinigen: 'Das Paket wurde mit .NetFramework XXX anstelle des Zielframeworks .NetFramework XXX wiederhergestellt. Das Paket ist möglicherweise nicht vollständig kompatibel mit Ihrem Projekt '
elszeus
1
Teil 2.b, der in anderen Antworten nicht erwähnt wurde, war für mich kritisch! 2.b Entfernen Sie <Ziel> Möglicherweise mit mehreren Zeilen </ Ziel>, die normalerweise im unteren Teil von .csproj zu finden sind.
Shelbypereira
1
Teil 2.b ist völlig verrückt, aber es funktioniert! danke
Elo
1
Danke 2.b hat den Trick auch für mich gemacht. Hätte das NIE selbst herausgefunden.
Henrik Clausen
23

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

Update-Package -Reinstall
Nitin Badole
quelle
2
Obwohl dieser Vorschlag mein Problem nicht direkt löste, wies er mich in die richtige Richtung für mein Szenario. Für diejenigen, die es helfen könnte, musste ich meine NuGet-Paketquelle für Update-Package auf v3 ändern, um die richtige Version zum Herunterladen zu finden: docs.nuget.org/consume/package-manager-dialog#package-sources
John Lee
1
Es entfernte alle Pakete, installierte sie und die gelben Dreiecke kamen zurück.
Anders Lindén
8

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 .

user274294
quelle
5

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

Sumit khare
quelle
5

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.

Justin
quelle
4

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.

Glückliche Stadt
quelle
4

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.

JenonD
quelle
4

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.

Alex Stephens
quelle
1
Hat für mich gearbeitet. Blöd oder nicht manchmal, Visual Studio wird verwirrt und der Cache wird durcheinander gebracht. Vielen Dank, dass Sie es vorgeschlagen haben - ich hasste es, es zu tun, weil ich mich dumm fühlte zu denken, dass es funktionieren würde, aber was zum Teufel - nach einer Stunde anderer Dinge könnte ich genauso gut und tada es funktionierte
Blake
2

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.

Tomcat0x4d2e47
quelle
1

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.

Martijn
quelle
1

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

Agat
quelle
1

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
Riaan van Zyl
quelle
0

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.

ali
quelle
0

in VS 2017 Reinigen und dann erstellen

user1684037
quelle
0

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?

PhoenixWright
quelle
0

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

oben
quelle
0

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.

Babatunde Ahmed
quelle