dotnet build with ResXFileRef doesn't work

See https://github.com/Microsoft/vsts-tasks/issues/5205

Build TaskRepro.zip using dotnet build and using msbuild.exe. You will notice the resources embedded in the output assembly are different:

Using dotnet build: You’ll see it is just a string value.

Using msbuild.exe: You’ll see it is actually a byte[].

This causes the resources.Designer.cs file’s code gen to error at runtime:

2017-09-01T20:07:41.9560273Z Initialization method Ommited.TestInitialize threw exception. System.InvalidCastException: Unable to cast object of type 'System.String' to type 'System.Byte[]'..
2017-09-01T20:07:41.9600087Z Stack Trace:
2017-09-01T20:07:41.9649846Z at Ommited.ExtensionsResources.get_TestFile() in d:\a\1\s\src\Tests\Ommited\Resources\ExtensionsResources.Designer.cs:line 564

        /// <summary>
        ///   Looks up a localized resource of type System.Byte[].
        /// </summary>
        internal static byte[] TestFile {
            get {
                object obj = ResourceManager.GetObject("TestFile", resourceCulture);
                return ((byte[])(obj));
            }
        }

[dasMulli]

However this is kind of… 💩 So VS calls the netfx msbuild and it will happily embed a binary file. Then the file generator hooked up in VS uses netfx msbuild logic to generate the strongly typed code file (for which there isn’t a .net core implementation) and that works. When built on .NET Core, msbuild will only emit string resources and the previously generated code file crashes on decoding. Best thing is probably to emit a warning / error in msbuild when the resx entry has the type="…" attribute defined to indicate that this project should be built using the netfx msbuild or implement the embedding logic (by implementing the winforms embedding type via convention).

[nguerrera]

This is a duplicate of https://github.com/Microsoft/msbuild/issues/2221

We generate satellite assemblies with our own code, but not the .resources files inside them. That is still handled by msbuild, and there is a bug in their handling on .NET Core.