StrongNaming for nuget package
edud69 opened this issue · comments
Description
The latest nuget package (v2.0.21) contains the FSharp.Control.AsyncSeq.dll which is not strongly named. Having a project that is strongly named that depends on this library will fail, except if a third party (such as StrongNamer) is used.
Repro steps
Create a project that is signed, have this project depend on this library.
Execute the project. It will fail runtime.
Expected behavior
Signed assemblies should be able to run this library without third party StrongNamer.
Actual behavior
Runtime will fail if a signed project tries to load the library.
Known workarounds
A third party such as StrongNamer is needed on strongnamed projects that depend on this library.
Related information
n\a
While having a strong named version is needed in some scenario, it make noise for normal .NET users who doesnt need it and after strong naming need to add assembly binding redirects.
As you said, to have it signed is possibile to use strongnamer in the consumer app/lib and it can be set it as development dependency too (PrivateAssets="All in fsproj or developmentDependency=true in nuspec) so is not added to dependency list of the consumer app/lib.
As a note, if strong naming need to be done, it require:
- a bump to a major version (v3), because strong naming is a breaking change
- set the assembly version to a fixed version, so doesnt break each new package.
@edud69 there was a previous version of FSharp.Control.AsyncSeq who was already strongly signed? i am checking but didnt yet found one.
I don't think there was any version that was previously strongly signed also.