【问题标题】:Code Coverage for Strong Named Assemblies with Visual Studio Premium使用 Visual Studio Premium 的强命名程序集的代码覆盖率
【发布时间】:2015-06-25 15:35:15
【问题描述】:

当我在 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 文件并将同一个文件与类库相关联和测试项目。

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

简单测试

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

添加代码覆盖率

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

代码覆盖启用测试运行

然后运行测试...

帮助

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

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

sn -p MyStrongNameKey.pfx MyStrongNameKey.snk

我在 Code Coverage Detail Re-Signing Key 文件中选择什么文件似乎无关紧要 - 我可以选择我的 .sln 文件并得到相同的错误。

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

One Drive VS2010 Solution

pfx 密码是:

fernado1

我很想得到代码覆盖率,但我看不到它——即使是这样一个简单的解决方案。

【问题讨论】:

    标签: .net visual-studio code-coverage


    【解决方案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 添加要跳过验证过程的程序集,然后使用 64 位版本使用 sn -Vl 对其进行验证,那么它将不会显示您刚刚注册的条目。好奇。

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

    "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 位)。

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

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-01-16
      • 2017-01-25
      • 2012-10-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多