"MSB3823: Non-string resources require the property GenerateResourceUsePreserializedResources to be set to true" if TargetFramework=net48

[to-st]

We have a few projects that muti target .net core and the old fashioned .net framework. Some of these include binary resources (mostly images). With .net core 2.1 / 2.2 they build successfully but accessing an image while running under .net core throws an exception while with the full framework everything continues to works.
Now .net core 3.0 added support for binary resources giving us the chance to eliminate a few workarounds.
But now TargetFramework=net48 fails to build. As we are still in the transition to .net core and most of our products (still) require the full framework. Therefore this blocks any usage of .net core 3.0 in our codebase.

Steps to reproduce

unzip the attached project and run "dotnet build" or "dotnet build -p:TargetFramework=net48". Note that "dotnet build -p:TargetFramework=netcoreapp3.0" builds successfully.

LibraryWithImage.zip

Expected behavior

Successful build - net48 definitely supports images inside .resx

Actual behavior

Microsoft (R)-Build-Engine, Version 16.3.0-preview-19426-01+faf5e5d75 f▒r .NET Core
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

  Wiederherstellung in "113,4 ms" f▒r "C:\source\ResxBug\LibraryWithImage\LibraryWithImage.csproj" abgeschlossen.
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
C:\Program Files\dotnet\sdk\3.0.100-preview9-014004\Microsoft.Common.CurrentVersion.targets(3056,5): error : MSB3823: Non-string resources require the property GenerateResourceUsePreserializedResources to be set to true. [C:\source\ResxBug\LibraryWithImage\LibraryWithImage.csproj]
C:\Program Files\dotnet\sdk\3.0.100-preview9-014004\Microsoft.Common.CurrentVersion.targets(3056,5): warning MSB3555: Die Ausgabedatei "C:\source\ResxBug\LibraryWithImage\obj\Debug\net48\LibraryWithImage.Resources.resources" ist m▒glicherweise besch▒digt. [C:\source\ResxBug\LibraryWithImage\LibraryWithImage.csproj]
  LibraryWithImage -> C:\source\ResxBug\LibraryWithImage\bin\Debug\netcoreapp3.0\LibraryWithImage.dll

Fehler beim Buildvorgang.

C:\Program Files\dotnet\sdk\3.0.100-preview9-014004\Microsoft.Common.CurrentVersion.targets(3056,5): warning MSB3555: Die Ausgabedatei "C:\source\ResxBug\LibraryWithImage\obj\Debug\net48\LibraryWithImage.Resources.resources" ist m▒glicherweise besch▒digt. [C:\source\ResxBug\LibraryWithImage\LibraryWithImage.csproj]
C:\Program Files\dotnet\sdk\3.0.100-preview9-014004\Microsoft.Common.CurrentVersion.targets(3056,5): error : MSB3823: Non-string resources require the property GenerateResourceUsePreserializedResources to be set to true. [C:\source\ResxBug\LibraryWithImage\LibraryWithImage.csproj]
    1 Warnung(en)
    1 Fehler

Verstrichene Zeit 00:00:02.58

Environment data

SDK 3.0.100-preview9-014004 installed using the installer (see https://dotnet.microsoft.com/download/dotnet-core/3.0 )

[rainersigwald]

This is an intentional change with .NET Core SDK 3.0. As you point out, the prior versions of MSBuild on .NET Core would produce corrupted output which would crash at runtime. With the new version, it's possible to embed resources when using .NET Core MSBuild, but because they're embedded in a different way, they require a new reference to access them at runtime: System.Resources.Extensions. This is available as a NuGet package which will be published to NuGet.org when .NET Core 3.0 is released. It's available now from a prerelease feed https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json.

[to-st]

just to make sure: It is intentional that if you have a project with the new csproj format, binary resources, a PackageReference to System.Resources.Extensions and add net48 as targetframework it won't built using "dotnet build"?
I do not complain that netcoreapp2.1 no longer builds broken dll ;)

I assume support for binary resources in net48 is not dropped altogether, so how should I build a project with the new csproj format for net48? Calling the msbuild from the .net framework build tools directly?

[rainersigwald]

It is intentional that if you have a project with the new csproj format, binary resources, a PackageReference to System.Resources.Extensions and add net48 as targetframework it won't built using "dotnet build"?

Correct.

how should I build a project with the new csproj format for net48? Calling the msbuild from the .net framework build tools directly?

Yes: projects built using Visual Studio or MSBuild.exe (as opposed to dotnet build or dotnet msbuild) use the older approach to serialize resources into the output assembly by default. It's not ideal to have the project built two different ways depending on how you launched the build, though, so I would recommend always specifying GenerateResourceUsePreserializedResources=true in your projects and referencing System.Resources.Extensions. That unifies on the new codepath.

[RusKnyaz]

I did not quite understand. What if I just want my existing project to build successfully both on machines with netcore2.1 and on machines with netcore3.0? However, I do not want to change anything, and am ready to get resources through Assembly.GetManifestResourceStream.

[RusKnyaz]

I solved my issue by removing of the extra lines from Resources.resx file.

[rainersigwald]

What if I just want my existing project to build successfully both on machines with netcore2.1 and on machines with netcore3.0?

If your projects built successfully with the .NET Core SDK 2.1, they should work without modification in .NET Core SDK 3.0. If the projects built without errors but produced corrupt outputs in 2.1, they can be built correctly only with 3.0's new behavior.

[figloalds]

I did not quite understand. What if I just want my existing project to build successfully both on machines with netcore2.1 and on machines with netcore3.0? However, I do not want to change anything, and am ready to get resources through Assembly.GetManifestResourceStream.

I got mad too and I was about to just rage uninstall dotnet sdk 3.0, but then it was just add

<PackageReference Include="System.Resources.Extensions" Version="4.6.0" />
to references and
<GenerateResourceUsePreserializedResources>true</GenerateResourceUsePreserializedResources>
to a property group

I have a few complaints though: GenerateResourceUsePreserializedResources is a HUGE and ugly name and also I wonder why and who would ever disable this, if it's the only way to get embed resources in SDK 3.0 to build?
It looks unnecessary to add that ugly bigass name property to my csproj and the error message could have been: Hey, you just need to install System.Resources.Extensions from NuGet, we'll make the rest work.
This over here is one of my biggest rants with .Net lately: Things keep breaking every time you upgrade the SDK. :\

[figloalds]

Actually after I applied the fixes suggested NOW the application causes runtime error with Unable to load file or assembly 'System.Resources.Extensions, Version=4.0.0
I'm uninstalling SDK 3.0 because it's causing a lot more problems than it should it Installed automatically with Visual Studio update and just broke a lot of code that used to work fine when building with dotnet cli 2.2.300 and even after trying to apply the changes suggested by the SDK it still caused more problems.

Edit: except it's not possible without removing the entire Web Development from Visual Studio altogether. So because of a broken update on Visual Studio I have to completely remove non-string resources from projects because my dotnet command will just build broken assemblies otherwise.

Edit 2: Fixed by going to C:\Program Files\dotnet\sdk and hardcore deleting 3.0.100;

[MiguelAlho]

Also noticed this fix won't work when targeting net45, since the System.Resources.Extensions package does not support it (minimum is netstandard2.0 which would be net461). I know net45 is old, but this app is an installer intended to run on machines that might not have any new version of .Net running (but will install net48 if needed).