MSB3823 starts occurring after installing Rider 2022.3

I'm currently unable to use Rider due to this bug. One of the core libraries in my main solution will not compile under Rider, but works fine in VS2022

Edit: Found a workaround. None of this is actually required by the project, so I have it only applied to Debug builds

  <!-- Rider Workaround https://rider-support.jetbrains.com/hc/en-us/community/posts/9007815743762 -->
  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <GenerateResourceUsePreserializedResources>true</GenerateResourceUsePreserializedResources>
  </PropertyGroup>

  <ItemGroup Condition="'$(Configuration)' == 'Debug'">
    <PackageReference Include="System.Resources.Extensions" Version="7.0.0" />
  </ItemGroup>

Found a workaround, this is dependent on also having VS2022 installed. Change the MSBuild version from the auto detected one (.net 7 here), to the VS 2022 MSbuild instance.

I have the same problem. I was developing an asp.net mvc/.Net framework 4.8 using Jetbrains Rider 2022.2.4 and after updating to 2022.3 it failed building. The problem resides on the MSBuild. Please help. Thanks.

Ed Eldy21, does chaning of toolset in settings help in your case? Does it help if you disable R# build in Preferences | Build, Execution, Deployment | Toolset and Build?

It doesn't change anything Olga Diakonova . Please see details below. 

We're also experiencing this issue where msbuild is happy but builds under Rider fail. Has there been any progress on a fix from JetBrains?

The impact is that Rider is unusable for the projects/solutions that have this problem.

Hi there,

We fixed the issue when Rider fails to build .NET Framework project because of the Microsoft.WebApplication.targets problem.

https://youtrack.jetbrains.com/issue/RIDER-87113/Cannot-build-.NET-Framework-projects-with-legacy-style-csproj-after-upgrading-to-2022.3.1

The fix will be available in the upcoming bugfix build (I hope). Please give it a try and let us know if it helps.

Hi there again.

If you experience the build issue, please call `Rebuild with Diagnostics` context action (Right click on a project > Advanced Build actions). Then collect all the logs via "Help | Collect Logs" and share them with us via attaching them to the youtrack issue comment https://youtrack.jetbrains.com/issue/RIDER-87113, or via the service https://uploads.jetbrains.com/ (Do not forget to let us know the uploads ID).

hello. i have this same issue with version 2022.3.3 and the latest 2023.1. i cant seem to get the error to go away which is rather frustrating. i'm stuck using visual studio until this is resolved.

Hello,

What MSBuild version do you have selected in Preferences | Build, Execution, Deployment | Toolset and Build? If you switch to another version, e.g. supplied with Visual Studio, do you still observe the same behavior?

Referencing MSBuild from Visual Studio worked for me, however it would need a separate Visual Studio license even if MSBuild was installed from Build Tools for Visual Studio, without the IDE.

 Switching MSBuild version used to version 17.0 mentioned above worked for me perfectly.

Sofia Byzova Ivan Skorikov This issue reproduces with latest Rider 2025.2 and MSBuild from latest .NET SDK 9.0.304. I don't have Visual Studio 2022 license so I cannot switch to VS MSBuild. Any workaround of fix timeline?

Hello Aleonovich,

I am sorry to hear that you are running into such an issue.

If the issue is just the same, you might want to try “Workaround 1” mentioned on the issue page: RIDER-87113 Cannot build .NET Framework projects with legacy style csproj after upgrading to 2022.3.1

However, I suppose the cause of the issue and the scenario are different in your case. So, I would appreciate it if you could elaborate on the issue you experience:

• Does the issue reproduce in a newly created project? If so, please share exact steps;
• Does the problematic project target .Net Framework? (or .net 9?)
  • Do you have .Net Framework Developer pack installed?
• Share the .binlog file (Invoke Build | Advanced Actions | Rebuild Solution with diagnostics);
• Share Rider logs (Help | Collect Logs and Diagnostic Data);
• Share a screenshot that demonstrates the issue;

Upload files to the Upload Service and let me know the Upload ID.

Hope to hear from you soon.
Have a nice day!

Dmitry Kazantsev 
The issue reproduces in a newly created project (it is a netstandard20 class library).
I have Net Framework 4.7.2 runtime, SDK and Targeting pack installed.
Steps to reproduce:

1. Create Class library project, choose netstandard20
2. Add reference to System.Resources.Extensions 8.0.0 nuget (changes nothing but that is metioned as a recomendation in Rider build window)
3. Place any .xslt file to project folder
4. Add Resources.resx and add that .xslt as named resource
5. Build and get MSB3823 error

Sample repo with minimal reproducible example.

Hello Aleonovich,

Thank you for the details shared. I see. I took another look into this issue. The reasoning for the build failure is that the .Net Core MSBuild.dll (the one used via `dotnet build`) handles non-textual resources differently in opposite to “full-framework” (.Net Framework) MSBuild.exe. You can't build your sample solution from the terminal using dotnet build, right? For me it fails with the same error.

Historically, MSBuild on .NET Core/.NET (invoked via dotnet build) used a path that could produce corrupted or non-portable .resources for non-string items (e.g., images, icons, byte[]). To prevent runtime failures, the .NET SDK 3.0+ changed behavior to require pre-serialization for non-string resources. If the property isn’t on and non-string resources are detected, the build fails with MSB3823 instead of silently producing bad output.
 
Pre-serialization relies on the System.Resources.Extensions mechanisms to serialize/deserialize supported non-string types in a runtime-agnostic way (works when consuming from .NET Core/.NET, .NET Framework, etc.). That’s why SDK-style projects with non-string resources typically need the System.Resources.Extensions package/reference when building with dotnet
 
You might find this thread and MSB3823 explanation helpful.
dotnet build (MSBuild running on .NET) enforces a safer, cross-runtime way of embedding non-string resources by requiring them to be pre-serialized. That’s what GenerateResourceUsePreserializedResources=true does. When it is unspecified or set to false, build errors with MSB3823 when detects non-string resources to force you to opt in and avoid invalid resource blobs
 
MSBuild.exe (Full Framework) uses the older resx processing, which can embed non-string resources without that pre-serialization step, so it “just works” there.

The available options are:

• Using the full-framework MSBuild.exe from Visual Studio. If you don't have such an opportunity, you can try using the MSBuild.exe bundled with Rider. Open Settings | Build, Execution, Deployment | Toolset and Build and switch MSBuild version: to {RiderInstallationPath}\tools\MSBuild\Current\Bin\amd64\MSBuild.exe.
• Or, using the .NET build (from .Net SDK 3.0+ MSBuild.dll, for e.g. the MSBuild.dll from .NET 9.0.304), ensure to specify <GenerateResourceUsePreserializedResources>true</GenerateResourceUsePreserializedResources> under the <PropertyGroup>…</PropertyGroup>, as there is no other way to get rid of the build error, while 
  • having an SDK-style project targeting net-standard2.0 ;
  • having non-string resources;
  • and trying to build such a project via dotnet build (that is supposed to use .Net 3.0+ SDK/MSBuild.dll). Rider uses dotnet build command for building when the MSBuild version: is set to MSBuild.dll.

Hope that helps. Have a nice day!

Dmitry Kazantsev 

Using the full-framework MSBuild.exe from Visual Studio. If you don't have such an opportunity, you can try using the MSBuild.exe bundled with Rider.

So there is no workaround to build on Linux without setting <GenerateResourceUsePreserializedResources>?

If you are on Linux and do not wish to use <GenerateResourceUsePreserializedResources> using the modern MSBuild, you might want to try using the MSBuild that ships with Mono (cross-platform .NET Framework implementation).

On MacOS, I was able to build the sample project you shared using this MSBuild:

If that doesn't work, the only remaining option on Linux is to set <GenerateResourceUsePreserializedResources> .