Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Puppeteer assembly doesn't have a strong name #1461

Closed
johnnyjob opened this issue Apr 16, 2020 · 8 comments
Closed

Puppeteer assembly doesn't have a strong name #1461

johnnyjob opened this issue Apr 16, 2020 · 8 comments

Comments

@johnnyjob
Copy link

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

@johnnyjob
Copy link
Author

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.

@kblok
Copy link
Member

kblok commented Apr 16, 2020

@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.

@kblok
Copy link
Member

kblok commented Apr 16, 2020

@johnnyjob I would accept a PR for that.

@madelson
Copy link
Contributor

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.

@kblok
Copy link
Member

kblok commented Apr 17, 2020

I wouldn't bump the version. Matching Puppupeteer version is rule number 1 (or 2).
We could ship a StrongName assembly for these scenarios.

@kblok
Copy link
Member

kblok commented Apr 20, 2020

What are your thoughts here @Meir017 ?

@Meir017
Copy link
Member

Meir017 commented Apr 20, 2020

I'm ok with making puppeteer-sharp use strong naming. as long as we check-in the strong-name key file

@sergiuciudin
Copy link

This is the reason why assembly binding to Microsoft.Extensions.Logging 3.1.4.0 doesn't work?

stesee added a commit to Codeuctivity/PuppeteerSharp.Renderer that referenced this issue Dec 15, 2020
Signing does not make sense until hardkoded/puppeteer-sharp#1461 isnt fixed
@kblok kblok closed this as completed Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants