Please sign the assembly

[astrowalker]

For the record I found related issue: #990

The problem is the assemblies are not signed so when they propagate you end up with non-signed assembly at the end. When it is fine, it is fine, but when signed is required you are toasted.

The point is, please sign assemblies.

[tearvisus]

I agree. Strong naming has few drawbacks nowadays. NuGet automatically generates necessary assembly binding redirects.
The .NET open-source library guide recommends considering strong naming as well.

As an alternative, two separate packages may be created for each version: one with strong name, the other without. Math.NET projects use this approach.

[jmecosta]

i think this is really needed, workarounds like strongnamer nuget do not work becasue of design assemblies.

1>C:\Program Files\dotnet\sdk\3.0.100-preview5-011568\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(157,5): message NETSDK1057: You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
1>FSC : error FS3031: The type provider 'D:\prod\structures\ObjDrop\Work\Debug\x64\FarmiCaseHelpers\SignedAssemblies\FSharp.Data.dll' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'FSharp.Data.DesignTime' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///D:\prod\structures\ObjDrop\Work\Debug\x64\FarmiCaseHelpers\SignedAssemblies\FSharp.Data.DesignTime.dll' or one of its dependencies. The system cannot find the file specified.
1>FSC : error FS3005: Referenced assembly 'D:\prod\structures\ObjDrop\Work\Debug\x64\FarmiCaseHelpers\SignedAssemblies\FSharp.Data.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found
1>Done building project "FarmiCaseHelpers.fsproj" -- FAILED.
2>------ Build started: Project: FarmiAdapterUtils, Configuration: Debug Any CPU ------
2>FarmiAdapterUtils -> D:\prod\structures\BuildDrop\Work\bin_x64\Test\TestAdapters\FarmiAdapterUtils.dll

So this is definitely a must

[jmecosta]

@dsyme could be this considered? would make our lifes much easier

[dsyme]

What scenario leads you to need strong naming? I assume it is to do with .NET Framework in some way?

For .NET Core see https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named and https://docs.microsoft.com/en-us/dotnet/standard/assembly/create-use-strong-named, e.g.

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

[cartermp]

Yeah, it's for .NET Framework. It's a recommended practice in the published .NET library authoring guidelines here: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming#create-strong-named-net-libraries

[ReedCopsey]

@dsyme and @cartermp FYI - This was needed for integration with 3rd party libs that also require COM support. The 3rd party library plugin API is .net framework, and requires use of /codebase registration, which requires signing - see: https://docs.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool

It's .NET Framework, and unavoidable (other than just not using fsharp.data) as far as I can tell at this point.

[cartermp]

Closing, released

[jmecosta]

thanks @cartermp @dsyme