Nehmen Sie diese Kette von DLL-Referenzen an
%Vor%mit der folgenden Codezeile in Tests.dll, wo alles aufbaut
%Vor%Wenn ich das jetzt zu
ändere %Vor%Ich erhalte den folgenden Erstellungsfehler für Tests.dll "White.UIItem ist nicht in einer Assembly definiert, auf die nicht verwiesen wird. Sie müssen einen Verweis auf White.Core.dll hinzufügen." Und ich möchte das nicht machen, weil es meine Schichtung durchbricht.
Hier ist die Typdefinition für das Ergebnis, das in Automation.dll
ist %Vor%In der Aufrufkette wird der Eingabeparameter für diesen ctor über (Die TreeNode-Klasse ist in White.Core.dll) erstellt.
%Vor%Warum tritt diese Abhängigkeit beim Aufrufen von Count () auf IEnumerable auf? Ich vermutete dann, dass eine faule Auswertung das verursachte (aus irgendeinem Grund) - also habe ich ein ToArray () in die obige Zeile eingefügt, aber nicht funktioniert.
Update 2011 01 07: Neugieriger und neugieriger! Es wird nicht erstellt, bis ich eine White.Core-Referenz hinzufüge. Also füge ich eine Referenz hinzu und baue sie (um die schwer zugängliche Abhängigkeitsquelle zu finden). Öffnen Sie es in Reflector und die einzigen aufgeführten Referenzen sind Automation, mscorlib, System.core und NUnit. Also hat der Compiler die White-Referenz weggeworfen, da sie nicht benötigt wurde. ILDASM bestätigt auch, dass es keinen White AssemblyRef-Eintrag gibt.
Irgendwelche Ideen, wie man diesem Ding auf den Grund gehen kann (in erster Linie für "Jetzt will ich wissen warum" Gründe)? Was sind die Chancen, dass dies ein VS2010 / MSBuild Bug ist?
Aktualisierung 2011 01 07 # 2 Nach Shimmy's Vorschlag versuchte man, die Methode explizit als eine Erweiterungsmethode zu bezeichnen
%Vor% und es hört auf zu cribbing (nicht sicher warum).
Allerdings habe ich danach etwas Code umgestellt und jetzt bekomme ich das gleiche Problem an einem anderen Ort mit IEnumerable - dieses Mal Lese- und Filterzeilen aus einer Datei auf der Festplatte (völlig unabhängig von Weiß). Sieht so aus, als wäre es ein 'Symptom-Fix'.
var lines = File.ReadLines(aFilePath).ToArray();
noch einmal, wenn ich das ToArray () entferne, kompiliert es wieder - es scheint, dass jede Methode, die bewirkt, dass das aufzählbare Element ausgewertet wird (ToArray, Count, ToList usw.), dies verursacht. Lass mich versuchen, eine funktionierende kleine App zu bekommen, um dieses Problem zu demonstrieren ...
Aktualisierung 2011 01 07 # 3 Puh! Weitere Informationen .. Es stellt sich heraus, das Problem ist nur in einer Quelldatei - diese Datei ist LINQ-Phobic. Jeder Aufruf einer Enumerable-Erweiterungsmethode muss explizit aufgerufen werden. Die Refactorings, die ich gemacht habe, haben verursacht, dass eine neue Methode in diese Quelldatei verschoben wurde, die einige LINQ hatte :) Noch immer keine Ahnung, warum diese Klasse LINQ nicht mag.
%Vor% Aktualisierung 2011 01 11 # 4
Verengt es auf was scheint der Täter, aber kein Motiv :)
Die Quest postte das Wochenende wieder ... und nutzte den immergrünen Prozess der Eliminierung, um auf dem verletzenden Teil zu landen.
Das Problem besteht in der Verwendung der Direktive in der Quelldatei in Tests.dll
Als nächstes ging ich nach dem wahrscheinlichsten Verdächtigen in diesem Namensraum und ich hatte WhiteExtensions im Rampenlicht.
%Vor%Dies führte zu 3 Korrekturen, die beide funktionieren.
G.S.OurAutomation.Framework.White
Obwohl meine spezifische Instanz behoben ist, kann dieses Update jemandem helfen, den Grund dafür zu erklären? Wenn nicht shimmy das Häkchen bekommt :), um in die richtige Richtung zu zeigen.
Versuchen Sie, System.Linq.Enumerable.Count(result.MissingPaths) (mit oder ohne die vollständige Namespace-Referenz) aufzurufen.
Count ist eine Erweiterungsmethode, die Sie explizit aufrufen können.
Aktualisierung nach Gishus Update # 2:
Der Grund für alle ist der gleiche, die Funktionen ToArray , Count , ToList usw. sind alle Erweiterungsmethoden, die in System.Linq.Enumerable .
BTW, wichtig : Haben Sie überprüft, ob der Namespace System.Linq ( using System.Linq ) in Ihre Datei importiert wurde? das könnte sogar alle deine Probleme lösen.
Der Compiler musste vermutlich White.Core.dll sehen, um herauszufinden, ob für Ihre Klasse eine Count () -Methode definiert wurde. Da dort nicht das IEnumerable & lt; & gt; Der Count der Erweiterungsmethode und somit nicht White.Core.dll, aber es konnte nicht wissen, ohne es zu untersuchen.
Aber ich kann nicht erklären, wie das für IEnumerable<string> der Fall sein könnte, wenn der Compiler nicht überprüft, dass Sie keine Kovarianz verwenden ??