Visual Studio Premium 的强命名程序集的代码覆盖率

Code Coverage for Strong Named Assemblies with Visual Studio Premium

我在 运行 对我们的企业级应用程序进行单元测试时遇到以下错误,代码覆盖率在 Visual Studio 2010 年启用:

Strong name verification failed for the instrumented assembly 'MyTestableLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0e9ec37537d29286'. 
Please ensure that the right key file for re-signing after instrumentation is specified in the test settings.   

简化问题

所以我在 Visual Studio 2010 年用一个 class 库和一个测试项目创建了一个简单的解决方案。我们有强命名的程序集,所以我使用 Visual Studio 创建了一个新的 pfx 文件并将同一文件与 class 库和测试项目相关联。

这会产生同样的错误。见下文。

简单测试

单元测试 运行 在没有启用代码覆盖的情况下很好。

添加代码覆盖率

添加一些代码覆盖细节...

代码覆盖启用测试运行

然后 运行 测试...

帮助

当然,在启用代码覆盖率的情况下,测试执行得很好,但是强名称签名从两个项目和未选中的仪器程序集中删除。

我已经尝试 selecting 代码覆盖率重新签名密钥文件中的 pfx。我尝试使用 sn 命令从 pfx 生成强命名密钥:

sn -p MyStrongNameKey.pfx MyStrongNameKey.snk

我 select 代码覆盖详细信息重新签名密钥文件中的哪个文件似乎无关紧要 - 我可以 select 我的 .sln 文件,但我得到了同样的错误。

如果有人想看,我已经在这里添加了解决方案:

One Drive VS2010 Solution

pfx 密码是:

fernado1

我很想获得为此工作的代码覆盖率,但我看不到它 - 即使是像这样的简单解决方案。

好的。我现在有一个适用于我的问题的测试代码覆盖率。

此时我已经使用以下命令从程序集中提取了 public 密钥:

sn -p input.pfx output.publickey
sn -tp output.publickey

这在命令行中提供了以下 public 关键文本:

0024000004800000940000000602000000240000525341310004000001000100595757733513185e3dc44b958c76cdc1e56b73d5bd1c05a8a2b208311126cc1bc8e234a244cb1dcc3f3a25fbd82474911ce671cfd155242659a258c51d5fee8263a6a12d7a82cb98f1b5af0ac6e58afd2f02d1a8b9b34b5a4e8aa63a754830826caef3de5efe8ccbef81210a3dea0f977746b4f1d3335c1ca68d6a1894e47cb0

然后我遇到了这个 post,这引发了一些思考 MSDN Social Forum

可以说它没有用。有趣的是 post 有 32 位和 64 位版本的 sn 工具。使用 sn -Vr 将程序集添加到注册表时,sn.exe 你 运行 很重要。因此,如果您使用带有 -Vr 的 sn.exe 的 32 位版本来添加您想要跳过验证过程的程序集,然后使用 sn -Vl 使用 64 位版本对其进行验证,那么它将不会显示您刚刚注册的条目.好奇。

我使用以下命令行注册我的程序集我想尝试摆脱错误消息如下:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"

注意:我已经为 sn.exe 的 32 位和 64 位版本完成了此操作。我认为测试项目不需要注册,但我已经留下了。

所以在这一点上我的测试仍然没有 运行。

我使用 Fusion Log 工具查看发生了什么。我对其输出日志进行了文件内容搜索(使用 Agent Ransack),以查看在哪里使用了我的 DLL。我注意到一个名为 QTAgent32.exe 的进程,我不知道它是什么。我以为这是一些 Quick Time 代理,但事实证明它是 Visual Studio/Microsoft 测试代理。

日志仍然没有透露太多信息。我决定使用 SysInternals ProcMon。然后我 运行 测试显示 activity 的 1000 行。我寻找我的 DLL MyTestableLib.dll。往下看,我注意到测试代理正在使用它自己的位于我的解决方案路径中的文件夹:

E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out

我查看了这个文件夹,里面有我的 MyTestableLib.dll 和 mytestablelib.tests.dll 文件。我以为我会使用 Assembly Information tool 来快速达到峰值,但我发现,我得到了与测试相同的错误。测试项目加载正常(因为我没有在 MSTest 设置中检查它)

好的,现在回到sn.exe-Vr注册。

我运行以下命令行:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"

为了安全起见,32 位和 64 位都可以。添加了注册(使用 sn.exe -Vl - 对于 32 位和 64 位进行验证)。

然后我重新运行 测试,他们运行 很好。我现在可以查看我的代码覆盖率信息。

希望这可以帮助其他苦苦挣扎的人。可以这么说,因为我一直在工厂附近,所以某处可能有捷径。