From: Foster, Richard - PAL [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 22, 2005 2:29 PM
To: Whitner, Tom
Subject: RE: [Nant-users] Strong Names - Delay Signing - Relative PathsTom,In what way does the build fail within NAnt? Is it by any chance complaining about running the tests? If so, you probably need to add an appropriate validation entry on your build machine (E.g. use sn -Vr *,<your public key>).In our configuration we use the <asminfo> task to set the appropriate public key file (using an absolute path in a NAnt property), then use the <delay-sign> task on our continuous integration machine to complete the signing process after a successful build & test cycle.Regards,Richard
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Whitner, Tom
Sent: Tuesday, February 22, 2005 13:51
To: [email protected]
Subject: [Nant-users] Strong Names - Delay Signing - Relative PathsHello,
Is anyone out there actually signing assemblies? I am working through automating this with NAnt. Of course, I want the process to actually sign the assemblies when run on our build server, but only partially sign (with public key only) when built on a developer's workstation. Also, I want the solution to build with both NAnt and Visual Studio. I figured key containers would simplify this. However, I have not been able to install just the public key into a container. So, I am back to key files for the developer builds. Unfortunately, if I set the relative path in the KeyFile attribute to work from VS, the build fails from NAnt. I am using the <solution> task to build the solution. Could this be a bug in the solution task?
Thanks,
Tom
Title: Strong Names - Delay Signing - Relative Paths
I get the following error "error CS1548: Cryptographic
failure while signing assembly 'MyAssembly.dll' -- 'Error reading key file
'A.snk' -- The system cannot find the file specified. ' " I found
this knowledge base article http://support.microsoft.com/default.aspx?scid=kb;en-us;328379 which
references to VS2002. My experimenting has shown that this path is now
relative to the sln file in VS2003. I am suspecting this is an issue with
the <solution> task and C#.
- Tom
