unerwartetes Ergebnis Reflection.AssemblyName() Version

Question

Vor kurzem hatte ich Assemblierung-Version von bestimmten DLL zu überprüfen, lassen Sie es AAA.BBB.dll nennen und ich beschloß, einen einfachen Powershell-Befehl zu verwenden, um es zu bekommen, und zwar:

[Reflection.AssemblyName]::GetAssemblyName('AAA.BB.dll').Version 

Ich habe festgestellt, dass dieser Befehl nicht die gewünschte Version anzeigt. Meistens zeigt es eine feste Version an, die nicht mit der Version der DLL im aktuellen Verzeichnis übereinstimmt. Selbst das Bereitstellen einiger ungültiger Eingaben für die Methode GetAssemblyName (z. B. "AAA.BB.dll123") zeigte dieselbe Version (anstatt eine Ausnahme auszulösen). Ich habe versucht, absolute Pfade zu verwenden und es hat nicht geholfen. Ich habe auch überprüft, dass AAA.BB.dll nicht in GAC war.

Ich konnte eine korrekte Assembly-Version erhalten, indem ich analogen Code in F # interaktiv aufruft oder indem ich diese AAA.BB.dll in .NET-Reflektor öffne.

Ich habe Dokumentation für AssemblyName.GetAssemblyName überprüft und ich konnte keine Erklärung für dieses Verhalten finden. Ich frage mich:

• Warum zeigt dieser Befehl ständig eine Version einer DLL?

• Wie können die Unterschiede zwischen analogem Code in Powershell und F # interactive erklärt werden? Ist es etwas mit dem Assembly Resolution Mechanism oder der .NET Framework-Konfiguration oder der .NET Framework-Version?

• Warum ruft GetAssemblyName mit einem ungültigen Argument (nämlich 'AAA.BB.dll123') nicht die Ausnahme?

Ich bin Einfügen der Ausgabe für ein paar Befehle, die in M: Verzeichnis ausgeführt wurden, die keine DLLs enthält.

PS M:\> [Reflection.AssemblyName]::GetAssemblyName('AAA.BB.dll').Version 

Major Minor Build Revision 
----- ----- ----- -------- 
1  0  600 8 


PS M:\> [Reflection.AssemblyName]::GetAssemblyName('aAAA.BB.dll').Version 
Exception calling "GetAssemblyName" with "1" argument(s): "Could not load file or assembly 'M:\aAAA.BB.dll' or one o 
f its dependencies. The system cannot find the file specified." 
At line:1 char:43 
+ [Reflection.AssemblyName]::GetAssemblyName <<<< ('aAAA.BB.dll').Version 
    + CategoryInfo   : NotSpecified: (:) [], MethodInvocationException 
    + FullyQualifiedErrorId : DotNetMethodException 

PS M:\> [Reflection.AssemblyName]::GetAssemblyName('AAA.BB.dll123').Version 

Major Minor Build Revision 
----- ----- ----- -------- 
1  0  600 8 


PS M:\> [Reflection.AssemblyName]::GetAssemblyName("AAA.BB.dll123").Version 

Major Minor Build Revision 
----- ----- ----- -------- 
1  0  600 8 


PS M:\> [Reflection.AssemblyName]::GetAssemblyName("AAA.BB123").Version 
Exception calling "GetAssemblyName" with "1" argument(s): "Could not load file or assembly 'M:\AAA.BB123' or one of 
its dependencies. The system cannot find the file specified." 
At line:1 char:43 
+ [Reflection.AssemblyName]::GetAssemblyName <<<< ("AAA.BB123").Version 
    + CategoryInfo   : NotSpecified: (:) [], MethodInvocationException 
    + FullyQualifiedErrorId : DotNetMethodException 

PS M:\> [Reflection.AssemblyName]::GetAssemblyName("AAA.BB.123").Version 

Major Minor Build Revision 
----- ----- ----- -------- 
1  0  600 8 

sollte ich beachten Sie, dass AAA.BB.dll mit Montage Version 1.0.600.8 auf diesem Computer in einem anderen Verzeichnis ist.

Answer 1

Ich habe keinen Zugriff mehr auf Maschine in Frage, aber ich denke, dass falsch konfigurierte DEVPATH könnte der Schuldige gewesen sein. Einige Tools, z. B. Decompiler, modifizieren DEVPATH, damit Benutzer dekompilierte Assemblys debuggen können.

Wenn this blog entry wahr ist, wenn DEVPATH festgelegt ist, sind alle normalen Assembly-Suchfunktionen deaktiviert, und Assemblys in DEVPATH haben Vorrang vor allen anderen Assemblys. In diesem Fall sollte die Tatsache, dass Powershell eine feste Version von AAA.BB.dll angezeigt hat, keine Überraschung sein. Wenn F # unter einer anderen .NET-Laufzeitversion ausgeführt wird, ist diese Änderung möglicherweise nicht betroffen.