Strong-name sign ClosedXML and deprecate ClosedXML.Signed package

Do you want to request a feature or report a bug?

• Feature

Did you test against the latest CI build?

• Yes

If you answered No, please test with the latest development build first.

Version of ClosedXML

e.g. 0.95.3

What is the current behavior?

At the moment there are two distinct nuget packages for ClosedXML:

• ClosedXML (not signed with strong-name)
• ClosedXML.Signed (signed with strong-name)

Given improvements in .NET Core (re: binding redirects) and recent updates to Microsoft’s guidance on strong-naming, I’d suggest we strong-name the ClosedXML assembly, and retire the ClosedXML.Signed package.

Any objections before I put together a PR?

---

Related links:

• Strong Name Signing, dotnet/corefx
• Strong naming guidance, docs.microsoft.com
• Build great libraries using .NET Standard

[Pankraty]

Wow, now it is way more clear. Looks convincing for me. Thanks for the effort of providing such a detailed explanation!

[augustoproiete]

@Pankraty No worries!

Indeed, binding redirects got a lot better since .NET 4.5 and the undesired side-effects of strong-naming assemblies are mostly gone in the .NET world, and completely gone for .NET Core/.NET 5 thus it can only get better with time.

Thus if you don’t don’t have a strong opinion on either side, I suggest we move forward with the plan above and sign ClosedXML only, keeping ClosedXML.Signed for a while to give people (including the core dev team) more time to move to the newest ClosedXML that will also be strong-name signed.

---

Re: "we do not fork our developer ecosystem" - We actually do. What they mean here is that other developers that want to extend ClosedXML and build other packages on top of it, now have to choose between ClosedXML and ClosedXML.Signed to take a dependency on: That’s the fork.

As an example, let’s look at popular packages (according to nuget.org) that extend ClosedXML today:

• DoddleReport.OpenXml, depends on ClosedXML
• DataBooster.DbWebApi.SqlServer, depends on ClosedXML.Signed

As you can imagine, an app that needs to use both packages in their application will most likely run into issues using these together. In the best case scenario, the app runs but they won’t be able to share any ClosedXML instances between these libraries, because in the eyes of .NET Framework the assemblies are not the same, and thus the types are also not the same, despite having the same namespace & name. In the worst scenario the app won’t even run and will thrown a TypeInitializationException.

---

Another reason for signing the main assembly is the classic scenario that affects anyone that needs to strong-name sign their application or library, and share internal classes with another projects via InternalsVisibleTo and the project where InternalsVisibleTo applies uses ClosedXML or references another library that does.

Because the assembly exposing internal types is signed, it requires that the library accessing the types to be signed as well (even though the main project doesn’t reference it) and, of course, it cannot be signed because of ClosedXML being in the chain and not having a strong-name.