Posted 25 days ago by Edouard Lemoine
Version: 22.1.3
Avatar

Hello,

I'm wondering where I could find code-signed dll for .NET Core. According to the documentation, code-signed dlls are only available via the installer, however, .NET Core assemblies are not included in the WPF Controls installer.

The ideal solution would be a nuget package containing the code-signed dlls.

Comments (5)

Posted 25 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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?


Actipro Software Support

Posted 24 days ago by Edouard Lemoine
Avatar

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.

[Modified 24 days ago]

Posted 24 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

The latest build of this product (v22.1.3) was released 23 days ago, which was before the next post in this thread.
Posted 22 days ago by Edouard Lemoine
Avatar

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.

[Modified 22 days ago]

Answer - Posted 22 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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!


Actipro Software Support

Add Comment

Please log in to a validated account to post comments.