MissingManifestResourceException with linked resource

[Symbai]

• .NET Core Version: 3.0

• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

  Problem description:

With a file-linked* resource file, the app crashes on runtime when accessing it. The same app was ported from .NET Framework 4.8 where it worked without any issue. The project has no errors on build.

• VS right click add existing file, at the bottom on the add button choose "add as link" instead.

  Actual behavior:

System.Resources.MissingManifestResourceException: 'Could not find the resource "SchmuhHost.Properties.Resources.resources" among the resources "SchmuhClient.g.resources", "SchmuhClient.Properties.Resources.resources" embedded in the assembly "SchmuhClient", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.'

Expected behavior:

No crash

Minimal repro: Host = project with normal resource file. Create resource string called "BlaString" with content "blabla {0}" Client = project that has the host's resource file linked

In client's code: string.Format(Properties.Resources.BlaString, 12)

In client's project file

  <ItemGroup>
    <Compile Include="..\..\SchmuhHost\SchmuhHost\Properties\Resources.Designer.cs">
      <Link>Properties\Resources.Designer.cs</Link>
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <EmbeddedResource Include="..\..\SchmuhHost\SchmuhHost\Properties\Resources.resx">
      <Link>Properties\Resources.resx</Link>
      <Generator>PublicResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <CustomToolNamespace>SchmuhHost.Properties</CustomToolNamespace>
    </EmbeddedResource>
  </ItemGroup>

[grubioe]

@rainersigwald - is this related to https://github.com/microsoft/msbuild/issues/4794?

[rainersigwald]

I don't think so: there's no locale id in the resx filename.

I suspect this is related to the DependentUpon convention, though. cc @BenVillalobos

Can you try setting

<EmbeddedResourceUseDependentUponConvention>False</EmbeddedResourceUseDependentUponConvention>

?

[Symbai]

@rainersigwald I added this line to the csproj file but it didn't helped. Same exception in release but also in debug mode when started in VS. Platform target is set to x64 if that matters.

[Symbai]

I fixed the issue by manually renaming in Resources.Designer.cs: global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("SchmuhHost.Properties.Resources", typeof(Resources).Assembly); to global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("SchmuhClient.Properties.Resources", typeof(Resources).Assembly); Sadly this has to be done by hand and reverted before rebuilding the host app but its okay for my purpose.

[weltkante]

@Symbai you can add a LogicalName tag to change the metadata name of an EmbeddedResource so it matches what the .Designer.cs expects. Its certainly not a good idea to rebuild the .Designer.cs with different settings in different projects, thats not the point of the code generator (if you want that you should have distinct .Designer.cs files and not share them)

Its normal however that resx files get the default namespace of the project prepended, so you claiming that it works in Desktop Framework gets me confused. You might have had settings in the Desktop Framework that you forgot to migrate to the Core project? Like both projects having the same default namespace?

Or is this a bug in .NET Core not respecting the CustomToolNamespace SchmuhHost.Properties when naming the embedded resource? I thought that property was only for generating the .Designer.cs but I may be mistaken.

And if this indeed a bug you might want to keep the issue open so it can be fixed eventually.

[Symbai]

@weltkante After editing the line I wasn't so sure about this anymore. I think I just forgot about anything I did in the framework project although I cannot find what exactly.

Editing the CustomToolNamespace is what people recommend to do when share a resource file between two projects. I also have to admit that I am not only sharing the resource file but also sharing class files as a linked file which need to still work in VS code when they access the resource file.

If it is a bug, which I have some doubts now, it may be too specific?