问题
Recently, I had to check assembly version of certain DLL, let call it AAA.BBB.dll and I decided to use a simple Powershell command to get it, namely:
[Reflection.AssemblyName]::GetAssemblyName('AAA.BB.dll').Version
I realized that this command does not display the version that I want. Most of the time it displays one fixed version which does not match the version of the dll in the current directory. Even providing an some invalid inputs to GetAssemblyName method (e.g. 'AAA.BB.dll123') showed that same version (instead of throwing an exception). I tried using absolute paths and it did not help. I've also checked that AAA.BB.dll was not in GAC.
I could get a correct assembly version by calling analogical code in F# interactive or by opening that AAA.BB.dll in .NET reflector.
I've checked documentation for AssemblyName.GetAssemblyName and I couldn't find any explanation for that behavior. I'm wondering:
Why is that command constantly displaying one version of a DLL?
How differences between analogical code in Powershell and F# interactive can be explained? Is it something with assembly resolution mechanism or .NET Framework configuration or .NET Framework version?
Why calling GetAssemblyName with an invalid argument (namely 'AAA.BB.dll123') does not throw the exception?
I'm pasting the output for a couple of commands which were executed in M: directory which contains no dlls.
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
I should note that AAA.BB.dll with assembly version 1.0.600.8 is in some other directory on that computer.
回答1:
I don't have access to machine in question anymore, but I think that misconfigured DEVPATH might have been the culprit. Some tools, such as decompilers, modify DEVPATH to enable user to debug decompiled assemblies.
If this blog entry is true, if DEVPATH is set, all normal assembly lookup features are disabled and assemblies in DEVPATH take precedence over all other assemblies. In such case, the fact that Powershell displayed a fixed version of AAA.BB.dll should be no surprise. If F# run under another version .NET runtime, it could be not affected by that change.
来源：https://stackoverflow.com/questions/38132546/unexpected-result-of-reflection-assemblyname-version