Delayed Signing, the GAC, and Installations

[Bill]

I have a shared C# class assembly that I am trying to give a
strong-name so I can install it into the GAC on the target machine.
Without delay signing, I've successfully been able to do this by
performing the following steps:

1. Create a public/private key pair by doing the following:
sn -k pubpriv
2. Build and sign the assembly with the following code in the
AssemblyInfo.cs file:
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile(@"..\..\pubpriv")]
3. Create and Build a Setup project and place the Primary Output of
the shared assembly project into the "Global Assembly Cache Folder".

The installation succeeds and the assembly is in the GAC. However,
when I try to delay sign the assembly I get an error during
installation. Here are the steps I took in this instance:

1. Create a public/private key pair by doing the following:
sn -k pubpriv
2. Export the public key into a new file by doing the following:
sn -p pubpriv pub
3. Build and delay sign the assembly with the following code in the
AssemblyInfo.cs file:
[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyKeyFile(@"..\..\pub")]
4. Sign the assembly with the private key by doing the following:
sn -R ClassLibrary1.dll "..\..\pubpriv"
5. Create and Build a Setup project and place the Primary Output of
the shared assembly project into the "Global Assembly Cache Folder".

The installation fails with the following error: "An error occured
during the installion of assembly component. {guid} HRESULT:
-2146234299".

Any idea what I'm doing wrong? How do I know that Step 4, where I sign
the assembly, really works other than the message the sn tool gives
me? The modification date on the assembly doesn't change when I run
this, which makes me think that the assembly was never really signed
afterall. Has anyone had this problem?

Thanks.

 

[Nicole Calinoiu]

What happens if you attempt to add the fully signed assembly to the GAC
manually? Is the problem perhaps that your setup project uses the build
product of a VStudio project rather than the fully signed DLL from disk?

 

[Bill]

Nicole,

Thanks for your response. You brought up some good questions. The answer
to your first one is yes, after delay-signing the assembly I am able to
use gacutil to add it to the GAC.

Your second question is making me wonder. To create the Setup project,
I've add the "Primary Output" for the project that compiles to the
signed assembly, which called ClassLibrary1 . Maybe the problem is that,
when I build the Setup project, it rebuilds the ClassLibrary1 dll and it
is no longer signed? If that is the case, what is the process for
delay-signing assemblies and including them in a Setup project?

Thanks!

 

[Nicole Calinoiu]

Nicole,

Thanks for your response. You brought up some good questions. The answer
to your first one is yes, after delay-signing the assembly I am able to
use gacutil to add it to the GAC.

Your second question is making me wonder. To create the Setup project,
I've add the "Primary Output" for the project that compiles to the
signed assembly, which called ClassLibrary1 . Maybe the problem is that,
when I build the Setup project, it rebuilds the ClassLibrary1 dll and it
is no longer signed?
Yup.

If that is the case, what is the process for
delay-signing assemblies and including them in a Setup project?

Manually add the fully signed DLL to the setup project instead of adding it
as a project primary output. Instructions for adding a file to a setup
project can be found at
http://msdn.microsoft.com/library/en-us/vsintro7/html/vbconaddingitemstodeploymentproject.asp.
Once you remove your project output from the setup project contents, you
might also need to add back some other files (e.g.: images, application
configuration file, or other supporting files) from your DLL project if they
need to be included in the distribution package
..

 

[Bill]

That's really the only way to do this? Seems like there should be a way
to include the Primary Output to get the benefit that brings, but still
be able to delay sign the assembly.

While I have you here, have you deloyed applications where you have used
delay-signing in a team environment? After doing some research, I've
learned that smartcards seem to be the way to safely generate keys. Have
you had any success with doing this?

Thanks Nicole.

 

[Nicole Calinoiu]

That's really the only way to do this? Seems like there should be a way
to include the Primary Output to get the benefit that brings, but still
be able to delay sign the assembly.

Not that I know of, but you might have better luck asking the question in a
setup newsgroup.

While I have you here, have you deloyed applications where you have used
delay-signing in a team environment?
Yes.

After doing some research, I've
learned that smartcards seem to be the way to safely generate keys. Have
you had any success with doing this?

Where have you seen this recommendation? You can generate a key quite
safely with sn.exe. Key storage is another issue. Offline, physically
secure storage is recommended if you need to keep the private key safe from
even your IT staff.

 

[Bill]

Here is the article that got me interested in the smartcard usage:
http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/
dnnetsec/html/strongNames.asp

Basically, it says that using sn.exe to create the keypair on a
hard-drive could expose you to malicious attempts to find the private
key, even after you delete the pair. But if you generate the keys on a
smart-card and safely store it in the company safe, you can ensure that
nobody will be able to remotely find your private key.

I'll pose my setup question to the setup newsgroup. Thanks for helping
me out, you've helped a lot.

 

[Todd Derksen [MSFT]]

Todd Derksen
Hopefully I can offer a little help on the delay sign issue mentioned
earlier.
What is happening is that Visual studio detects the file has changed since
it built it (the signing of it)
What you can do to use project output is do the signing in the post build
event of the C# dll, this will cause it to build every time you build teh
setup project however it will be signed before it is included in the setup
project.

 

[Nicole Calinoiu]

Umm, little detail... Why would one bother with delay signing if it's
acceptable to fully sign as part of one's within-VStudio build process?

 

[Bill]

Todd, you make a good point and that may be what I do. Thanks.

Nicole, I also see your point, and I'd like to get more information from
you. I'm guessing that the development team should not be responsible
for signing the assemblies. They should use delay-signing with the
public key, and then QA or whatever team is responsible for testing
should handle the signing of the assemblies before generating the
Installation packages. If that's the case, how can I work the eventual
signing of the assemblies by QA into an automated build process? I am
using BuildIt
(http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_app.asp?frame=t
rue) to automate the build. Todd's sugguestion would work but it would
also make the signing part of the development process which, like you
said, goes against the goal of delay-signing.

Thanks guys!

 

[Nicole Calinoiu]

Todd, you make a good point and that may be what I do. Thanks.

Nicole, I also see your point, and I'd like to get more information from
you. I'm guessing that the development team should not be responsible
for signing the assemblies. They should use delay-signing with the
public key, and then QA or whatever team is responsible for testing
should handle the signing of the assemblies before generating the
Installation packages.

Well, that all depends on your process and who you think can be trusted with
the private key. Personally, I think it's a wee bit odd to have QA either
signing assemblies or generating installation packages, but maybe it makes
sense in your organization.

To be honest, I'm also not quite sure why you object to manually building up
the content list for a setup project. It's a bit more work (say, maybe 1/2
an hour more for a medium-large project), but this extra work only needs to
be done once, and the extra control over package content can sometimes save
time troubleshooting later on. I've been creating setup projects this way
for quite some time now, and I really don't see it as much bother at all.

If that's the case, how can I work the eventual
signing of the assemblies by QA into an automated build process? I am
using BuildIt
(http://msdn.microsoft.com/library/en-us/dnbda/html/tdlg_app.asp?frame=t
rue) to automate the build. Todd's sugguestion would work but it would
also make the signing part of the development process which, like you
said, goes against the goal of delay-signing.

Again, the whole setup seems a wee bit odd to me, but I guess it depends on
the role of QA in your organization. In mine, QA works against installed
applications in order to ensure that both the applications and their
installation-time configurations are tested. QA would never need to compile
or sign an application, nor would they build installation packages.