Can no longer compile any project after upgrading from .NET 9.0 Preview 7 to .NET 9.0 RC1

[MarkCiliaVincenti]

The steps I took:

• Uninstall .NET 9.0 Preview 7
• Install .NET 9.0 RC1
• Upgrade Visual Studio 2022 to the latest version

Every project I try compiling I'm getting this error even though it's not referencing System.Text.Json, even transitively.

C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1060: Error reading assets file: Error loading lock file 'C:[....]\obj\project.assets.json' : Could not load file or assembly 'System.Text.Json, Version=8.0.0.4, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

I tried redownloading and reinstalling, repairing, deleted the NuGet package cache, manually deleted the bin and obj folders, rebooted the PC... basically everything I could think of

[Youssef1313]

We are encountering this in Uno Platform as well once we updated to RC1

[MarkCiliaVincenti]

What I find strange is the version number. Should it really be 8.0.0.4? The latest stable NuGet package version is 8.0.4

[MarkCiliaVincenti]

We are encountering this in Uno Platform as well once we updated to RC1

Only in Uno Platform though? I'm having this issue in every project. I can start a new solution, add a class library with nothing in it, try to compile and I get that error.

[Youssef1313]

It shouldn't be specific to Uno Platform, just mentioning that we are also unable to upgrade to RC1 due to this issue

[Youssef1313]

This may be related to #40645 ?

cc @Forgind

[MarkCiliaVincenti]

Quite likely, possibly this commit: 337965f

In my SDK folder I have 8 files called System.Text.Json.dll

Four are file version 9.0.24.43107
Two are file version 8.0.724.31311 with a file size of 628 KB
Two are also file version 8.0.724.31311 but have a file size of 566 KB

None of them are 8.0.0.4

[KalleOlaviNiemitalo]

What I find strange is the version number. Should it really be 8.0.0.4? The latest stable NuGet package version is 8.0.4

https://nuget.info/packages/System.Text.Json/8.0.4 shows lib/net8.0/System.Text.Json.dll with full name System.Text.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, not assembly version 8.0.0.4. The file version 8.0.724.31311 does not matter for the assembly load error.

https://nuget.info/packages/System.Text.Json/9.0.0-rc.1.24431.7 shows both lib/net8.0/System.Text.Json.dll and lib/net9.0/System.Text.Json.dll with full name System.Text.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 and file version 9.0.24.43107. I suppose this could be suitable for the referenced assembly version 8.0.0.4 if there were an assembly binding redirection.

[wanggangzero]

I meet this problem too!
to avoid this Exception, you can place a global.json in your project's root folder to specify the version of sdk 8.0.401

[MarkCiliaVincenti]

I meet this problem too! to avoid this Exception, you can place a global.json to specify the version sdk 8.0.401

But then you wouldn't be able to compile .NET 9 projects, no?

[wanggangzero]

I meet this problem too! to avoid this Exception, you can place a global.json to specify the version sdk 8.0.401

But then you wouldn't be able to compile .NET 9 projects, no?

Yes! I think you can down grade it to preview7 first.

[Youssef1313]

Looks like it's a known issue: https://github.com/dotnet/core/pull/9489/files

[MarkCiliaVincenti]

I hoped this App.config would help but it really didn't. Maybe I am missing something.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<runtime>
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
			<dependentAssembly>
				<assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" />
				<bindingRedirect oldVersion="8.0.0.4" newVersion="9.0.0.0" />
			</dependentAssembly>
		</assemblyBinding>
	</runtime>
</configuration>

[MarkCiliaVincenti]

I confirm that this is a Visual Studio issue. I was able to dotnet pack the same project that Visual Studio 2022 couldn't.

[KalleOlaviNiemitalo]

@MarkCiliaVincenti, which App.config file did you modify? It might need to be devenv.exe.config of Visual Studio but I'm not sure.

[MarkCiliaVincenti]

@MarkCiliaVincenti, which App.config file did you modify? It might need to be devenv.exe.config of Visual Studio but I'm not sure.

Interesting, but I'm not sure what I'm supposed to do here.

I tried this but it didn't work:

        <dependentAssembly>
          <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral"/>
          <bindingRedirect oldVersion="4.0.0.0-8.0.0.3" newVersion="8.0.0.3" />
          <codeBase version="8.0.0.3" href="PublicAssemblies\System.Text.Json.dll" />
        </dependentAssembly>

to:

        <dependentAssembly>
          <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral"/>
          <bindingRedirect oldVersion="4.0.0.0-8.0.0.4" newVersion="8.0.0.3" />
          <codeBase version="8.0.0.3" href="PublicAssemblies\System.Text.Json.dll" />
        </dependentAssembly>

[leppie]

Moved to #43356

[rainersigwald]

This is a known issue with the combination of Visual Studio 17.11 and .NET SDK 9.0.100-rc.1. It will be addressed in a future Visual Studio 17.11.x release.

Per the .NET SDK support matrix, you must use Visual Studio 17.12-preview to target .NET 9 from within Visual Studio. That’s the best way to get things working today.

To target .NET 8 or lower, there are a couple of workaround options while you wait for the fix (dotnet/msbuild#10650) to be available:

1. Use a global.json to continue using the 8.0 SDK even when .NET 9.0.100-rc.1 is installed.
2. an ugly workaround I'll post in a minute after I double-check it.

[rainersigwald]

@leppie please file a separate issue, that doesn't sound like this one.

[leppie]

@leppie please file a separate issue, that doesn't sound like this one.

Done #43356

And funny enough, I just ran into THIS issue now (msbuild) due to not having VS preview. Was working before.

[Youssef1313]

you must use Visual Studio 17.12-preview to target .NET 9 from within Visual Studio. That’s the best way to get things working today.

@rainersigwald The problem for us is mostly with CI scenarios where hosted agents don't yet contain 17.12. If there are ugly workarounds to use rc1 with 17.11.2 (e.g, messing up with System.Text.Json in the .NET installation or really anything else), we'd love to hear.

[rainersigwald]

If there are ugly workarounds to use rc1 with 17.11.2 (e.g, messing up with System.Text.Json in the .NET installation or really anything else), we'd love to hear.

working on it

[rainersigwald]

Workaround

This workaround can be checked into any affected repo, but should be removed as soon as possible.

Add the following to a Directory.Build.targets or another file that's imported into every project in your repo:

  <!-- BEGIN workaround for https://github.com/dotnet/sdk/issues/43339; remove after updated to VS 17.12 or a future 17.11 patch -->
  <Target Name="WorkaroundDotnetSdk43339" BeforeTargets="ResolvePackageAssets" Condition=" '$(MSBuildRuntimeType)' == 'Full' and $([MSBuild]::VersionLessThan($(MSBuildVersion), 17.12.0))">
    <PrimeSystemTextJson804 />
  </Target>
  <UsingTask
    TaskName="PrimeSystemTextJson804"
    TaskFactory="RoslynCodeTaskFactory"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" >
    <Task>
      <Code Type="Fragment" Language="cs">
<![CDATA[
try
{
    System.Reflection.Assembly.LoadFrom(@"$(MicrosoftNETBuildTasksDirectoryRoot)\..\..\..\DotnetTools\dotnet-format\BuildHost-net472\System.Text.Json.dll");
}
catch
{
    // Best effort: if something moves in the SDK don't break the build.
}
]]>
      </Code>
    </Task>
  </UsingTask>
  <!-- END workaround for https://github.com/dotnet/sdk/issues/43339 -->

It's working for the MSBuild repo; see dotnet/msbuild#10643.

[jeromelaban]

@rainersigwald this workaround is working for us as well! Thanks for the help!

[rainersigwald]

If all goes well, a VS-side fix will be released with release 17.11.4 (we just checked in to VS).

[baronfel]

A possible workaround for those who don't want to add that targets file to every project is maybe replacing every 8.0.0.4 to 8.0.4 in dotnet\sdk\9.0.100-rc.1.24452.12\DotnetTools\**.

I don't believe that will work - that directory contains tools like format, watch, etc., not the build logic that is causing the crash. I strongly encourage users to not go spelunking and modifying the SDK's installed layout.

[Saplonily]

I don't believe that will work - that directory contains tools like format, watch, etc., not the build logic that is causing the crash. I strongly encourage users to not go spelunking and modifying the SDK's installed layout.

yeah it won't, I got something wrong

[MarkCiliaVincenti]

There are 4 solutions:

1. Build from the command line (dotnet build)
2. Install Visual Studio 2022 Preview
3. Apply the workaround described at Can no longer compile any project after upgrading from .NET 9.0 Preview 7 to .NET 9.0 RC1 #43339 (comment)
4. Wait for Visual Studio 2022 17.11.4 to be released

[mfeemster]

Can confirm. I was eager to try .NET 9 RC 1 but nothing will build in Visual Studio 2022 Community edition now.

[MarkCiliaVincenti]

Since Visual Studio 2022 v17.11.4 is out, this problem is fixed.

[skyslide22]

Still occours on azure using a .net8 web app which used msbuild .net9 for compiling on AZURE
Deleted obj & bin folders, global.json, env DOTNET_VERSION 8.0, nuget cache clearing - nothing helped.

Solution

Deleting the dev slot on the azure portal and deploying on a brand new slot solved the issue.

For the ones who might end up here having the same issue ^^

[codethisio]

Still occours on azure using a .net8 web app which used msbuild .net9 for compiling on AZURE Deleted obj & bin folders, global.json, env DOTNET_VERSION 8.0, nuget cache clearing - nothing helped.

Solution

Deleting the dev slot on the azure portal and deploying on a brand new slot solved the issue.

For the ones who might end up here having the same issue ^^

Unfortunately, we still got the same error on a brand new slot. I'm hoping the Azure/.NET folks eventually get this sorted. We normally stay on LTS versions but wanted to observe the performance improvements of .NET 9 in a test environment.