ManifestEmbeddedFileProvider corrupt manifest file

[dazinator]

Describe the bug

I am seeing the same issue that was described here: https://www.gitmemory.com/issue/aspnet/Extensions/1333/507701113
II get a runtime exception constructing the ManifestEmbeddedFileProvider because it complains that the format of it's embedded manifest file is wrong - even though this is produced for me (i.e by the build task).

On looking around I came accross the above link and can confirm it only happens in the project which also has an embedded resx file - it has these additional csproj entries:

 <ItemGroup>
        <Compile Update="Apps\PlatformSetup\Services\Resources\PlatformSeedData.Designer.cs">
            <DesignTime>True</DesignTime>
            <AutoGen>True</AutoGen>
            <DependentUpon>PlatformSeedData.resx</DependentUpon>
        </Compile>
    </ItemGroup>

    <ItemGroup>
        <EmbeddedResource Update="Apps\PlatformSetup\Services\Resources\PlatformSeedData.resx">
            <Generator>ResXFileCodeGenerator</Generator>
            <LastGenOutput>PlatformSeedData.Designer.cs</LastGenOutput>
        </EmbeddedResource>
    </ItemGroup>

To Reproduce

Create a vanilla csproj project, include the ManifestEmbeddedFileProvider but also set up an embedded RESX file like so:

 <ItemGroup>
        <Compile Update="Apps\PlatformSetup\Services\Resources\PlatformSeedData.Designer.cs">
            <DesignTime>True</DesignTime>
            <AutoGen>True</AutoGen>
            <DependentUpon>PlatformSeedData.resx</DependentUpon>
        </Compile>
    </ItemGroup>

    <ItemGroup>
        <EmbeddedResource Update="Apps\PlatformSetup\Services\Resources\PlatformSeedData.resx">
            <Generator>ResXFileCodeGenerator</Generator>
            <LastGenOutput>PlatformSeedData.Designer.cs</LastGenOutput>
        </EmbeddedResource>
    </ItemGroup>

Start your application and create an instance of the file provider.

Exceptions (if any)

As shown above.

Further technical details

• ASP.NET Core version: 3.1
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[javiercn]

@dazinator thanks for contacting us.

You can exclude things from the manifest by adding ExcludeFromManifest=true (Not sure if this is the exact attribute name, but there is a way) in the elements. That should unblock you.

I'm not sure what exactly is going on in this case, this is not an area we plan to invest in the future since it was mainly developed for Identity UI and the functionality it provides has been superseded by static web assets.

That said, if there is an obvious issue in this area and a clear fix, we would be willing to accept a PR with a fix for it.

[dazinator]

Ok thanks for quick response - I will find a workaround!

Regarding the surrounding comments though - I believe the issue that this provider solves is that embedded resources lose their original file path / directory information - due to the way the original file path is encoded (during a build) to produce the embedded resource name. The embedded manifest solves this issue by preserving a mapping between resource name and its original path captured at build time. This solves a general and long standing issues with working with embedded resources in the framework itself. Imho this provider should be promoted up the stack because of that. Static web assets may allow you to work around this problem in a web application scenario and identity- but thats a (more) niche scenario, what about:

• console apps or tools
• plugins
• basically any non web app
  That has (or wants) to work with embedded resources? I don't think static web assets can work for them can they!?

Those tools can go on using the old method of accessing embedded files without original path information preserved. But that seems a lost opportunity (and a shame) given you have solved this problem.

[javiercn]

@dazinator I wrote the ManifestEmbeddedFileProvider, it solves the issues you mention, but we wrote it because we needed it for Identity UI (although as you mention it can be used outside of it).

What I'm pointing out is that we haven't seen significant usage outside of our own usage and as such is not something we plan to invest time on improving in the near future. Supporting any scenario outside of the one defined for Identity UI (out original goal) is not part of our goals (although we won't block anyone from using it there) and as such we don't have any plans to work on improving it.

We have limited resources and this is not a priority area for us, that said, as I mentioned we are happy to accept contributions for bug fixes to improve it.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[andersstorhaug]

I am also running into this issue. To reproduce: create a standard WPF application with net5.0-windows and <GenerateEmbeddedFilesManifest>true</GenerateEmbeddedFilesManifest> and attempt to use ManifestEmbeddedFileProvider.

The generated manifest XML in this case is:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Manifest>
    <ManifestVersion>1.0</ManifestVersion>
    <FileSystem>
        <File Name="">
            <ResourcePath></ResourcePath>
        </File>
        <File Name="Microsoft.Extensions.FileProviders.Embedded.Manifest.xml">
            <ResourcePath>Microsoft.Extensions.FileProviders.Embedded.Manifest.xml</ResourcePath>
        </File>
    </FileSystem>
</Manifest>

I'm guessing this is due to WPF's generated resource file, WpfApp1.g.resources.

[andersstorhaug]

Here's a temporary (and minimal) workaround that removes the empty File node at runtime: FixedManifestEmbeddedAssembly.cs.

[javiercn]

We haven't seen enough demand for us to prioritize this ask.

We would be open to a PR that fixes the issue