2008-09-09 7 views
15

Wie kann ich anhand des Assemblynamens oder der Assembly-Klasse (oder ähnlicher) feststellen, ob eine Assembly Teil des .NET-Frameworks ist (System.windows.Forms)?Ermitteln, ob eine Assembly Teil des .NET-Frameworks ist

Bis jetzt habe ich die PublicKeyToken und CodeBase-Eigenschaften berücksichtigt, aber diese sind nicht immer die gleichen für das gesamte Framework.

Der Grund, warum ich diese Informationen erhalten möchte, ist eine Liste der Assemblys, die meine EXE-Datei verwendet, die auf Clientcomputern sein müssen, damit ich die richtigen Dateien in einer Setupdatei verpacken kann, ohne das Visual Studio-Setup-System zu verwenden. Das Problem ist, ich möchte keine .NET-Framework-Assemblies abholen, und ich möchte, dass es sich um einen automatischen Prozess handelt, der einfach ausgeführt werden kann, wenn ein größeres Update abgeschlossen ist.

Die ultimative Lösung wäre, dass es eine IsFramework Eigenschaft ist ... :)

+0

Wie automatisch muss das sein? Es ist ziemlich einfach herauszufinden, welche von MS sind. – RQDQ

Antwort

3

Ich vermute, dass das Verfahren sowohl zuverlässigsten und allgemeinste die PublicKeyToken sein wird. Ja, es gibt mehr als eine, aber es wird eine endliche Liste sein und eine, die sich nicht sehr oft ändert.

Zu diesem Zweck könnten Sie nur eine Positivliste von Assemblynamen haben - diese Liste wird zwischen den Versionen des Frameworks sowohl endlich als auch statisch sein.

+0

Ich frage mich, ob Sie einige Microsoft-Service für die öffentlichen Schlüssel-Token abfragen können ... wie die Art, wie sie einen Remote-Symbol-Server bereitstellen. Auf diese Weise müssen Sie es nicht manuell verfolgen. –

1

Sie könnten reflection verwenden, um den Herausgeber der Assembly anzuzeigen und diesen mit dem Pfad der Assembly zu koordinieren. Wenn Sie eine Assembly finden, deren Herausgeber Microsoft ist und die sich irgendwo unterhalb von C:\Windows\Microsoft.NET\Framework befindet, ist es eine sichere Sache, dass sie Teil der Laufzeit ist.

Auf den zweiten Gedanken, der Verlag möglicherweise nicht einmal notwendig sein. Alles, was sich unter diesem Pfad befindet, sollte Teil der Laufzeit sein (abgesehen von einer fehlerhaften Anwendung, die an der falschen Stelle funktioniert).

+0

Das Problem hier ist, dass eine Menge Zeug in der GAC nach AssemblyName und Assembly –

3

Nein, es beginnt nicht mit "System". Sie könnten "WindowsBase" überprüfen, was eine Framework-Assembly ist.

Sie können das PublicKeyToken auch nicht überprüfen, da andere Microsoft-Assemblys mit den Standardschlüsseln signiert sind, aber nicht Teil von .NET Framework (Visual Studio-Assemblys) sind.

Der beste Weg, dies zu tun ist, eine Sammlung von installierten .NET-Frameworks zu erhalten und zu überprüfen, ob die Zielbaugruppe Teil ihrer RedistList ist (RedistList\FrameworkList.xml).

FrameworkList.xml zu finden in:

  • .NET 2.0: C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ RedistList
  • .NET 3.x: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework \ v Version \ RedistList
  • .NET 4.x: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v Version \ RedistList
  • .NET Kern: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETCore \ v Version \ RedistList
+0

Needs viel mehr als +1 ist. Dies ist die echte, autoritative Antwort. –

1

Wenn Sie wissen, dass keine Ihrer DLLs im GAC sein könnten Sie überprüfen ob jede Baugruppe im GAC ist oder nicht. Wenn es ist, kopieren Sie es nicht. Wenn nicht, dann kopiere es.Es gibt eine Eigenschaft in der Assembly-Klasse GlobalAssemblyCache. Dies würde offensichtlich in manchen Situationen besser funktionieren als in anderen.

3

Um dies zu erreichen, verwende ich den Produktnamen, der in AssemblyProductAttribute eingebettet ist.

var attribute = assembly.GetCustomAttributes(typeof(AssemblyProductAttribute), false)[0] as AssemblyProductAttribute; 
var isFrameworkAssembly = (attribute.Product == "Microsoft® .NET Framework"); 

Ich verwende diese Technik Gruppe Baugruppen nach Produkt unter dem Info-Bildschirm der Anwendung und es scheint nur für mich gut zu funktionieren.

4

Ich hatte mit genau dem gleichen Problem zu tun haben. Leider sind alle bisher angegebenen Antworten nicht ausreichend, um sicher festzustellen, ob eine Assembly Teil des .NET Framework ist.

Microsoft stellt eine Klasse FXAssembly in die globale Namespace jeder Rahmenanordnung mit einem const String Angabe der Version genannt:

.class private abstract auto ansi sealed beforefieldinit FXAssembly 
    extends [mscorlib]System.Object 
{ 
    .field assembly static literal string Version = string('2.0.0.0') 

} 

Mit diesem „Marker“ zu überprüfen, ob eine Baugruppe eine Rahmenanordnung ist. Das Überprüfen des öffentlichen Schlüssels tut auch nicht weh.

+1

Leider gilt dies nicht für alle Framework-Assemblies :(Beispiel: System.Data Version 2.0.0.0 verfügt nicht über diese Klasse, obwohl sie Teil von .net Framework 2.0 war. Es wird weiterhin nach einem öffentlichen Schlüsseltoken von 'b77a5c561934e089' gesucht scheint am vielversprechendsten zu sein –

+1

Neben 'b77a5c561934e089' gibt es mindestens 3 weitere:' 31bf3856ad364e35' (zB PresentationCore.dll), 'b03f5f7f11d50a3a' (zB System.Drawing.dll) und' 89845dcd8080cc91' (zB System.Data.SqlServerCe .dll) – VitalyB

1

Wenn Sie Visual Studio installieren, erhalten Sie die Referenzkomponenten in verschiedenen Unterordner des Formulars C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\{FrameworkName}\{FrameworkVersion} - das Interessanteste, was könnte die RedistList\FrameworkList.xml-Datei, die eine Liste aller Montagenamen enthält, die mit der angegebenen Framework-Version ausgeliefert wurden.

z. C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\RedistList\FrameworkList.xml scheint eine Liste aller .NET 4.0-Framework-Assemblys zu enthalten.

Mit diesen Dateien können Sie problemlos statische weiße Listen von Baugruppen erstellen.