Reflection.AssemblyName().Version 的意外结果 [英] Unexpected result of Reflection.AssemblyName().Version

问题描述

最近，我不得不检查某个 DLL 的汇编版本，姑且称之为 AAA.BBB.dll，我决定使用一个简单的 Powershell 命令来获取它，即:

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

我意识到这个命令没有显示我想要的版本.大多数情况下，它显示一个与当前目录中的 dll 版本不匹配的固定版本.即使为 GetAssemblyName 方法(例如AAA.BB.dll123")提供了一些无效的输入，也会显示相同的版本(而不是抛出异常).我尝试使用绝对路径，但没有帮助.我还检查过 AAA.BB.dll 不在 GAC 中.

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.

通过在 F# 交互中调用类比代码或在 .NET 反射器中打开 AAA.BB.dll，我可以获得正确的程序集版本.

I could get a correct assembly version by calling analogical code in F# interactive or by opening that AAA.BB.dll in .NET reflector.

我已经检查了 AssemblyName.GetAssemblyName 我找不到对这种行为的任何解释.我想知道:

I've checked documentation for AssemblyName.GetAssemblyName and I couldn't find any explanation for that behavior. I'm wondering:

• 为什么该命令总是显示一个版本的 DLL?

• Why is that command constantly displaying one version of a DLL?

如何解释 Powershell 和 F# Interactive 中的类比代码之间的差异?是否与程序集解析机制或 .NET Framework 配置或 .NET Framework 版本有关?

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?

为什么使用无效参数(即AAA.BB.dll123")调用 GetAssemblyName 不会引发异常?

Why calling GetAssemblyName with an invalid argument (namely 'AAA.BB.dll123') does not throw the exception?

我正在粘贴在不包含 dll 的 M: 目录中执行的几个命令的输出.

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

我应该注意到，程序集版本为 1.0.600.8 的 AAA.BB.dll 位于该计算机上的某个其他目录中.

I should note that AAA.BB.dll with assembly version 1.0.600.8 is in some other directory on that computer.

推荐答案

我无法再访问有问题的机器，但我认为配置错误 DEVPATH 可能是罪魁祸首.一些工具，例如反编译器，会修改 DEVPATH 以使用户能够调试反编译的程序集.

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.

如果 这个博客entry 为真，如果设置了 DEVPATH，则禁用所有正常的程序集查找功能，并且 DEVPATH 中的程序集优先于所有其他程序集.在这种情况下，Powershell 显示 AAA.BB.dll 的固定版本这一事实应该不足为奇.如果 F# 在另一个版本的 .NET 运行时下运行，则它可能不受该更改的影响.

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.

这篇关于Reflection.AssemblyName().Version 的意外结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！