Skip to content

[🚀 Feature]: do not copy unneccesary selenium-manager binaries via Selenium.WebDriver NuGet #15768

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

Open
LukasGelke opened this issue May 21, 2025 · 3 comments
Labels
A-needs-triaging A Selenium member will evaluate this soon! B-manager Selenium Manager C-dotnet .NET Bindings I-enhancement Something could be better

Comments

@LukasGelke
Copy link

LukasGelke commented May 21, 2025

Description

build\Selenium.WebDriver.targets just includes all selemium-manager binaries in the build regardless of (target) OS. It would be nice, if one could somehow control which ones are copied.
Our tests (currently) only run on windows, so the linux and macos binaries are never used and are just "bloat". Some Applications/Tests may have the <RuntimeIdentifier> or similar MsBuild-Properties set. However I guess it is not always present, if the package is included in e.g a "plain net8.0" project
So a dedicated property (that can be set in .csproj or Directory.Build.props)? (Empty=Default="copy all" to be non-breaking)

Have you considered any alternatives or workarounds?

manually delete unneeded binaries after dotnet publish

@LukasGelke LukasGelke added I-enhancement Something could be better A-needs-triaging A Selenium member will evaluate this soon! labels May 21, 2025
@selenium-ci
Copy link
Member

@LukasGelke, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

@github-actions github-actions bot added B-manager Selenium Manager C-dotnet .NET Bindings labels May 21, 2025
@nvborisenko
Copy link
Member

It will be resolved implicitly by #15355

@nvborisenko
Copy link
Member

Seems that issue is on long shelf. But we can do something to be step closer.

Here I propose to start resolving this particular issue. We can consider selenium-manager.exe as "native library" and pack it appropriately. Meaning that nuget will deal with it as with native library. Then at runtime we will find the path to selenium-manager.exe.

Before re-packing nuget package, I ask help to test it in different environments like console app, test app, asp.net, anything else? Who is ready? Special case is the project who has packages.json file (I even don't know how to create new project in old style).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-needs-triaging A Selenium member will evaluate this soon! B-manager Selenium Manager C-dotnet .NET Bindings I-enhancement Something could be better
Projects
None yet
Development

No branches or pull requests

3 participants