[Feature] More intuitive setup and installation of Playwright

[Swimburger]

I'm a fan of PowerShell, but I think having to add Microsoft.Playwright.NUnit or a similar package, then build your project, then execute a PowerShell script that you can find in the bin/something...something/playwright.ps1 is not the ideal experience or the experience .NET developers expect. It works great tho!

I was hoping the Playwright setup experience could be more in line with what we expect as .NET developers.
I'm not an expert on MSBuild and still new to Playwright, so call me out if I'm off base!

When installing any Playwright NuGet package, I'd expect the installation to modify the MSBuild project file, and the MSBuild project file would setup all of Playwright the first time.
I'm not sure if Playwright updates its dependencies automatically over time, but if it did, I'd expect that to be checked for and updated during build. This could also be a standalone MSBuild target.

Alternatively, I think Playwright may also be a good fit for a global tool, or a local tool like the ef core tool.
Then inside the project, you may be able to run dotnet playwright init or dotnet playwright update.

Based on the NuGet package and MSBuild target described above, I'd expect there to be additional .NET templates for NUnit, MsTest, and xUnit. These templates would be the most intuitive ways to get started with Playwright and also to be reused for .NET IDEs like Visual Studio, VS Code, and Rider.

[mxschmitt]

Sounds related to #2213 which includes templates for vs, vsc and dotnet new.

[Swimburger]

There's definitely some overlap there! 👍

However, I think it makes sense to improve the installation mechanism without using templates as well, in case you're starting from a console app and do not plan to use a testing library.
This would make it more intuitive to add Playwright to other testing libraries outside of the big three (xUnit, NUnit, MsTest)

[timheuer]

In a $100 survey for Playwright for .NET I'd use $70 of my budget for this. The process today doesn't appear to put me on the path of success...

This process is just not how .NET developers expect things to work. To "build" a project to get a tool to be able to install things that are now really global (not project-specific) is a super odd flow. We need the post-install-nuget dependency to do more work, or to @Swimburger's point to have a combination of steps (global tool) to do the thing. The nuget package for the Test project shouldn't be the delivery for global tools IMO.

[pavelfeldman]

I'd need to pass on your $70 for the sake of our users. The reality is that we've arrived at where we are based on experience and the feedback from the field. We were installing on build, we used to have the dotnet tool, etc. We had to walk away from those because they were creating more problems than they were solving. Yes, we are different from a typical .NET application, but our use-cases are also different. Once you start deploying the tests to CI, use Playwright Containers with pre-installed browsers and dependencies, manage system dependencies installation on Linux, manage Playwright and Playwright Browsers updates in production, you'll see why the things are the way they are.

Templates and NUnit / MSTest integration are a different story, we are working on improving those!

[Swimburger]

What about the dependency on PowerShell? Could that be avoided?
The PowerShell file loads the Playwright DLL and invokes the Program.Main method:

#!/usr/bin/env pwsh

$PlaywrightFileName = Join-Path $PSScriptRoot "Microsoft.Playwright.dll"
[Reflection.Assembly]::LoadFile($PlaywrightFileName) | Out-Null
exit [Microsoft.Playwright.Program]::Main($args)

Would it make sense to run the DLL instead of the PowerShell script?
I'd expect dotnet Microsoft.Playwright.dll to do the same as the PowerShell script, but it does error.

[timheuer]

Yes, we are different from a typical .NET application, but our use-cases are also different. Once you start deploying the tests to CI, use Playwright Containers with pre-installed browsers and dependencies, manage system dependencies installation on Linux, manage Playwright and Playwright Browsers updates in production, you'll see why the things are the way they are.

I don't think the use case is much different from a bunch of other things in the ecosystem...you have some pre-reqs that must be satisfied for Playwright to work. Burying the acquisition of those in a dotnet build in order just to get the expansion of the nuget package into a random bin directory to then install those pre-reqs. It's the anti-pattern of NuGet and .NET and we should work together on either improving the NuGet post-experience (sadly we used to have this), or other means.

I would love to understand why this pattern solves things better for CI -- and would expect pre-installed containers to not need this at all? That part confused me why this makes it any better as the docs indicate the process is the same.

[pavelfeldman]

Would it make sense to run the DLL instead of the PowerShell script?

You can do that today if you'd like to install browsers programmatically.

I would love to understand why this pattern solves things better for CI -- and would expect pre-installed containers to not need this at all? That part confused me why this makes it any better as the docs indicate the process is the same.

I feel like we have a rather high-level, even a theoretical debate over a cosmetic detail. Could you share more on your test project configuration, how you run it and why you don't want to see a utility for manually fetching the required browsers. Playwright customers are often interested in better means of running tests in parallel, reusing authenticated state, running browsers in diverse containers and settings. They don't really focus on ability to install with 3 commands vs 2 commands. In order for us to prioritize this request, we need to better understand where it is coming from.

[pavelfeldman]

you have some pre-reqs that must be satisfied for Playwright to work

These pre-requisites are up to the user. The manual post-installation step is required to fetch the browser binaries matching the OS and process architecture. The set of the browsers is up to the user, not Playwright. I don't think NuGet can solve any of that.

-- adding

Even if NuGet allows downloading OS-specific binaries like pypi at some point (which as I understand is against the portability considerations), we won't want to create dozens of packages representing these browser binaries. That's simply too much of the maintenance overhead for us. And we won't want users to replicate them over and over for their local projects. That's >1G per the browser set, imagine you have 30 projects on your system - it adds up.

[timheuer]

why you don't want to see a utility for manually fetching the required browsers.

Oh I didn't mean that...to the contrary, I think that is valid utility -- I'm only focused on the UX. Relying on a \bin output for a utility of such is not a pattern we have in .NET...that's why we have global/local tools.

The manual post-installation step is required to fetch the browser binaries matching the OS and process architecture

Right, a global/local tool achieves this same and is more of the pattern for a .NET customer. I meant NuGet used to have a method of post-NuGet install being able to run commands...it no longer does.

And we won't want users to replicate them over and over for their local projects. That's >1G per the browser set, imagine you have 30 projects on your system - it adds up.

Totally agree...the pattern right now. The .NET SDK team has heard this feedback of multiple installs of our bits as well :-). It definitely adds up. In situations where there is multi-targeting, the current step also duplicates everything in \bin for each target (not talking about browsers)...so a single project multi-targeted for different version of .NET has multiple .playwright folders duplicating unnecessarily the contents (a secondary target duplicates my disk output now to 134MB).

I sent you a mail internally to better understand a bit 'offline' than here to know where .NET may be failing the workflow you've tried before. I don't debate the need for the CLI commands, the benefit, the constraints you note about browser acquisition, etc. I just think those can all be accomplished with a better UX for .NET developers.

[Swimburger]

You can do that today if you'd like to install browsers programmatically.

I see you can do this via the .NET API, but that's not what I mean.
If the PowerShell script is invoking the Program.Main method from the Microsoft.Playwright.dll, wouldn't you be able to do dotnet exec Microsoft.Playwright.dll or dotnet Microsoft.Playwright.dll. Or if you converted it into an executable binary, you could directly invoke Microsoft.Playwright?
(This doesn't work for some reason even though the PowerShell script and dotnet exec should do the same thing I think)

While there's only 3 lines to install Playwright, you do have to install PowerShell on your machine before running the third line, assuming it's not already on the machine. There's probably a good reason for involving PowerShell that I'm not aware off, but if there isn't, then not using PowerShell would be an improvement to the UX, as you'd not need to install it and keep it patched.

[pavelfeldman]

Let's keep it open to collect upvotes!

[AngelMunoz]

I just found this myself as well last time I tried it I was using the CLI tool which was bizarre for me as well. A global CLI tool that requires a project build to work... that's now that I would expect, specially when the node.js experience is quite smooth (npx playwright install like a .NET global tool)

I expected the global CLI tool to at minimum (and sometimes even at most) to just install the browsers
because my builds and F# scripts failed just because playwright browsers were not installed nothing else, once I ran npx playwright install things just worked and I could live with that

Now I come back and find that I need to run powershell scripts? which are generated after build?

That's simply too bizarre for me to be honest I'd prefer to have a global CLI tool that's just a wrapper over npx playwright install if that would let me do the following

dotnet tool restore
dotnet playwright install
dotnet build # or test

I don't think this is a cosmetic issue, while I know every project is different I find it hard to justify that I need to modify my .NET workflow just because a library seems to have weird requirements

Now I'm not sure how my wording is for this feedback but I certainly have no intention to annoy anyone it is just my raw experience with this tool from a few minutes ago after a couple of months away from it. The install experience hasn't been there from the get go, once we're past that things just work very nicely and smooth, it is a very sweet library to work with

Extra: It would be nice to pin this issue to make it more visible

[304NotModified]

Agree with this. I tried raising the same issue with #2239, but I guess it wasn't clear.

IMO this is far more important than all the new features (asserts etc) and 2nd is the large nodejs (#1850)

[IanChamberlain-SMS]

For Visual Studio the user experience should be:

1. Create a test project (Nunit/xUnit/MSTest whatever)
2. Add Nuget dependency for Playwright
3. Write Test Code
4. Run Tests

This experience currently fails because browsers aren't installed.
By default it should check to see if the browser specified has been installed and if not install it or alternatively use the Users Default Browser if it is supported.

[egtalbot]

I'm going to add my support for this issue. I got version 1.28 working a couple months ago with VS 2022 and XUnit - I don't remember exactly how but it involved a few hoops. I know I did NOT have to run a powershell script because my company disables running powershell scripts locally.

I accidentally upgraded to 1.29 today and now my tests don't work. I got the chrome browser versioning issue first and couldn't get, so I uninstalled from nuget and reinstalled 1.28. But that actually made things worse because the npx install command doesn't work any more (does nothing) and now the test is failing on PlayWright.CreateAsync() instead of LaunchAsync.()

I mean, I get that people used to running powershell for installs and using npx may find this intuitive, but that is not the vast majority of the Microsoft developer base. At this point there seems to be no path forward for me to actually get this working again, as nearly all the help around the net is not for use with C#.

It should be a nuget install and uninstall like thousands of other similar packages. I can't believe I'm saying this but Selenium is easier to get up and running with dotnet. I am kind of shocked Microsoft recommended this tool at thier conference a couple months ago, especially given that it doesn't fully play nicely with their default test framework of XUnit

[304NotModified]

@egtalbot maybe the work arround in #2239 helps in upgrading Playwright - no PowerShell or JavaScript need.

[egtalbot]

@egtalbot maybe the work arround in #2239 helps in upgrading Playwright - no PowerShell or JavaScript need.

This worked! Thanks so much for the link

[Billybishop]

This is still very much an issue in my opinion; following the #2293 suggestions, as well as some others, the process remains very unintuitive and can be easily disjointed in comparison to the docs. For instance, if the user has ran Playwright install before and already has a browser version installed on their machine, Playwright will default to using the currently installed Browser instead of the version that it downloaded and installed to ms-playwright appdata. Can we please get this rectified sometime soon? Being able to setup and run Playwright.NET in a reliable way is pretty pertinent from my point of view. If someone has a stable workaround to force Playwright to use the browsers that it downloads via install, then please share it here, otherwise I currently see NO way to do that.

[eric-vanartsdalen]

Hi Group...
This came up in conversation on one of cSharpFritz channel conversations where he was expecting a dotnet tool of some sort to help... so commands might look like those from the comment above...

I am playing around with an idea of creating a tool and following this Tutorial: Create a .NET tool using the .NET CLI ...
So far I have a program that basically finds a local version of the Microsoft.Playwright.dll and executes it as a process as a wrapped caller like the powershell script does with the args supplied and posts back the output asynchronously.
If you attempt to use it from a high level directory where you might have multiple dlls, it'll tell you to navigate deeper to a subdirectory and lists the locations so you can choose the appropriate dll for commanding...
If no dll is found, it'll tell you that too and suggest you dotnet restore/build to get the dependency dll down.

My main question would be is how and where the code can best be provided. This is my first work towards a potential contribution. Any guidance is welcome.
Any thoughts or pointers?

[lonix1]

Another reason: the current approach is extremely complicated (and downright weird) when used in a docker container, and especially in a CI environment.

One needs to restore and build in order to get the .playwright/ and .playwright.ps1 assets, but that makes a build pipeline incredible complex and hard to cache. So we resorted to building a "fake" project, just to force creation of the playwright assets, then build the base image, and then layer our app into that, and build/publish again. A royal mess, and almost impossible to cache, so our docker images are over 2GiB each, and take upward of 10 minutes to build.

Interestingly, the team came to the same conclusion, as the official (but outdated) image does the same thing.

[damianh]

Commenting to add my displeasure with this approach. This mechanism of distribution of an installation routine is funky as hell. Like @lonix1 above, I too have this nasty "fake project" hack in the docker file:

# install Microsoft.Playwright dependencies.
# The installation process for this is a bag of wtf https://github.com/microsoft/playwright-dotnet/issues/2286
# This is adapted from https://github.com/microsoft/playwright-dotnet/blob/main/utils/docker/Dockerfile.jammy#L29
RUN mkdir /ms-playwright && mkdir /ms-playwright-agent
COPY playwright.csproj ./ms-playwright-agent/playwright.csproj
RUN cd /ms-playwright-agent && dotnet build
RUN ./ms-playwright-agent/bin/Debug/net8.0/playwright.ps1 install --with-deps
RUN rm -rf /tmp/*
RUN dotnet nuget locals all --clear && rm -rf /root/.nuget && \
    rm -rf /ms-playwright-agent && \
    chmod -R 777 /ms-playwright

If not using docker and just using GitHub actions, the expected process would be install dependencies -> build and not install dependencies -> build -> install more dependencies

What I would conceptually prefer to have, in either docker file or a GitHub actions job step:

dotnet playwright install --with-deps

[damianh]

Another 6 months has passed. What's the situation with this, seriously?