Signing the nuget package

[wowyzga]

Could you please sign the nuget package. I'm getting errors when including your package in a project:
Error CS8002 Referenced assembly 'EFCore.BulkExtensions, Version=2.4.3.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

[SailorTurkey]

I have this problem reversed. My project is NOT signed, nor ise EFCore.BulkExtensions. But God knows why, its referencing FastMember SIGNED, Please release a nuget package referencing UNSIGNED FastMember package too, thank you.

[borisdj]

In latest Nuget FastMember.Signed is replaced with FastMember.
As for the signed verison of lib. I couldn't find a Certificate to Sign it properly.

[danstur]

@borisdj Would you accept a PR that handles this? The idea would be to fix the AssemblyVersion and only increase it when the major version is increased (i.e. when breaking changes are introduced).

This gives what I'd consider the best experience: You get a warning if you try to use incompatible versions, which you can explicitly ignore with binding redirects. For minor versions if two NuGet packages require different versions, NuGet resolves the higher version which is then installed. No binding redirects are needed and everything just works as it should.

I'd simply add an additional csproj, but share all the relevant information between the two projects to avoid duplication.

[304NotModified]

Please sign this package. All MS packages are signed and other large OSS projects are doing this. (e.g. Json.NET)

If we are doing semver here, it's recommend to use only the major version name in your assembly. (so 1.0.0.0, 2.0.0.0 and currently 3.0.0.0) - also others are doing that (like Json.NET)

[flensrocker]

@borisdj You don't need a certificate.

• Call sn -k EFCore.BulkExtensions.snk in the directory EFCore.BulkExtensions to create a key pair.
• Add this file to the repository
• Edit the properties of the project on the signing tab: activate signing and select the snk-file
• Use FastMember.Signed instead of FastMember

Diff of the project file:

diff --git a/EFCore.BulkExtensions/EFCore.BulkExtensions.csproj b/EFCore.BulkExtensions/EFCore.BulkExtensions.csproj
index 5422d85..49d2d53 100644
--- a/EFCore.BulkExtensions/EFCore.BulkExtensions.csproj
+++ b/EFCore.BulkExtensions/EFCore.BulkExtensions.csproj
@@ -14,10 +14,12 @@
     <PackageReleaseNotes>Nugets updated; Fixes: TimeStamp column, Abstract base type, Contains query, BatchUpdate Sqlite</PackageReleaseNotes>
     <AssemblyVersion>3.1.1.0</AssemblyVersion>
     <FileVersion>3.1.1.0</FileVersion>
+    <SignAssembly>true</SignAssembly>
+    <AssemblyOriginatorKeyFile>EFCore.BulkExtensions.snk</AssemblyOriginatorKeyFile>
   </PropertyGroup>

   <ItemGroup>
-    <PackageReference Include="FastMember" Version="1.5.0" />
+    <PackageReference Include="FastMember.Signed" Version="1.5.0" />
     <PackageReference Include="Microsoft.Data.SqlClient" Version="1.1.1" />
     <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.3" />
     <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="3.1.3" />

[flensrocker]

I have this problem reversed. My project is NOT signed, nor ise EFCore.BulkExtensions. But God knows why, its referencing FastMember SIGNED, Please release a nuget package referencing UNSIGNED FastMember package too, thank you.

@SailorTurkey
Why is this a problem? What kind of error message do you get?

All Microsoft packages have a strong name and you can consume them in a project, which is not strong name signed.

@borisdj
For reference, why it is a good idea to strong name sign your assembly:
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

If you like I can create a pull request.

[borisdj]

5.0.6 is now Strong named.
What I got from sign assembly is that generated private key should be committed into repository, is that correct approach?
At strong-named it is stated : 'If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.'
Also SO-WhyIncludePK

[flensrocker]

Yes, just check in the generated snk without a password.
With this, forkers can build an own assembly with the same key, so they can drop it in as an replacement.

See my comment from June 23.

[borisdj]

Finished, thx for suggestion.

[flensrocker]

Thanks for this package! 👍

[flensrocker]

For those who need a signed assembly for an older version (in my case 2.4.1 because of EF Core 2.1), execute the following commands in an empty temp-directory (adjust):

nuget install -OutputDirectory . -Version 2.4.1 EFCore.BulkExtensions
ildasm EFCore.BulkExtensions.2.4.1\lib\netstandard2.0\EFCore.BulkExtensions.dll /out:EFCore.BulkExtensions.il
ilasm EFCore.BulkExtensions.il /resource=EFCore.BulkExtensions.res /dll /key=path\to\EFCore.BulkExtensions.snk

add the dll to your repository and then reference it in all projects where you need it:

  <ItemGroup>
    <Reference Include="EFCore.BulkExtensions">
      <HintPath>..\relative\path\to\EFCore.BulkExtensions.dll</HintPath>
    </Reference>
  </ItemGroup>