Veraltete assembly dependency in C# .NET

Question

Mein C# - Projekt - wir nennen es die SuperUI - verwendet, um die Verwendung einer Klasse aus einer externen Montage.Jetzt ist es nicht, aber der compiler lässt mich nicht erstellen Sie das Projekt, ohne die assembly-Referenz im Ort.Lassen Sie mich erarbeiten.

Dieses Projekt verwendet, um werfen und fangen eine benutzerdefinierte exception-Klasse - die SuperException - was wurde abgeleitet von den standard-System.Ausnahme und lebte in einem separaten kompilierte assembly, SuperAssembly.DLL, die ich referenziert.

Irgendwann habe ich beschlossen, dass dies war eine sinnlose übung und ersetzt alle SuperExceptions mit einem System.SuitableStandardException in jedem Fall.Ich habe den Verweis entfernt, um SuperException.DLL, aber jetzt bin erfüllt mit die folgenden auf, die versuchen, das Projekt zu kompilieren:

Der Typ 'SuperException' ist in einer assembly definiert, die nicht verwiesen wird.Sie müssen einen Verweis auf assembly 'SuperException, Version=1.1.0.0 (...)'

Die Quelldatei wird, auf den der Fehler scheint nicht relevant;es ist die Projekt-namespace wird hervorgehoben, dass in der IDE.

Jetzt, hier ist das Ding:

1. Alle Verwendungen SuperException ausgeschlossen wurden aus der Projekt-code.
2. Im Vergleich zu einem anderen Projekt, das kompiliert gut, ohne einen Verweis auf SuperException.DLL, Ich nur den Verweis eine weitere Montage - und that Referenzen nichts, dass mein Projekt nicht auf sich selbst.Während es möglich ist, dass alle diese Abhängigkeiten werfen könnte SuperExceptions, Ich bin nur abfangen der Exception-Basisklasse und in jedem Fall...das andere Projekt baut gut!
3. Ich habe getan, Visual Studio ' s "Saubere Lösung" und klärte alles per hand, viele Male.

Es ist nicht das Ende der Welt, um diese Referenz, die ich einfach nicht sehen, warum es notwendig ist, nicht mehr.Nrrrgg.Alle Hinweise sind willkommen!

Answer 1

Es ist wahrscheinlich, eine transitive Referenz, wo irgendeine Art Aufruf der Methode gibt eine Instanz von SuperException boxed ("niedergeschlagen"), wie z.B.Eine Ausnahme ist, aber von der überprüfung den code in die transitiv enthalten code, D. H.code von Ihre externe Methode aufrufen, der compiler weiß, dass Sie müssen in der Lage, Informationen über das geben, irgendwann.

Resharper würde Ihnen sagen, wo ist es der Fall, dass Sie brauchen, um einen Verweis hinzuzufügen, und Sie könnte verwenden Lütz Roeder aka RedGate ' Reflektor zu Scannen zusammengestellt IL für einen Verweis auf diese Art in zwei Arten:1) verwenden Sie die Suche-Anlage 2) öffnen Sie die einzelnen öffentlich-Typ, den Sie verwenden, und für die muss der "ghost" Montage, es wird Sie bitten, Ihren Standort angeben.

Diese Häufig happends zu mir, wenn ich mich auf die Burg.Windsor aber nicht Schloss.Mikrokernel.:p

Answer 2

1. Beenden Sie Visual Studio
2. Löschen Sie die bin und obj Ordner in your solution directory
3. Neu starten und sehen was passiert

Answer 3

Ich Stimme den anderen Kommentaren hier..Es ist eine Referenz, in plain text irgendwo !Ich habe ähnliche Probleme in der Vergangenheit, wo die Suche durch die Projekt-Dateien zurückgegeben nichts, stellt sich heraus, es war in irgendeiner anderen Datei, die nicht automatisch abgeholt die Suche.

Ich denke nicht, dass das erstellen eines neuen Projekts ist die Lösung hier ... Sie müssen positiv sein, dass NONE von den Referenzen in Ihrer dependency tree verwenden SuperException.. NONE

Ich habe noch nie erlebt, bis zu dem Punkt, wo ich gebraucht haben buchstäblich wischen Sie das Projekt, ich habe immer gefunden, die Bezug zu irgendwo.Sicherzustellen, dass Sie Suche jeder Datei.

EDIT:

Nur einen Punkt hinzufügen, wenn die Lage spitzt sich zu, indem die Fehler scheint zufällig, kann oft bedeuten, dass es eine Diskrepanz zwischen der kompilierten source und das source-code-Datei..Ist das ein ASP.NET Anwendung?Ich habe es vorher, wo die kompilierte DLL ' s noch nicht ersetzt worden, die auf einen Umbau in der ASP.NET temp-Ordner verursacht Dinge zu bekommen..Interessant beim Debuggen :)

Answer 4

Ich glaube nicht, dass dies ist ein code-Problem.Was ich sehen kann, passiert, ist, dass man Ihre bestehenden Referenzen wahrscheinlich auf das verlassen, geben Sie Ihre eigenen Arten, die Sie wahrscheinlich erstellen in Ihrer Anwendung.

Wenn das der Fall ist, müssen Sie diesen Verweis auch wenn Sie nicht explizit den Typ und das obwohl die anderen referenzierten assembly hat seine eigene Referenz.Manchmal wird das Problem mit 3rd-party-Komponenten, die müssen Referenzen auf Typen, die man noch nicht verwiesen wird.Der compiler ist offensichtlich zu sehen, etwas in einer bestehenden referenzierten Assemblys und erwartet, dass Sie auf die abhängigen.

Answer 5

Da es ein compiler-Fehler, muss es eine Referenz oder Verwendung SuperException irgendwo in das Projekt.

1. Tun ein suchen/ersetzen im gesamten Projekt oder eine Lösung für, dass Typ, und entfernen Sie jede Referenz (es ist möglich hast du dies schon getan).
2. Wenn Sie auf irgendwelche Typen, die erbt von SuperException (auch wenn der Typ in einer anderen assembly definiert), müssen Sie einen Verweis auf die assembly, die SuperException definiert ist.

Nehmen die Linie, dass der compiler zeigt Sie den Fehler und starten Sie die Ablaufverfolgung der Erbe Baum von Objekten verwendet, auf dieser Strecke finden Sie vielleicht die Quelle, dass es der Weg.

Answer 6

Vielen Dank für Eure Antworten bisher.Ich habe versucht, jeden Vorschlag (mit einer Ausnahme) ohne Erfolg.

Der Vorschlag, den ich habe nicht versucht, erstellen Sie ein neues Projekt und fügen Sie alle meine Sachen zu ihm, der Gedanke, das wirklich testet meinen Willen zu Leben.;), Ich kann versuchen, das morgen, wenn ich belästigt werden.Nochmals vielen Dank.

Answer 7

Es gibt wirklich nichts besonders mysteriöses VS-Projekte heute - es ist alles text-Dateien, etc.ETWAS verweisen muss, dass die Klasse/dll, und dass etwas ein Teil von Ihr Projekt.

Haben Sie wirklich grep würde oder findstr würde die gesamte Lösung, Baum, jede einzelne Datei, für einen Verweis auf die Ausnahme?

Answer 8

Das klingt ziemlich seltsam.Hier ist, was ich würde check weiter:

1. Überprüfen Sie, dass es nichts Verweilen in Ihrem Properties/AssemblyInfo.cs-Datei.
2. Überprüfen Sie, dass es nichts Verweilen in Ihre SuperUI.csproj-Datei.
3. Löschen Sie alle Verweise und re-fügen Sie Sie hinzu.

Answer 9

Versuchen Sie, erstellen ein neues Projekt, und das hinzufügen von Klassen zu.

Answer 10

grep Ihrem Projekt-Ordner.Es könnte eine versteckte Referenz in Ihrem Projekt haben, oder ein Projekt, dass Ihre Projekt-Referenzen.Reinigen Sie mit dem Notepad-Editor, wenn nötig.

Answer 11

Wenn Sie auf irgendwelche Typen, die erbt von SuperException (auch wenn der Typ in einer anderen assembly definiert), müssen Sie einen Verweis auf die assembly, die SuperException definiert ist.

Abgeordnete auf, dass.

Sie möglicherweise nicht die Referenzierung SuperException, aber vielleicht sind Sie verweisen auf SpecializedSuperException, die ist abgeleitet von, oder irgendwie anderweitig verwendet SuperException - Ihre grep des Projekts für SuperException wird nicht fangen es aber.

Versuchen Sie, einen hack mit der Studie von NDepend

Answer 12

Dies ist, wo Werkzeuge wie Resharper wirklich auszahlen-eine simple Findet Verwendungen in der Regel sagt mir, wie "ghost Abhängigkeiten" mehrere Male.

Vielleicht Sie könnte gehen zu Ihre definition der SuperException class und versuchen Sie, Alle Referenzen().Sie möchten vielleicht auch zu prüfen, ob die Montage SuperException ist eine zirkuläre Abhängigkeit auf Ihrem Haupt Versammlung (z.B. Haupt-Versammlung hängt davon ab, Ausnahme assembly abhängt main assembly...).

Answer 13

Ich habe eine sehr ähnliche assembly-Referenz-Problem, das passiert, wenn mein C# - Bibliothek hatte ein abhängiges C++/CLI-assembly.Das problem war, dass ich Erben eine öffentliche Klasse aus, dass C++/CLI-assembly in mein C# - assembly-Bibliothek.Das bedeutete, dass die Vererbungskette war, spanning über mehrere Baugruppen.

Ich war in der Hoffnung, dass jeder client schlau genug wäre, um indirekt laden Sie die C++/CLI-assembly jeder Zeit die C# - Bibliothek-es brauchte, aber das war nicht der Fall, selbst bei der Kompilierung.

Ich entledigte sich dieses problem durch das brechen der Vererbung zwischen Klassen, die waren spanning über diese zwei Montage-Bibliotheken und die Verwendung aggregation statt.Mein Mandant war endlich glücklich und nicht erfordern die C++/CLI-assembly als eine Abhängigkeit nicht mehr.

In Ihrem Wort, das Sie wahrscheinlich haben, um sicherzustellen, dass SuitableStandardException nicht Erben SuperException in Auftrag zu beseitigen die SuperException.DLL als Referenz.

Verwenden Kapselung statt Vererbung und erstellen Sie ein SuperException Daten-member in Ihren neuen SuitableStandardException.

Wenn das nicht zu lösen, müssen Sie möglicherweise mehr Klassen spanning Vererbung über einige Versammlungen, in Ihrem Fall SuperAssembly.DLL und superException.dll.

Wenn Sie nicht finden können alle von Ihnen versuchen Sie diesen trick:

1. Alle öffentlichen Mitglieder und Klassen in SuperAssembly.DLL intern.

2. In der SuperAssembly.DLL Freunde mit SuperException.DLL:

   [assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
   

3. Stellen Sie sicher, dass Sie bauen, und entfernen Sie die SuperAssembly.DLL Referenz aus alle Kunden, die bereits Referenzen SuperException.DLL.

Answer 14

grep -R SuperException * in der Basis des Projekts (get grep von irgendwo erstmal) nur um sicher zu sein.