[🚀 Feature]: Publish `StrongNamed` builds to nuget feed

[harunurhan]

Feature and motivation

It would make it easier to consume if strong name signed versions of the packages, such as Selenium.WebDriver.StrongNamed were published to nuget.org feed, currently it's only possible to download from github.

Usage example

N/A

[github-actions]

@harunurhan, 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!

[nvborisenko]

I don't think we will publish it in nuget feed. More realistic scenario is making Selenium.WebDriver with strong name.

[Mek7]

OK, it would be very useful also for us. Any news on this?

[superbull]

Hi, when will the strong named version published in nuget feed?

[nvborisenko]

Only with Selenium 5 as a major breaking change, and if core team doesn't mind.

[Mek7]

Major breaking change?
Strongly naming a library doesn't influence existing consumers, only broadens its usability for environments where everything is strongly named (and thus, non-strongly named libraries cannot be referenced).
Am I missing something?

[tbremard]

Hello,
I can see that this ticket is open since 1 year (july 2023 when we are in june 2024.
I did not see it and created this ticket (which has been closed because of 'duplication'):
#14115

let me copy paste my last comment:

Strong-naming an assembly introduces a small initial overhead, as it requires generating a key pair and integrating the signing process into the build pipeline. However, once this key pair is generated, it can be reused for all subsequent releases, making the process transparent and straightforward for future updates.

For a widely used library like Selenium, providing strong-named assemblies in the NuGet package would enable developers to use these assemblies in environments that require strong-naming, such as in large enterprises with strict security policies. It allows these developers to maintain strong-naming across their entire application stack, ensuring compatibility and compliance with their security requirements.

Moreover, it is worth noting that most NuGet packages available today include a public key, which means they are already strong-named. This has become a standard practice, reflecting the industry's emphasis on security and integrity. By aligning with this standard, the Selenium library will not only enhance its security posture but also meet the expectations of its user base, facilitating smoother integration and wider adoption.

The benefits of strong-named assemblies in promoting security, integrity, and trustworthiness far outweigh the small initial overhead. Incorporating strong-named assemblies in the next minor release would significantly enhance the utility of the Selenium library, making it more suitable for a wider range of applications and increasing its adoption in secure and enterprise environments.
Furthermore, it is important to consider the principle of transitivity in strong-naming. A non-signed project can use both non-signed and signed assemblies without issue. However, if a project requires a strong-named assembly, it cannot use a non-signed assembly, as it will be refused to load at runtime. By adding strong-naming to the Selenium NuGet package, you significantly increase the potential user base, as both non-signed and signed projects will be able to integrate Selenium seamlessly. This inclusivity broadens the ecosystem of users who can rely on Selenium for their testing needs, enhancing the library's adoption and utility across various environments and security requirements.

Of course, while you currently provide signed assemblies in a zip file, however best practices in modern .NET development strongly recommend using NuGet package references rather than hard-copied DLL files. NuGet packages ensure better dependency management, automatic updates, and a more streamlined development process. Including strong-named assemblies directly in the NuGet package would align with these best practices, making it easier and more efficient for developers to integrate Selenium into their projects.
I invite you to look at your own dotnet dependencies, browse the method declarations and see at the top of each of your dependencies a public key token, like the ones that my own project is referencing which follow:

#region Assembly System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.8\System.Windows.Forms.dll
#endregion

#region Assembly System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.8\System.Xml.Linq.dll
#endregion

#region Assembly DevExpress.RichEdit.v13.1.Core, Version=13.1.8.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a

#region Assembly NLog, Version=5.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c

Find the exception....
#region Assembly WebDriver, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null
// C:\Work\GitlabRepos\TechTest.Taf\packages\Selenium.WebDriver.4.21.0\lib\netstandard2.0\WebDriver.dll
#endregion

I think in the back lines this is more an issue about knowledge of how strong name signing works rather than a technical blocker.

[nvborisenko]

I feel Selenium 5 will be signed with strong name. Technically we are ready to do it, I don't see any reasons why the assembly cannot be signed in, build process is adopted.

Why not now?.. Because it is breaking change at binary level, all users who consume the assembly transitively will be affected. Given that this assembly is still not signed yet for a long time, and the source code is opened for everybody, I can summarize - wait major update v5 or apply one of many workarounds available to you. Signing the assembly right now will damage the project more than hilling.

[tbremard]

Thank you I would be happy to learn about a scenario which would show an issue if you release tomorrow a strong named version. I would like to know which one with the parameters for my curiosity. Le mer. 12 juin 2024 à 16:37, Nikolay Borisenko ***@***.***> a écrit :

…

I feel Selenium 5 will be signed with strong name. Technically we are ready to do it, I don't see any reasons why the assembly cannot be signed in, build process is adopted. Why not now?.. Because it is breaking change at binary level, all users who consume the assembly transitively will be affected. Given that this assembly is still not signed yet for a long time, and the source code is opened for everybody, I can summarize - wait major update v5 or apply one of many workarounds available to you. Signing the assembly right now will damage the project more than hilling. — Reply to this email directly, view it on GitHub <#12315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIULZZD345MRUWMDXDRUDCLZHBMJ7AVCNFSM6AAAAAAZ7FAD2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGE4DGMBTHE> . You are receiving this because you commented.Message ID: ***@***.***>