bugsnag/bugsnag-dotnet

sign Bugsnag.dll

galich opened this issue · 5 comments

galich commented

Expected behavior

NuGet installed packages to provide signed assemblies.

Observed behavior

app crash when adding NuGet package to a signed app

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

Steps to reproduce

  1. Create signed .NET app (WPF, console, WinForms - doesn't matter)
  2. add nuget package Bugsnag
  3. build and run

Version

1.4.0.0

PandaWood commented

Use the StrongNamer Project

Most applications in .NET do not need to be strong named. Strong names can also introduce pain because they end up requiring binding redirects. Because of this, many OSS libraries do not strong name their assemblies.
...
Simply install the StrongNamer NuGet package, and it will transparently and automatically sign the assemblies you reference as part of the build process

  • 👍1
clairernovotny commented

@PandaWood That guidance is no longer accurate. Please see the current guidance from the .NET Team:

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

kenmorse commented

Any update on this? Would be great to see something like a Bugsnag.signed in NuGet that was a strong-named signed version of the Bugsnag package.

mattdyoung commented

Hi @kenmorse

We're planning to take a look into this when priorities allow.

yousif-bugsnag commented

v3.0.0 of bugsnag-dotnet has now been released which adds strong-name signing to the Bugnsag.dll, Bugsnag.AspNet.dll, Bugsnag.AspNet.Mvc.dll and Bugsnag.AspNet.WebApi.dll assemblies.