code-signed dlls for .NET Core

Hi Edouard,

At the moment, we only offer code-signed assemblies for .NET Framework via the WPF Controls installer.  We do not currently have NuGet packages that contain code-signed assemblies.

Can you provide some more information on your specific needs and your scenario for wanting these?  I only ask since we haven't had requests for code-signed assemblies for .NET Core+ yet.  If you would prefer to keep that discussion offline, please create a support ticket and reference this thread.

Are you looking for code-signed assemblies within a NuGet package, or would the NuGet package itself being code-signed be enough, or both?

Hi,

Right now, we're still on .NET Framework, and we wish to redistribute code-signed assemblies to our clients. We were wondering what was the best way to do so (since for now, we're using the NuGet package to build). So when thinking about transitioning to the WPF Controls installer in order to have access to the code-signed assemblies, we noticed it didn't include .NET Core assemblies.

This made us wonder, since we intend to upgrade to .NET Core in the near future, how would we do so while keeping signed-assemblies.

Ideally, what we're looking for are code-signed assemblies within a NuGet package (for .NET Framework and .NET Core) in order to keep our current build process (.NET Framework) simple, and to be able to upgrade easily to .NET Core when we need to. We don't really need the NuGet package itself being code-signed, but I guess it can't hurt.

Hi Edouard,

Could you elaborate on the reason you are wanting to redistribute code-signed assemblies to your clients?

Also, you mentioned wanting to move to .NET Core.  Do you mean .NET 6 or .NET Core 3.1?  I ask since I believe .NET Core 3.1 is going end-of-life later this year.

In the current version, we only have code-signed copies of our assemblies built for the .NET Framework variation, and only available via our WPF Controls installer (not NuGet).  To code-sign .NET Core+ variations of the current assemblies, you'd have to get their NuGet packages, extract the .dlls from there, code-sign them yourself, and reference those signed copies.

We need to do more investigation on if code-signing assemblies in .NET Core+ is a common practice.  I don't believe many packages do it.  We have seen a couple instances where a vendor will provide ".Signed" clones of their NuGet packages that contain code-signed copies.  But that doubles our package listings and makes things more complicated.  We don't distribute code-signed copies by default because a while back, machines without internet access that would try and validate a signed assembly could experience a delay in application load times as the validation check timed out.  We are not sure if that is still an issue in .NET or not.

We are of course open to any thoughts and would love to hear what you have observed regarding code-signing from other vendors.

Hi,

We want to redistribute code-signed assemblies to our clients because we have been confronted to very restrictive antiviruses, and have had success mitigating this by signing our assemblies. We wish to sign as few external assemblies as possible, so we try to get assemblies signed by their vendor as much as possible.

We want to upgrade to .NET 6 (7), not 3.1.

We don't see any reason why code-signing would be less of a common practice with .NET Core than with .NET Framework, if anything, it should be the other way around.

We don't distribute code-signed copies by default because a while back, machines without internet access that would try and validate a signed assembly could experience a delay in application load times as the validation check timed out. We are not sure if that is still an issue in .NET or not.

According to this KB, this was an issue with .NET Framework 2.0, which was fixed back in 2007. We remember having this issue with your assemblies, and in our memory it was indeed around 15 years ago so everything seems to coincide.

Anecdotally, right now in the 2400 external assemblies we redistribute, 2155 are code-signed by their vendor.

Hi Edouard,

Thank you for the additional information.  We spent a while yesterday researching all the code signing issues as well and believe that it was mainly back in the .NET Framework 2.0 era that customers were originally reporting issues.  We found a number of other writeups over the years, and it appears that the Publisher evidence validation problems were indeed solved in .NET Framework 4 and then backported to .NET Framework 2.0 via hotfix.

Moving forward, our plan is to code-sign everything by default starting in our next major v23.1.0.  That means our NuGet packages will have code-signed assemblies at that point.  I hope that helps!