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

时间:2015-06-25 15:35:15

标签: .net visual-studio code-coverage

当我在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中创建了一个带有一个类库和一个测试项目的简单解决方案。我们有强大的命名程序集,因此我使用Visual Studio创建了一个新的pfx文件并将相同的文件与类库和测试项目。

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

简单测试

单元测试运行正常,但未启用代码覆盖。

Simple Unit Test

添加代码覆盖率

添加一些代码覆盖率详细信息...

Add Code Coverage Detail

启用代码覆盖率测试运行

然后运行测试...

Run Test with Coverage

帮助

当然,在启用了代码覆盖率的情况下,测试可以正常执行,但是从两个项目和未组合的仪器组件中删除了强名称签名。

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

sn -p MyStrongNameKey.pfx MyStrongNameKey.snk

我在代码覆盖率详细信息重新签名密钥文件中选择的文件似乎并不重要 - 我可以选择我的.sln文件,但我得到同样的错误。

如果有人愿意,我在这里添加了解决方案:

One Drive VS2010 Solution

pfx密码为:

fernado1

我很想让代码覆盖率为此工作,但我无法看到它 - 即使是这样一个简单的解决方案。

1 个答案:

答案 0 :(得分:1)

行。我现在对我的问题有一个有效的测试代码覆盖率。

此时我使用以下命令从程序集中提取了公钥:

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

这在命令行中为我提供了以下公钥文本:

0024000004800000940000000602000000240000525341310004000001000100595757733513185e3dc44b958c76cdc1e56b73d5bd1c05a8a2b208311126cc1bc8e234a244cb1dcc3f3a25fbd82474911ce671cfd155242659a258c51d5fee8263a6a12d7a82cb98f1b5af0ac6e58afd2f02d1a8b9b34b5a4e8aa63a754830826caef3de5efe8ccbef81210a3dea0f977746b4f1d3335c1ca68d6a1894e47cb0

然后我发现这篇帖子引发了一些想法MSDN Social Forum

公平地说它不起作用。这篇文章的有趣之处在于有一个32位和64位版本的sn工具。使用sn -Vr将程序集添加到注册表时,您运行的是哪个sn.exe很重要。因此,如果您使用带有-Vr的32位版本的sn.exe来添加要跳过验证过程的程序集,然后使用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"

注意:我已经为32位和64位版本的sn.exe做了这个。我不认为注册测试项目是必需的,但我把它留在了。

所以此时我的测试仍然没有运行。

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

日志还没有透露太多。我决定使用SysInternals ProcMon。然后我运行测试以显示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位)。

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

希望这有助于其他人挣扎。可能会说,因为我一直在工厂周围,可能会有一条捷径。