You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please produce strong-name signed assemblies as it makes the assemblies impossible to reference without modification by a project where strong-naming is enabled.
Selenium itself has a separate strong-named package (http://selenium-release.storage.googleapis.com/3.141/selenium-dotnet-strongnamed-3.141.0.zip). The better solution is to strong-name the assemblies and ship it in the existing package, because two packages that contain exactly the same assemblies, types, etc, could cause issues if they are in the same dependency graph.
Example of the current issue as seen in ILSpy: Microsoft.Edge.SeleniumTools, Version=3.141.1.0, Culture=neutral, PublicKeyToken=null
The text was updated successfully, but these errors were encountered:
Hi @inthemedium. We can make a separate Microsoft.Edge.SeleniumTools.StrongNamed package available for use with the official Selenium strong-named package. Our existing package depends on the official Selenium.WebDriver NuGet package which is not strong-named.
Please produce strong-name signed assemblies as it makes the assemblies impossible to reference without modification by a project where strong-naming is enabled.
Selenium itself has a separate strong-named package (http://selenium-release.storage.googleapis.com/3.141/selenium-dotnet-strongnamed-3.141.0.zip). The better solution is to strong-name the assemblies and ship it in the existing package, because two packages that contain exactly the same assemblies, types, etc, could cause issues if they are in the same dependency graph.
Example of the current issue as seen in ILSpy:
Microsoft.Edge.SeleniumTools, Version=3.141.1.0, Culture=neutral, PublicKeyToken=null
The text was updated successfully, but these errors were encountered: