[🚀 Feature]: Revisiting strong-named assemblies for NuGet (.NET Core/.NET)

[craigfowler]

Feature and motivation

I'm aware that the current policy at Selenium is to distribute non-strong-named assemblies via NuGet and to make strong-named assemblies available only via a download site which is not a NuGet feed. This is OK unless a developer wishes to create a package which:

• Is to be distributed exclusively via NuGet
• Depends upon Selenium
• Is to be strong-named

Such a package cannot depend upon the Selenium NuGet packages because they are not strong-named, and a NuGet package cannot sensibly depend upon "an out-of-band download site". I am aware that this issue/question has come up a few times over the past few years and I recall asking about it myself previously (possibly on IRC but it would have been at least 4 years ago).

What I'd like to do is prompt a revisit of the policy of "No strong-named assemblies on NuGet", given the current status of NuGet and .NET. What problems need to be resolved to prompt a reversal of that policy? Lots (perhaps the majority) of packages are released on NuGet with strong-named assemblies so it must be possible.

I seem to recall that at least part of the problem with strong-naming related to assembly binding redirects in App.config files. If that's the main pain-point then I have good news: In .NET Core and .NET5+ App.config files and binding redirects are a thing of the past! The assembly binding/versioning rules are now much more sane. This is going to mean that the audience who could be affected by issues is only going to decline as more projects upgrade to .NET Core or .NET5+.

But still - I suppose this feature request begins with a question: What problems would need to be resolved in order to reverse the policy of having no strong-named binaries distributed via NuGet? The next step is me taking a look to see if I can solve those problems.

Current workarounds

A package which has to depend upon Selenium and is to be distributed via NuGet would have to either:

• Forgo strong-naming
• Bundle a copy of the Selenium strong-named binaries

For that second workaround, as far as I can tell the software license doesn't prevent this, but it's a bad solution because then the Selenium Version is tied to the package version. Developers could not upgrade Selenium (even point releases) without upgrading the dependent package. So, that's not a great solution either.

Usage example

I'm about to begin a revisit of a package of my own. I would like to distribute this via NuGet, it will require a dependency upon Screenplay and I would like to strong-name it.

[github-actions[bot]]

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

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[craigfowler]

I get a feeling that @jimevans might have some of the most insightful things to contribute on this one.

[titusfortner]

In .NET Core and .NET5+ App.config files and binding redirects are a thing of the past!

Yes, but so long as Selenium supports .NET Framework, it will continue to be an issue, right? I believe we're making the decision based on ensuring a minimum standard, not on what percent of users would benefit. I'm not Jim, but to the extent I understand this (admittedly not well), the calculus is unlikely to change.

[craigfowler]

so long as Selenium supports .NET Framework, it will continue to be an issue, right?

To a degree, but I think there are solutions to this as well, for the .NET Framework folks.

• Developers using the (now somewhat dated) packages.config mechanism of package dependencies will have binding redirects created automatically for them
• It's possible to specify XDT (config transformation files) inside of NuGet packages, which are applied when the package is installed. Binding redirects can be included in these, so upon package installation or upgrade, the binding redirects are taken-care-of for the developer. The creation of those XDTs can be integrated into the build/packaging process.

But - I wonder if it's more than just this, which is why I'm looking for a better understanding of the reasons. I'm hoping that I can solve them all and get the Selenium packages to play a little more nicely with the rest of the NuGet ecosystem. If I can't then so be it. I'll continue shipping a non-strongnamed package.

[titusfortner]

Can you join us in Slack to discuss? https://www.selenium.dev/support/#ChatRoom

[github-actions[bot]]

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 14 days with no activity.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.