search

spectreconsole / wcwidth

A .NET library that calculates the width of Unicode characters.
MIT License
49 stars 13 forks source link

Add .NET Framework 4.5 and strong name signing #1

Closed bastianeicher closed 3 years ago

bastianeicher commented 3 years ago

This PR adds a .NET Framework 4.5 build target to the existing .NET Standard 2.0 target (which can be used for .NET Framework 4.6.1+).

It also adds strong name signing. While this is losing importance in the .NET Core era, MS guidelines still recommend strong-name signing for open-source libraries: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

patriksvensson commented 3 years ago

@bastianeicher Thanks for taking the time to do this. However, I do not wish to add the extra support burden of supporting net45 and strong naming. Is there a specific reason you want to add this to this library?

bastianeicher commented 3 years ago

I would like to use your library Spectre.Console (which has a dependency on Wcwidth) in Zero Install which targets .NET Framework 4.5 and .NET 5.0 and uses strong naming (and can therefore only use dependencies with strong naming).

I've adjusted the PR to include a reference to Microsoft.NETFramework.ReferenceAssemblies, allowing the build to succeed without .NET Framework 4.5 installed (e.g. during CI builds).

patriksvensson commented 3 years ago

@bastianeicher While I sympathize with your problem, I have no intention of supporting .NET framework or strong naming in Spectre.Console either. I could stretch myself to support strong naming if there was a good enough reason, but not .NET framework. Sorry.

My recommendation would be to drop net45 and strong naming to use Spectre.Console in your project or use something like StrongNamer.

bastianeicher commented 3 years ago

Ok, thanks for the feedback.

I do intend to retarget to .NET Framework 4.6.1 sooner or later, so that problem will take care of itself.

Unfortunately StrongNamer is not really an option for me, since I also publish NuGet packages for others to consume, so they'd have a transitive dependency on a still-unsigned Spectre.Console. I suppose the only arguments I can make for strong naming are: adding it is pretty easy, it has no runtime impact (therefore shouldn't add to the support burden) and MS recommends it since it increases the number of projects that consume a lib.