Assembly signing

[yusukemasuda]

Hi.

I faced a build error that complains the Esent.Collections does not have strong name.
I think that the most packages distributed on nuget.org have strong name.
Do you have any reason that you don't sign your assemblies?

If you don't have any critical reason, could you sign the packages which you distribute after next version?

Or else, could you let me know how avoid this build error?

[stewienj]

We wanted to migrate our codebase to .NET Core, this requires changing the ManagedEsent package

from https://www.nuget.org/packages/ManagedEsent/
to https://www.nuget.org/packages/Microsoft.Database.ManagedEsent/

Unfortunately the latter isn't signed. So this one package is currently blocking us migrating to .NET Core. All the other packages we use are signed.

Is there any plan to sign the published nuget package, if so could you say when? It would be good to know so we can put a date on our roadmap for .NET Core support.

[stewienj]

On closer inspection it looks like the new ManagedEsent DLL is signed, however it doesn't have a strong name, so I get this:
Warning CS8002 Referenced assembly 'Esent.Interop, Version=1.9.4.1, Culture=neutral, PublicKeyToken=null' does not have a strong name.

This illustrates the problem:

E:\packages\managedesent\1.9.4\lib\net40>sn -T Esent.Interop.dll

Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0
Public key token is 31bf3856ad364e35

E:\packages\microsoft.database.managedesent\2.0.1\lib\netstandard2.0>sn -T Esent.Interop.dll

Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0
Esent.Interop.dll does not represent a strongly named assembly

And here's what I get when I run my app:

System.IO.FileLoadException: 'Could not load file or assembly 'Esent.Interop, Version=1.9.4.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)'

[stewienj]

The issue could be as simple as a missing snk file, the EsentInterop.csproj has the following:

    <SignAssembly>true</SignAssembly>
    <PublicKeyFile>..\scripts\internal\35MSSharedLib1024.snk</PublicKeyFile>
  </PropertyGroup>

  <!-- The .snk file won't be published to codeplex. -->
  <PropertyGroup Condition="Exists('$(PublicKeyFile)')">
    <DefineConstants>$(DefineConstants);STRONG_NAMED</DefineConstants>
    <DelaySign>true</DelaySign>
    <AssemblyOriginatorKeyFile>$(PublicKeyFile)</AssemblyOriginatorKeyFile>
  </PropertyGroup>

[yusukemasuda]

@stewienj
Thank you for your comment.
I also check the csproj file, with accross its vesions.
The 'PublicKeyFile' element existed since pretty old version.
So I guess this had worked with same csproj at that time.

As you showed, signing seems to skip if the key file does not exist by the condition on the property group.
I suppose that this is a probrem in build process.
I think that we need someone who knows how this is built.

---

Unfortunately, if no one in the project team see this issues, we have to move to another database when we need strong name for libraries.

[michaelthorp]

Sorry it took so long, the notifications had stopped sending me alerts about new issues. I will look into the build issue and publish a new package.

[michaelthorp]

I just pushed version 2.0.2 which should have the SN-signing issue resolved. There is no other update as I wanted to make sure this got addressed. Please let me know if there are any issues with this version.

[stewienj]

Esent.Interop.dll from nuget works fine on Windows 10 Enterprise, but gets a "Strong name validation failed" exception on Windows Server 2019 Standard.

If I go to the VS2019 x64 command prompt and do: sn -v Esent.Interop.dll
Windows 10 Enterprise gives: Assembly 'Esent.Interop.dll' is valid
Windows Server 2019 Standard gives: 'Esent.Interop.dll' is a delay signed or test-signed assembly

[michaelthorp]

Thanks for letting me know. I've identified the issue in the build/signing infrastructure and am working on getting it fixed. I'll post here once it's updated.

[Obalix]

Just checked on Windows 10 Enterprise (Version 2004 Build 19041.450) and Windows 10 Pro (Version 20H2 Build 19042.1110). Both versions reported the exception mentioned above when executing "sn -v Esent.Interop.dll".

So the exception might not be only with Windows Server 2019.

[michaelthorp]

No, it's across the board. I am working on a fix now; had to wait for some new permissions but they just came through. I'll publish version 2.0.3 shortly.

[michaelthorp]

Ok, try 2.0.3. It should now be using strong-name signing.

[MisterMiksu]

In v2.0.4 there is the same signing issue again. It works with 2.0.3 though.

[michaelthorp]

I'll take a look at what changed in the signing process.

[AlexGilliland]

@michaelthorp - were you able to take a look at the signing process?

[a-v-ebrahimi]

As a temporary solution try this:
sn.exe -Vr Esent.Interop.dll