On Linux, integration tests using ManifestEmbeddedFileProvider does not work with a specified root parameter

[Daniel-Khodabakhsh]

Description

On Linux only, when a test project intended for integration tests of Razor Class Libraries uses ManifestEmbeddedFileProvider(Assembly, string), the below callstack is encountered when the resource is accessed in the test.

The version of ASP.Net-Core I'm using is 2.2.0.

It failed with the following callstack:

Test run for /home/dan/ManifestEmbeddedLinuxBug/ManifestEmbeddedLinuxBug.Test/bin/Debug/netcoreapp2.2/ManifestEmbeddedLinuxBug.Test.dll(.NETCoreApp,Version=v2.2)
Microsoft (R) Test Execution Command Line Tool Version 15.9.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
[xUnit.net 00:00:02.13]     ManifestEmbeddedLinuxBug.PageTests.Test_embedded_resource_different_from_root [FAIL]
Failed   ManifestEmbeddedLinuxBug.PageTests.Test_embedded_resource_different_from_root
Error Message:
 System.NullReferenceException : Object reference not set to an instance of an object.
Stack Trace:
   at Microsoft.Extensions.FileProviders.Embedded.Manifest.ManifestFileInfo.EnsureLength()
   at Microsoft.Extensions.FileProviders.Embedded.Manifest.ManifestFileInfo.get_Length()
   at Microsoft.AspNetCore.StaticFiles.StaticFileContext.LookupFileInfo()
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.TestHost.HttpContextBuilder.<>c__DisplayClass10_0.<<SendAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.TestHost.ClientHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Testing.Handlers.CookieContainerHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Testing.Handlers.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at ManifestEmbeddedLinuxBug.PageTests.Test_embedded_resource_different_from_root() in /home/dan/ManifestEmbeddedLinuxBug/ManifestEmbeddedLinuxBug.Test/PageTests.cs:line 25
--- End of stack trace from previous location where exception was thrown ---

Total tests: 2. Passed: 1. Failed: 1. Skipped: 0.
Test Run Failed.
Test execution time: 4.6064 Seconds

In this project, both ManifestEmbeddedFileProvider(Assembly) and ManifestEmbeddedFileProvider(Assembly, string) are used but only the latter fails.

To Reproduce

Steps to reproduce the behavior:

1. Clone my toy project from https://github.com/Daniel-Khodabakhsh/ManifestEmbeddedLinuxBug
   • $ git clone https://github.com/Daniel-Khodabakhsh/ManifestEmbeddedLinuxBug.git
2. Run the following commands to start the test:

   • $ cd ManifestEmbeddedLinuxBug/ManifestEmbeddedLinuxBug.Test
     $ dotnet restore
     $ dotnet build
     $ dotnet test
     

3. If you were running on Windows, both tests would pass. If you were running on Linux, the above callstack would occur.

Expected behavior

The behaviour of this project should be the same on Windows and Linux.

[Igorbek]

The problem is in LogicalName of EmbeddedResource.
When it contains windows path separator \ (TestRoot\ResourcesToEmbedWithLogicalName/script2.js in the repro), the actual resource name has / at the same place, but the manifest file still leaves \ there. So Assembly.GetManifestResourceStream returns null.

To work this around, just replace \ to / in your csproj.

But it is still a bug to me.

[ghost]

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[Daniel-Khodabakhsh]

Issue still occurs on .NET-Core 2.1.805 (latest 2.1 at the time of this posting).
Updated my toy project from above to use 2.1 LTS, the same steps apply.

[ghost]

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[pranavkm]

@BrennanConroy do you know what area label this belongs to?

[javiercn]

@pranavkm putting this on MVC since we built it for Identity UI, we should obsolete it and remove it in the future since we recommend using Static Web Assets instead.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.