Closed 12masta closed 3 years ago
hey @12masta, which .NET version are you using?
.NET Framework 4.7.2
@12masta could you try 0.191.1?
Sure, still the same issue. I am tried 0.191.1 and 0.191.12 :( @kblok
System.IO.FileLoadException : Could not load file or assembly 'PlaywrightSharp, Version=0.191.2.0, Culture=neutral, PublicKeyToken=db12f80f85d8ba23' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)
Some thoughts?
This worked for me https://github.com/kblok/PlaywrightSharp-NETFramerwork472-DemoApp what can I change there to reproduce your issue?
Thanks, I will try to share some code.
@kblok fwiw i'm getting the same error with puppeteer-sharp (3) on 4.7.2. landed here in googling for recent occurrences of this search term.
will report back if i find anything useful
@mrtristan I released ptpr# 4 a few days ago. Could you check that? If that works I will apply the same change here.
@kblok yep, ty.
i've got 3 projects. A, B, C.
A -> B -> C with A being 4.7.2 and the other two being netstandard2.0
The PS ref is in C. I bumped it to 4 in A after making that comment and things seemed to work. Going to bump it in C and let it trickle up, but my guess is that it'll work now.
Same error here.
I have a 4.8 Test project and a 4.8 MVC app that it references. I am on using PlayWrightSharp 0.192
Update: I tried launching with the installed edge browser and specified executablePath: @"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" and everything worked.
@12masta are you still seeing this problem? If so, do you have any bindingRedirect
s setup in the .config files by any chance?
using sn.exe against the current nuget seems to confirm something is wrong
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.0-pre.2.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
sn.exe -v C:\...\packages\microsoft.playwright\1.12.2\lib\netstandard2.0\Microsoft.Playwright.dll
Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.0
Copyright (c) Microsoft Corporation. All rights reserved.
Failed to verify assembly -- Strong name validation failed.
same occurs for the net5 version
so i suspect the problem is the assembly that has been shipped was built using <PublicSign>true</PublicSign>
https://github.com/microsoft/playwright-dotnet/blob/main/src/Common/SignAssembly.props#L6
@SimonCropp Indeed, we use PublicSign
. sn
will return an error, however, the relevant bit is set and the assembly is marked as signed, which you can verify:
> CorFlags.exe .\Microsoft.Playwright.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.8.3928.0
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 0x9
ILONLY : 1
32BITREQ : 0
32BITPREF : 0
Signed : 1
Technically, for OSS projects, this seems to be the way to go. However, the following is called out as a problem:
I wonder if any of the above might be the cause of the validation error @12masta was seeing though?
@SimonCropp Indeed, we use
PublicSign
.sn
will return an error, however, the relevant bit is set and the assembly is marked as signed, which you can verify:> CorFlags.exe .\Microsoft.Playwright.dll Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.8.3928.0 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 0x9 ILONLY : 1 32BITREQ : 0 32BITPREF : 0 Signed : 1
Technically, for OSS projects, this seems to be the way to go. However, the following is called out as a problem:
- You will not be able to install the assembly to the Global Assembly Cache (GAC)
- You will not be able to load the assembly in an AppDomain where shadow copying is turned on.
- You will not be able to load the assembly in a partially trusted AppDomain
I wonder if any of the above might be the cause of the validation error @12masta was seeing though?
@avodovnik I got this same error. Partial trust might be something to think about. By default no executables or scripts are allowed to run unless there is an exception in AppLocker or the program runs from the C drive. The location of my test console app is within an exception area, I don't know if playwright or its browser is trying to call out to other areas that are blocked. When I used the officially installed edge exe I did not get the error.
@Jojoshua are you saying you're running your app in a partially trusted AppDomain? Can you give me more details about that use case?
@Jojoshua are you saying you're running your app in a partially trusted AppDomain? Can you give me more details about that use case?
@avodovnik I am not sure what defines partial trust app domain but I can say that AppLocker policy may be in effect here where it is trusting my developer sandbox folder but not explicitly other executables/scripts that are spawned in other folders on the machine during program execution.
@Jojoshua so, it's possible that's the browsers - they would be installed, by default, under %AppData%\Local\ms-playwright
which might be blocked.
Are you seeing a specific problem/error with loading DLLs, or are you seeing an exception that might be related to browsers?
@Jojoshua so, it's possible that's the browsers - they would be installed, by default, under
%AppData%\Local\ms-playwright
which might be blocked.Are you seeing a specific problem/error with loading DLLs, or are you seeing an exception that might be related to browsers?
@avodovnik I saw the same strong name error unless I launch using the the official edge browser. Leads me to think something (maybe AppLocker) doesn't like the playwright browser location or the actual chromium exe. I tested this during version 0.92
@jojoshua I wonder if you can try setting the PLAYWRIGHT_BROWSERS_PATH
environmental variable, then running playwright install
once again. I would imagine the reason AppLocker is letting Edge through is because IIRC it's the only one where we don't have a custom build (cc: @aslushnikov can you confirm that's true?) and the exe would therefore be trusted. Anyway, since you have a way "around it", let's give this a go, and see?
@Jojoshua I wonder if you can try setting the
PLAYWRIGHT_BROWSERS_PATH
environmental variable, then runningplaywright install
once again. I would imagine the reason AppLocker is letting Edge through is because IIRC it's the only one where we don't have a custom build (cc: @aslushnikov can you confirm that's true?) and the exe would therefore be trusted. Anyway, since you have a way "around it", let's give this a go, and see?
@avodovnik Do you mean set PLAYWRIGHT_BROWSERS_PATH to a location that is exempt from AppLocker? Also, what exactly do you mean by running 'playwright install' once again...I did not manually invoke any script to install, this all automatically happened when I pulled in the package and tried to execute. Maybe the new version works differently? I would hope that in the .NET ecosystem that a .NET developer using playwright would not need to necessarily know how to configure or work with nodejs directly. For example, can I set PLAYWRIGHT_BROWSERS_PATH as part of my project appSetting?
Hello,
I am trying to attach playwright 0.180.0 into my existing project on .Net Framework and I am receiving following error when trying to execute some basic test:
Error message:
System.IO.FileLoadException : Could not load file or assembly 'PlaywrightSharp, Version=0.180.0.0, Culture=neutral, > > PublicKeyToken=db12f80f85d8ba23' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)
Sample code:
[Fact] public async Task Test1() { IPlaywright playwright = await Playwright.CreateAsync(); PlaywrightSharp.Chromium.IChromiumBrowser browser = await playwright.Chromium.LaunchAsync(); var page = await browser.NewPageAsync(); await page.GoToAsync("http://www.bing.com"); await page.ScreenshotAsync(path: ""); }
It will be cool to give it a try. ;)
you can disable strong name validation till the time the issue is resolved.
Disabling strong name validation is definitely not something we'd recommend.
After investigation of this, we've switched over to fully signed assemblies (see #1570). This should fix the assembly loading problems, when using Playwright in fully trusted scenarios.
@avodovnik Do you mean set PLAYWRIGHT_BROWSERS_PATH to a location that is exempt from AppLocker?
Yes, @jojoshua, that's what I mean. The browsers themselves are obviously still executables, and therefore might be subject to checks by AppLocker.
Also, what exactly do you mean by running 'playwright install' once again...I did not manually invoke any script to install, this all automatically happened when I pulled in the package and tried to execute. Maybe the new version works differently? I would hope that in the .NET ecosystem that a .NET developer using playwright would not need to necessarily know how to configure or work with nodejs directly. For example, can I set PLAYWRIGHT_BROWSERS_PATH as part of my project appSetting?
That's a really good suggestion (using appSettings
) and we'll look into adding that. As for running playwright install
, this is something that has to be done when updating versions, and it should be (for now), done manually. Let us know if the docs aren't clear enough for this and we'll update them.
Closing this issue for now, as the original problem is fixed. Feel free to open new issues, if you encounter them.
Hello,
I am trying to attach playwright 0.180.0 into my existing project on .Net Framework and I am receiving following error when trying to execute some basic test:
Error message:
System.IO.FileLoadException : Could not load file or assembly 'PlaywrightSharp, Version=0.180.0.0, Culture=neutral, > > PublicKeyToken=db12f80f85d8ba23' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)
Sample code:
It will be cool to give it a try. ;)