none
Unable to obtain public key for StrongNameKeyPair - TeamTest

    Question

  • Has anyone gotten unit testing to work with strong named assemblies (using a password protected PFX)?

    I found this discussion, but it doesn't seem to help.

    I had no problem building this solution until I added strong naming on the build server. Now I'm getting the above error when it tries to build the test project. These tests pass on my local machine using the SNK (delay signing) and validation disabled for that SNK locally.

    If I test the very assembly reported in the message for signing, it passes. Could this be a permissions issue, wherein the account can't access the public key in the referenced (just built) assembly?
    Thursday, May 28, 2009 9:08 PM

Answers

  • Actually, I tested my suggestion before I posted. Here are my settings:

    Non test projcts:
    ----SignAssembly=true
    ----DelaySign=true
    ----AssemblyOriginatorKeyFile=path/publickKey.snk

    Test projects:
    ----SignAssembly=false

    <AssemblyOriginatorKeyFile> property:
    ----DelaySign=false;AssemblyOriginatorKeyFile=path/mykey.pfx;

    Therefore, SignAssembly property will not be overriden.


    I tested this issue in VS 2010 Beta 1 now. But unfortunately, it has not been resolved yet. I will report it.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    • Proposed as answer by Bill.Wang Thursday, June 25, 2009 11:34 AM
    • Marked as answer by Bill.Wang Thursday, June 25, 2009 11:43 AM
    Thursday, June 25, 2009 11:21 AM
  • I missed your most important point. I'm sorry.

    Ok, so individually control the signing in the csproj files and just overwrite the delay sign and assembly key file properties via the override. Got it!

    It's easy to get lost in the details and lose sight of obvious solutions when you're stuck on something for as long as I have been!
    • Proposed as answer by Bill.Wang Thursday, June 25, 2009 11:34 AM
    • Marked as answer by Bill.Wang Thursday, June 25, 2009 11:43 AM
    Thursday, June 25, 2009 11:31 AM

All replies

  • Hi Todd

    In Grant's blog, there's a section "Disable Strong-Name Verification on Developer Workstations".  Could you please perform the same steps at the build agent, then start the team build again? If it doesn't help, could you please let us know your steps that you add signing to team build so that we can reproduce this issue?
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Friday, May 29, 2009 8:21 AM
  • Thanks, Bill.

    I tried this step on the build server, under the build account and it failed, due to permissions.

    C:\BUILDS\certs>sn -Vr *,1275e79010923120
    
    Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.30729.1
    Copyright (c) Microsoft Corporation.  All rights reserved.
    
    Failed to open registry key -- Access is denied.
    This intrigues me. I wonder if this registry permission issue is actually causing the problem in the first place. I can't understand why the building of the test project would fail because by then the assembly being tested has already been strong named. So ... could it be that the build agent account doesn't have rights to even query about the strong name of an assembly?

    I had an admin issue the above command and the build ... still fails. Same issue.

    Unable to obtain public key for StrongNameKeyPair.

    This sounds like a thread I found by Oren Eini on Rhino Mocks failing. I'm not sure how to proceed. I don't want to harrass the admin guy with a ton of experiments that I don't really understand in the first place.

    ps: you seem to be answering questions in the middle of night, regardless of time zone. What's up with that? :)
    Friday, May 29, 2009 4:35 PM
  • I remember I have meet the same problem as you described a few monthes ago. But I can't remeber the details and how it got sovled. But I'm sure I haven't modified any registry settings manually as that in http://ayende.com/Blog/archive/2006/06/09/UnableToObtainPublicKeyForStrongNameKeyPair.aspx.

    For troubleshooting purpose, could you add TfsBuild account to Adminitrators group in build agent, run command prompt with Administrator and execute the sn -Vr command?

    By the way, in "Installing the Private Key for Team Build" section of Grant's blog, in order to pop up the password dialogbox, you can kick off build like this: 
    CD C:\Windows\Microsoft.NET\Framework\v3.5
    MSBuild mysolution.sln /p:AssemblyOriginatorKeyFile=MyKey.pfx;DelaySign=false
    After the password is stored, you can remove the TfsBuild account from Administrators group.

    When it comes to my last post, I'm in China, which is in +8 time zone. :).  I have been busy recently and need to work at night sometimes.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Monday, June 01, 2009 6:00 AM
  • This is so much fun!

    When I hit the above mentioned error, it was under the build account, which *IS* an admin!

    I ran Process Monitor while attempting the command and the registry key failure is on

    HKLM\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\*,1275e79010923120

    This entry was already present, from the run under the admin account. Interestingly, the administrators group already had permission to this element, but by adding "Everyone", I was able to re-issue the "-vr" statement. Facinatingly, if I then removed the "everyone" group, I could still issue the command under the build account. If I remove all exclusions (Vx), I again get the failure trying to add it back. I had to add "everyone" to the permissions. This is just wierd.

    Now ... none of this helped, though. I've been unable to determine why the build of the test project is failing. I've tried monitoring it with process monitor, but have yet to see anything useful.

    Another important point is that the very file that caused the failure in the build of the test assembly passes verification, just fine under that account.  So from what I can tell, the assembly's built and signed legitimately, but when the test assembly built, it can't locate the public key from the references assembly. sigh.

    I've tried drilling into BuildShadowTask to try to figure out what it's doing, but that didn't seem to get me far.
    Monday, June 01, 2009 5:01 PM
  • As you figured out, sn - Vu and sn -Vr command need modifying retgistry settings under HKLM key. If UAC is turned on, you need to run sn with elevated mode in order to change keys under HKLM even if you are an administrator. To do this, you can simple right click Command Prompt in Start menu and select Run as administrator, then type in the sn commands.

    In my computer, this issue doesn't occur. Here are some configrations I used.
    • In the Code Coverage tab of .testrunconfig file, "Instrument assemblies in place" is not checked. The "Re-signing key file" field is blank.
    • In the team build project file, RunConfigFile property is set to the path of the .testrunconfig file. Thus the .testrunconfig file is passed to the MSTest command line tool during the build.
    • The test project is not signed with any strong name key file.
    • In the build agent, when I run sn -Vl, it shows all assemblies with the public key token are skipped for strong name verification.

    If you are using the same configuration as mine, could you mail me your team build project file and the build log? I think they will be very helpful for further troubleshooting.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Tuesday, June 02, 2009 8:12 AM
  • Hi Todd

    Is this issue resolved?
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Friday, June 05, 2009 8:23 AM
  • Hi Bill.

    I haven't been able to compile test projects yet. Obviously, we want to!

    I experimented quite a bit on the build machine with the concept of disabling verification of the strong name. I could disable it. I verified this. But the build would still complain.

    I monitored the process with "process monitor" (kicked off a build), but saw no permissions failures, either in the file system or the registry.

    I simply have no idea what the real source of this failure is.

    Finally, it's concerned me, right from the beginning, why the strong name couldn't be verified on an assembly that was JUST compiled by the same build process. Why would it fail? And why wouldn't I be able to verify it on that machine?

    Thanks!
    Friday, June 05, 2009 10:04 AM
  • Finally, it's concerned me, right from the beginning, why the strong name couldn't be verified on an assembly that was JUST compiled by the same build process. Why would it fail? And why wouldn't I be able to verify it on that machine?

    Thanks!
    Well, I'm not able to give you a solid answer now. Would you mind mail me the folowing files so that I can do more analysis?
    1. Team build project file.
    2. Build log.
    3. Test resuts.
    4. Test run configuration file
    5. Setup and Cleanup batch files if they are used.

    You can zip them and mail to me via v-bilw@microsoft.com. I will let you know what I can find.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Monday, June 08, 2009 4:41 AM
  • Hi Todd

    Has this issue been resolved? If not, you can try logging to the build agent to build the solution in VS with the possward protected key. Building in VS should probably give us more information about the compile time errors.  

    Another thing is that VS may add InternalsVisibleToAttribute to your project to test classes with internal modifier. If this attribute is used in your strong name signed projects, you will need to specify public key to it. Otherwise there will be compile time erros too.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Friday, June 12, 2009 9:41 AM
  • I just got around to yet another stab at this pesky problem. Still no dice.

    If I load the solution interactively (build account) and strong name it with the same pfx that Team Build is using (replacing the delayed signing SNK that the projects are compiled with on the developer's machine) I get the same failure.

    Error 3 Error occured during processing of assembly 'C:\builds\Work\27\Sources\Dev\SiteDataEmailExtractor\SiteDataEmailExtractor\bin\Debug\SiteDataEmailExtractor.exe': Unable to obtain public key for StrongNameKeyPair. SiteDataEmailExtractorTests

    I have verified that the InternalsVisibleToAttribute is correct in the main project. It grants access to the test project, specifying the public key that both are signed with.

    I can even extract the public key from the main binary with "sn -Tp 'C:\builds\Work\27\Sources\Dev\SiteDataEmailExtractor\SiteDataEmailExtractor\bin\Debug\SiteDataEmailExtractor.exe" and it matches. So I know the main project's signed. Can also verifiy it with "sn -vf".

    Now, the pfx is password protected. I had previously entered the pw during a manual build, which was a hold up for a while, trying to get my assemblies strong named during the team build. So that part should be good. In fact, I'm not prompted for a password during this round of interactive building. I'm able to build the main exe and extract the public key, as just described above.

    I surrender!!! I'll email the requested files.
    Wednesday, June 24, 2009 3:13 PM
  • Hi Todd

    Thanks for sending me the log!

    I noticed that the error occurs in the BuildShadowTask, which is used to generate the private accessor. Previously, I didn't add private accessor for my assembly so I couldn't able to reproduce this issue. Your build log is very informative and I was able to reproduce this error. It occurs when:
    1. The test project contains private accessors.
    2. The test project is signed strong name with a password protected key file.


    This is a known issue for Visual Studio 2008. I'm using VS 2008 SP1 and it still repro. There are currently 2 workarounds I will recommend:

    • Turn off strong name signing for the test projects.
      In most cases, we don't deliver test projects to customers so turning off strong name signing for test projects should not be a problem. To do that, You can
      • In the Property page of all non test projects, CHECK "Sign the assembly".
      • In the Property page of all test projects, UNCHECK "Sign the assembly".
      • In the team build project, set CustomPropertiesForBuild property to   <CustomPropertiesForBuild>DelaySign=false;AssemblyOriginatorKeyFile=path/mykey.pfx;
        </CustomPropertiesForBuild>  
        Since "SignAssembly=true;" is removed, test projects will not be signed.
       
    • Use a key pair that is not possward protected of course I guess this is not what you want.

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Thursday, June 25, 2009 3:17 AM
  • Thank you, Bill. I was able to reproduce the issue w/o team build, by signing the test project locally.

    I didn't explicitly want to sign the test project, but my team build model uses CustomPropertiesForBuild to pass the signing properties into the solution at build time. This meant every project was signed the same way.

    I got around this yesterday by explicitly changing project properties of all projects except for test projects in AfterGet, introducing signing logic directly into the corresponding csproj files.

    Is this issue on the "to be fixed" list?

    Thanks again.
    Thursday, June 25, 2009 10:49 AM
  • MSBuild properties in CustomPropertiesForBuild do override the project level setings. My point was that don't set "SignAssembly=true" in the CustomPropertiesForBuild. Instead, configure SignAssembly property to true in the non project files like .csproj or .vbproj. And configure SignAssembly property to false in the test project files.

    Without setting SignAssembly to true, a project will not be signed regardless the settings of DelaySign and AssemblyOriginatorKeyFile.


    I will check if this issue is resolved in VSTS 2010 Beta 1 and let you know.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Thursday, June 25, 2009 11:04 AM
  • But my intent is most certainly to override the signing properties at team build time. How else can aproject be signed by a key file that only exists on the build server?

    Locally, projects are all signed with the public key, using delay signing.

    Team build then needs to override this, clearing the delay sign flag and specifying the private key file.

    So you see, in order to override signing, I have to do so globally via the menioned property or individually by updating the corresponding csproj files prior to building.

    The mile-high view of what I'm trying to accomplish is documented all over the net. What I haven't seen is low level details of how others have implemented the solution. If I'm missing something, I'm not aware of it.

    Thursday, June 25, 2009 11:13 AM
  • Actually, I tested my suggestion before I posted. Here are my settings:

    Non test projcts:
    ----SignAssembly=true
    ----DelaySign=true
    ----AssemblyOriginatorKeyFile=path/publickKey.snk

    Test projects:
    ----SignAssembly=false

    <AssemblyOriginatorKeyFile> property:
    ----DelaySign=false;AssemblyOriginatorKeyFile=path/mykey.pfx;

    Therefore, SignAssembly property will not be overriden.


    I tested this issue in VS 2010 Beta 1 now. But unfortunately, it has not been resolved yet. I will report it.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    • Proposed as answer by Bill.Wang Thursday, June 25, 2009 11:34 AM
    • Marked as answer by Bill.Wang Thursday, June 25, 2009 11:43 AM
    Thursday, June 25, 2009 11:21 AM
  • I missed your most important point. I'm sorry.

    Ok, so individually control the signing in the csproj files and just overwrite the delay sign and assembly key file properties via the override. Got it!

    It's easy to get lost in the details and lose sight of obvious solutions when you're stuck on something for as long as I have been!
    • Proposed as answer by Bill.Wang Thursday, June 25, 2009 11:34 AM
    • Marked as answer by Bill.Wang Thursday, June 25, 2009 11:43 AM
    Thursday, June 25, 2009 11:31 AM
  • Hi Todd

    You expressed what I meant to say in just one sentence! :) It seems I still have a long way to go to study English.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Thursday, June 25, 2009 11:33 AM