Ich würde gerne wissen, wie ich die Quelle dieses Build-Fehlers ermitteln kann;
%Vor%Ich verstehe die Bedeutung dieses Fehlers (und die 5 anderen mögen es für dasselbe Projekt), aber ich kann nicht herausfinden, wie ich es in meinem Fall lösen kann. Die 'primäre Referenz' in diesem Fall (MyNamespace.MyProject) hat keine direkten Abhängigkeiten zu .NET 4.0.x.
Die primäre Referenz hängt nur von einem anderen Projekt ab (MyNamespace.MyCoreProject), von dem auch das Quellprojekt für den Build (MyNamespace.MyOtherProject) direkt abhängt. Und der Build beschwert sich nicht über das -Projekt mit indirekten Verweisen auf .NET 4.0.x, also nehme ich an, dass ich das ausschließen kann.
Die primäre Referenz hat eine direkte Abhängigkeit von drei (3) Drittanbieter-DLLs, die alle auch Target .NET 2.0 enthalten.
Ich habe dotPeek verwendet, um die gebauten Bibliotheken zu untersuchen, und kann unter .NET 4.0 keinen Verweis auf irgendetwas finden.
Der einzige andere mögliche Schlüssel in den Arbeiten ist die Verwendung von PostSharp, auf das direkt von 'MyNamespace.MyCoreProject' verwiesen wird (das vom primären Referenzprojekt referenziert wird), was das Problem verursachen könnte, da ich glaube, dass es einen Zusammenhang gibt VS2010 Bug bei der Referenzierung von PostSharp.dll (http://www.sharpcrafters.com/forum/Topic4444-4-1.aspx#bm4462), aber ich habe auch das aus der Build-Kette entfernt und sehe immer noch diesen Fehler, also nehme ich an kann auch das herausregeln.
Wenn mir jemand sagen kann, warum das passiert, fantastisch! Wenn nicht, wäre eine Richtung, wie man herausfinden kann, was der unnamierte "indirekte Bezug" ist, genauso hilfreich!
Übrigens habe ich alle folgenden Tools ausprobiert, um einige Informationen zu erhalten, aber sie sagen mir nicht viel, was ich nicht schon wusste (was die direkten Abhängigkeiten der betreffenden DLL sind); - .NET Reflektor - dotPeek - IldAsm - Hängt davon ab (Dependency Walker)
Ich habe zwar nicht wirklich einen guten Weg gefunden, das Problem zu lösen, wie MsBuild die Referenzen bestimmt, die es benutzt (warum es mir nicht nur sagt, wie es mit diesen indirekten Referenzen auskommt, anstatt mich zu raten) weiß nicht ...) Ich habe mein Problem gelöst.
Am Ende habe ich im Prinzip alle Verweise im Projekt 'Primärreferenz' entfernt (die den gesamten Code Stück für Stück ausschließen mussten - ein etwas schmerzhafter Prozess), um die Quelle des vermeintlichen indirekten Verweises auf .NET 4.0-Bibliotheken zu bestimmen wurde von einer DLL eines Drittanbieters verursacht, auf die verwiesen wurde.
Ich glaube jedoch, dass hinter diesem Problem ein Bug in MsBuild steckt, wie;
Nun, eine andere Kuriosität ist, dass ich die relevanten Bibliotheken nicht irgendwann berührt oder geändert habe, also hat dies gerade angefangen, aus einem anderen, nicht miteinander verbundenen Grund zu geschehen - was das sein könnte, weiß ich nicht.
Am Ende konnte ich dieses Problem nur lösen, indem ich gacutil / u für jede der relevanten Bibliotheken ausführen ließ, um zuvor installierte / verwendete Versionen der 4.0-Bibliotheken zu entfernen. (Es waren ungefähr 40 im Paket, also war das auch schmerzhaft! Da das Deinstallationsprogramm des Pakets die Bibliotheken im GAC nicht löschte)
Dies scheint zu haben, dass msbuild damit begonnen hat, die Referenzen zu verwenden, die ich ihm gesagt habe, anstatt eine eigene Vorstellung davon zu bekommen, was "diese Datei verwenden" und "diese spezifische Version verwenden bedeutet.
Gelöst, aber ich hätte einen saubereren Weg dafür genossen!
Versuchen Sie, MSIL Disassembler für alle verdächtigen Benutzer zu verwenden Baugruppen.
Suchen Sie den Typ, der von dieser .NET-Assembly usinf Ref # als Suchkriterien geladen wird. Dies ist ein Beispiel für einen Typ, den Sie auf dem Bildschirm finden können
Token: 0x01000012
Auflösung: 0x23000001
TypeRefName: System.Runtime.CompilerServices.CompilationRelaxationsAttribute
Untersuchen Sie, warum dieser Typ verwendet wird.
Aktualisierung: Haben Sie versucht, MSBuild Project Build Output Ausführlichkeit auf der Seite Tools \ Optionen \ Projekte und Lösungen \ Build And Run auf "Detailliert" zu setzen und anschließend die Lösung neu zu erstellen? Möglicherweise sehen Sie etwas in ResolveAssemblyReference target
Ich hatte dieses Problem und verwendete CheckAsm, um festzustellen, dass eine meiner eigenen Assemblys aus irgendeinem seltsamen Grund auf eine .NET 4.0-Version einer 3rd-Party-Bibliothek Bezug nahm, während die App selbst .NET 2.0 war. Ich habe alle Instanzen dieser Assembly von meiner Festplatte gelöscht (es lagen viele Kopien herum), die Lösung neu aufgebaut und alles war gut.
Ich hatte auch dieses Problem, und event.er führte mich zur Lösung. Ich hatte folgendes in meiner app.config:
%Vor%Ich habe newVersion in "2.0.0.0" geändert und die Lösung erstellt.
Tags und Links c# visual-studio-2010 projects-and-solutions postsharp