puppeteer-sharp
puppeteer-sharp copied to clipboard
hardkoded
Puppeteer assembly doesn't have a strong name
Description
An attempt to use PuppeteerSharp.dll from a DLL which has a strong name causes the following error: System.IO.FileLoadException: Could not load file or assembly 'PuppeteerSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044) File name: 'PuppeteerSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
Expected behavior:
I would expect Puppeteer Nuget to work out of the box with any .Net project, signed or not.
Actual behavior:
Currently I have to download the source code and make my custom build of the Puppeteer. I cannot just use the Nuget package maintained by the Puppeteer developers.
Versions
Puppeteer Nuget 2.0.3
I can fix that if it's OK to keep the SNK file in the repository. It seems that falls into Microsoft recommendations: https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named
If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly to your source control system.
If it's not OK, only a person with appropriate rights in this GitHub project will be able to accomplish that task.
@johnnyjob I could take a look at that. My concern is not breaking existing users and, as you said, being able to build the assembly in our CI.
My understanding is that if we do add a strong name it will be considered a binary breaking change by .NET. So any library that built against 2.0 won't be compatible with the strong-named assembly.
It would be nice not to break with SemVer, so I'd suggest either going to 3.0 when we do this OR releasing a side-by-side PuppeteerSharp.StrongName package built from the same code that people who care about strong names can use until PuppeteerSharp decides to go to 3.0 for other reasons.
I wouldn't bump the version. Matching Puppupeteer version is rule number 1 (or 2). We could ship a StrongName assembly for these scenarios.
I'm ok with making puppeteer-sharp use strong naming. as long as we check-in the strong-name key file
This is the reason why assembly binding to Microsoft.Extensions.Logging 3.1.4.0 doesn't work?
