-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[🐛 Bug]: OneTimeSetUp: System.IO.FileLoadException : Could not load file or assembly 'System.Text.Json, Version=8.0.0.0 #14600
Comments
@Guitrum, thank you for creating this issue. We will troubleshoot it as soon as we can. Info for maintainersTriage this issue by using labels.
If information is missing, add a helpful comment and then
If the issue is a question, add the
If the issue is valid but there is no time to troubleshoot it, consider adding the
If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C),
add the applicable
After troubleshooting the issue, please add the Thank you! |
Have you tried updating System.Text.Json to 8.0.4 using your package manager? |
@Guitrum we really need simple reproducible project where we can face this issue. Why? It works fine on my environment. The only one difference between 4.23 and 4.24 is that the latest one uses |
Hi, @Guitrum. Either a complete code snippet and URL/HTML (if more than one file is needed, provide a GitHub repo and instructions to run the code), the specific versions used, or a more detailed description to help us understand the issue. Note: If you cannot share your code and URL/HTML, any complete code snippet and URL/HTML that reproduces the issue is good enough. Reply to this issue when all information is provided, thank you. |
Got the same issue when using Selenium in Windows PowerShell 5.1. It gives the following error: Tried versions 8.0.0, 8.0.4 and 8.0.5. Version 8.0.4 gives a slightly different error:
To invoke the web driver I'm executing the following code:
Versions used: |
@Guitrum @mvaneijken If somebody can rephrase steps to reproduce for me (as for dummy), I appreciate it. |
I have run into a very similar error as originally reported, but, at least in my exact case, this does not appear to be directly related to the Selenium assembly or packaging. In my case, taking on I have distilled down a reproducible example, which I'll discuss in "Issue 2", below. The key point here is most likely that we're targeting I have created what should be a pretty straightforward (and hopefully consistent) repro case and pushed it to a repository - Details of my machine -
I have a few data points to share and expand on and will try to break them up as best I can 👍 Issue 1 - failure due to System.Text.Json - MSTest DeploymentFirst, the outright failure stemming from my [very specific!] MSTest scenario. This is a secondary presentation and in my opinion, is 100% unrelated to the issue in question, nor is it any sort of root cause. It's simply a presentation of an error that is an unfortunate red-herring. I do want to share it for completeness and in case it helps others start an investigation of their own. The stack trace:
I could clearly see that the [presumably correct]
📣 For anyone finding this and attempting to debug through it, the best thing to do is probably going to be to enable fusion logging to better understand what exactly is being probed/discovered and what the underlying mismatch might be.
Issue 2 - Visual Studio Test Explorer failure due to System.Runtime.CompilerServices.UnsafeIn an effort to create a repro case, "out of the box" in a new project, I failed. Visual Studio appears to do what's right and it all works. I tried both
This error is suppressed (at least for me) when creating a fresh It is interesting, though, that if we are observing this in the fusion log, we can also see that there's a assembly load error reported for While the error surfacing in the runner is related to System.Runtime.CompilerServices.Unsafe
System.Text.Json
To make the test work, we can add in the assembly binding redirect for just <runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime> Issue 3 - VSTest.Console failure due to System.Text.JsonAn interesting behavior emerged when I was authoring some Cake scripts to help your team reproduce these - I was able to accurately reproduce the behavior seen in NUnit (below, Issue 4) from the console in VSTest. It turns out that in Issue 2, as I had alluded to, we need to place the redirect for
Adding both redirects resolves this error: <runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.4" newVersion="8.0.0.4" />
</dependentAssembly>
</assemblyBinding>
</runtime> Issue 4 - NUnit failure due to System.Text.JsonGiven what I learned in the second issue, I was able to reproduce (I am pretty sure) the exact case that @Guitrum reported.
This one, unlike the previous issue, required an assembly binding redirect for both assemblies in order to work, but once in place, the test does work without issue. <runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.4" newVersion="8.0.0.4" />
</dependentAssembly>
</assemblyBinding>
</runtime> Hope this helps, if there is anything I can help to clarify, please tag me. |
To sum-up: this is how assembly resolving is working in .net framework, and selenium is not an exception. As a developer, you should become familiar with it, especially with https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions. If you use .net core, you will never face this issue. @kcamp do you have any specific issue I may help to you? |
@nvborisenko No, there is nothing I need assistance with. I wanted to provide the repro scenario and share the investigation I did. Thank you for checking 👍 I do think I better understand why this is happening, though. I've set up a simple project build using the same TL;DR - There's an assembly version mismatch between target frameworks in the -- Examining the binary logger output, we can see that the If we browse the actual This is reflected [correctly] in the However, when we're building a project targeting .NET 4.8, we're resolving the file at Given all this, I am pretty sure that any suggestion or attempt to take on a top-level reference to I believe this difference between assembly versions in So this really comes down to the auto-generation of the assembly binding redirects for the .NET Framework class libraries. <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<RootNamespace>selenium_system_text_json_repro_nunit</RootNamespace>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<LangVersion>10.0</LangVersion>
<IsPackable>false</IsPackable>
<OutputType>Library</OutputType>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NUnit" Version="4.2.2" />
<PackageReference Include="NUnit3TestAdapter" Version="4.6.0" />
<PackageReference Include="Selenium.Support" Version="4.26.1" />
<PackageReference Include="Selenium.WebDriver" Version="4.26.1" />
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="131.0.6778.8500" />
</ItemGroup>
<!--
This forces the generation of assembly binding redirects
for class libraries - see https://github.com/dotnet/msbuild/issues/1310
-->
<Target Name="ForceGenerationOfBindingRedirects"
AfterTargets="ResolveAssemblyReferences"
BeforeTargets="GenerateBindingRedirects"
Condition="'$(AutoGenerateBindingRedirects)' == 'true'">
<PropertyGroup>
<!-- Needs to be set in a target because it has to be set after the initial evaluation in the common targets -->
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
</Target>
</Project>
Hope this helps explain things for anyone else coming across this issue. Fingers crossed we all continue to solve our tech debt and get off the full Framework! 🤞 |
Only one question:
why 8.0.0.4? It should be 8.0.0.0 (I know .net framework 4.6.2 is bad in terms of compatibility with netstadarad2.0, seems you use .net 4.8) |
Figured it out, this is really strong name version of |
Yeah, you figured it out and beat me by a couple of minutes. I'll still share the details (plus another workaround) - -- It's The When we're targeting .NET 4.8 (I would surmise any full framework), we're resolving If I take the comment from issue I linked above and incorporate it in my repro case, it suppresses the assembly binding redirect entirely and the test works correctly in NUnit. <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<RootNamespace>selenium_system_text_json_repro_nunit</RootNamespace>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<LangVersion>10.0</LangVersion>
<IsPackable>false</IsPackable>
<OutputType>Library</OutputType>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NUnit" Version="4.2.2" />
<PackageReference Include="NUnit3TestAdapter" Version="4.6.0" />
<PackageReference Include="Selenium.Support" Version="4.26.1" />
<PackageReference Include="Selenium.WebDriver" Version="4.26.1" />
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="131.0.6778.8500" />
<PackageReference Include="System.Text.Json" Version="8.0.4" GeneratePathProperty="true" ExcludeAssets="Compile;Runtime;Build" />
</ItemGroup>
<ItemGroup>
<!--
Force our reference to the netstandard2.0 8.0.0.0 version of the assembly
and avoid the need for an assembly binding redirect for System.Text.Json
-->
<Reference Include="System.Text.Json">
<HintPath>$(PkgSystem_Text_Json)\lib\netstandard2.0\System.Text.Json.dll</HintPath>
</Reference>
</ItemGroup>
<!--
This forces the generation of assembly binding redirects
for class libraries - see https://github.com/dotnet/msbuild/issues/1310
-->
<Target Name="ForceGenerationOfBindingRedirects"
AfterTargets="ResolveAssemblyReferences"
BeforeTargets="GenerateBindingRedirects"
Condition="'$(AutoGenerateBindingRedirects)' == 'true'">
<PropertyGroup>
<!-- Needs to be set in a target because it has to be set after the initial evaluation in the common targets -->
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
</Target>
</Project> |
@kcamp please help me to advise all who faced this issue in "old .net framework" - just verify binding redirects. Is it true? |
Yes, exactly. For those users targeting full framework, it will be necessary to ensure that they're either placing the redirects manually or re-working their project files to automatically generate them. |
Thank you man! @Guitrum you will be able to resolve the issue via correcting binding redirects. |
I would like to freeze this conversation. If somebody faces similar issue, please post new one referencing to this. Sorry, don't hesitate to describe your situation in new issue. |
What happened?
Ever since updating Selenium.WebDriver past 4.23.0, running integration tests fails on the OneTimeSetUp. To be clear, I can run my full integration test suite on 4.23.0, but I get the same setup failures on 4.24.0 and 4.25.0. For some reason it seems to still be looking for System.Text.Json, Version=8.0.0.0 even though the dependency requires 8.0.4. I notice that when trying to install 8.0.0 manually, it says there is a high severity vulnerability which is why I assume the update to require 8.0.4 exists.
Something is still stuck trying to download System.Text.Json 8.0.0 even after the update of the webdriver beyond 4.23.0
How can we reproduce the issue?
Install Selenium.WebDriver v4.25.0 and try to run integration test suite.
Relevant log output
Operating System
Windows 11
Selenium version
Selenium.WebDriver v4.25.0
What are the browser(s) and version(s) where you see this issue?
Chrome
What are the browser driver(s) and version(s) where you see this issue?
Selenium.WebDriver.ChromeDriver v129.0.6668.10000
Are you using Selenium Grid?
No response
The text was updated successfully, but these errors were encountered: