This project is read-only.


Dlls in Nuget packages are not strong signed


My solution uses only strong signed assemblies, and as such adding Catel packages prevent me from building a release version..
This is very annoying, and till now I've faced this issue only with another package.

I've proposed several times to Nuget team to NOT allow unsigned dlls in public packages, or at least to require a mandatory flag to document the presence of unsigned dlls in a package...

Can we expect signed dlls in Nuget in the near future, or at least a downloadable bundle including strong signed dlls?

I know that we can simply build from source and sign ourselves, but then what's the benefit from using Nuget??

Closed Jan 6, 2013 at 2:41 PM by GeertvanHorrik
Closed due to no response.


GeertvanHorrik wrote Nov 8, 2012 at 10:38 AM

Why are you signing your application assemblies?

nexbit wrote Nov 8, 2012 at 11:22 AM

It's required by several post build steps.. in particular for obfuscation.
I'm not a great fan of obfuscation, but my client is... ;)

By the way, what's the point to not sign a public released library?
For private and internal development, I know it could be a nightmare, but when someone decides to use a 3rd party dll, he expects a signed one. All commercial libraries that I use are strong signed. All MS dlls are strong signed.

In addition, what if I want to put it (the library) in the GAC? And if I want to put my library that uses your library in the GAC? Without strong signing I can't.

The overall signing procedure that MS put in place can be questionable, but we have to deal with it...

GeertvanHorrik wrote Nov 8, 2012 at 5:51 PM

For what kind of obfuscation is signing required? Can you give an example?

nexbit wrote Nov 8, 2012 at 7:08 PM

Indeed, it is not directly related to obfuscation step, but to runtime anti tamper protection added by the tool, that is tied also to the licensing mechanism.

In essence the strong name of the exe is used to detect tampering even if the verification skip-list is enabled on the target machine, and in addition the licenses for the software embeds a derived key used to detect tampering when the license is validated by the online license service.

Even if I didn't face the above problem, using a non-signed assembly prevents me to put a library that uses your dlls in the GAC.
For example what if I want to use only the Catel.Core facilities to make a common dll that serves many different WPF apps on the same machine?

Sorry to insist on that, but I really can't see the point against strong signing libaries.
I agree to not sign EXEs if u haven't a valid reason to do so, but for libraries the standard (at least the MS standard) is signing them when releasing to the public. And highlight "public" here, as this isn't necessarily true for internal libraries...

Other reasons in random order:
  • Using an unsigned dll expose an application to security risks. I can replace your dll with a hacked one, and the app will not complain about that. Doing so I can inject any code in the execution path of the application.
  • I can't use publisher policy and version redirection directives to get rid of multiple versions of the same assembly
So my reflected question: is there any reason why u don't sign Catel assemblies?


SimonCropp wrote Nov 16, 2012 at 1:38 PM


Are you on google chat? if so can we have a chat sometime? I am on both chat and email.

Or perhaps skype??

I think this discussion needs to be done with a smaller feedback loop

GeertvanHorrik wrote Nov 26, 2012 at 6:58 PM

Not for 3.4, if we implement it at all.

GeertvanHorrik wrote Nov 13, 2014 at 11:33 AM

Doing x because FxCop tells you to is wrong reasoning. Just because some guy at ms created the rule doesn't say it makes sense. Luckily you can also strong name yourself afterwards which would solve the issue for you.