|
Have your script copy the key to the
relative path. Payton
Byrd Trane eBusiness QED Team Phone:
931-905-5386 Fax: 931-648-5901 From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Whitner, Tom I
just discovered an article (http://blogs.msdn.com/shawnfa/archive/2004/04/15/114258.aspx) that
indicates that the path in the AssemblyKeyFile attribute is relative to the
output folder. This is insane yet explains why my NAnt build fails while
my VS build succeeds. Each has different output directories.
Thankfully, this looks to be fixed in Whidbey. Any thoughts on how to
tackle with w/o another build config? -
Tom ------------------------------------------
Hello,
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,
|
Title: Strong Names - Delay Signing - Relative Paths
- [Nant-users] Strong Names - Delay Signing - Relative Paths Whitner, Tom
- [Nant-users] Strong Names - Delay Signing - Relative Pat... Whitner, Tom
- RE: [Nant-users] Strong Names - Delay Signing - Relative... Byrd, Payton
- RE: [Nant-users] Strong Names - Delay Signing - Relative... Whitner, Tom
