Language-ext: Strong Naming

[michael-wolfenden]

Microsoft have just published their guidance for creating .NET libraries and are now recommending that publicly distributed .NET libraries should be strongly named.

As a library author myself, I understand what a pain this is and that there are ramifications to strong naming, however the reality is that as more libraries start strong naming themselves, fewer will be able to use this library (a strong named assembly can only reference other strong named assemblies).

I wanted to bring this up for discussion again. I'm happy to do the work, but the change would be a breaking change.

[louthy]

there are ramifications to strong naming

What are they? And how much pain does it involve for this project and the users of it?

I'm happy to do the work, but the change would be a breaking change.

What's involved? Is there an ongoing cost?

[michael-wolfenden]

The are three main ramifications

1) Strong naming is a breaking change
2) A strong named assembly can only reference other strong named assemblies
3) A strong-named assembly reference must exactly match the version referenced by an assembly. So if I have a reference to myAssembly 1.2.0 and import a package that references myAssembly 1.2.3 a binding redirect will need to be configured.

NOTE: This issue is isolated to the .NET Framework. .NET Core, Xamarin, UWP, and most other .NET implementations don't have strict assembly loading and removes the main downside of strong naming.

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="1.2.3"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

In regards to LanguageExt.Core this means

1) A new major version 4.0.0 will need to be published
2) This library doesn't appear to reference any non strongly named assemblies so this doesn't affect you.
3) There are two options

• Do nothing: The chance that a library or application are dependening on multiple versions of LanguageExt.Core are low, and if there are assembly version mismatches a binding redirect can be added (which visual studio does automatically these days). Also note this only affects .NET Framework.

• Do what Newtonsoft.Json and larger libraries do and pin the assembly major version. This way LanguageExt.Core 1.2.0 and LanguageExt.Core 1.2.3 both have an AssemblyVersion of 1.0.0.0 and the highest nupkg version will be used. So LanguageExt.Core.1.2.3.nupkg would have

<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.2.3.0</FileVersion>
<AssemblyInformationalVersion>1.2.3.0</AssemblyInformationalVersion>

What's involved? Is there an ongoing cost?

All you need to do is check Sign the assembly and create a new strong name key file

1) Do not give it a password
2) Make sure it's checked into source so that anyone can compile the project

From then on, your built assembly will be strongly named

More information can be found here

[TysonMN]

1. Strong naming is a breaking change

...

1. A new major version 4.0.0 will need to be published

I don't think @louthy (strictly) follows semantic versioning.

[EdwinEngelen]

I also need strong named assemblies.
Any updates on this issue?

[tafs7]

why not build two packages - one strong-named and one not - every time you publish a new release?