Error in .Net Core 3 preview 6 with individual user accounts in Linux docker

[analogrelay]

From @Thananji on Wednesday, June 26, 2019 3:43:36 AM

I created a web application (Razor pages) in dot core 3.0 preview 6 with individual user accounts in-app selected and enabled the docker support for Linux.
When I run the application, I got the error "System.ArgumentException: 'The path must be absolute.'" in CreateHostBuilder(args).Build().Run() method of Program.cs.
Am I missing anything or Is it a bug? Is there any workaround for this?
Thanks in advance?

Copied from original issue: dotnet/installer#2644

[analogrelay]

From @livarcocc on Wednesday, June 26, 2019 5:10:25 PM

@anurse another one that belongs in asp.net?

[analogrelay]

I can repro this as described. Looks like an error in the StaticWebAssets.Reader:

Unhandled Exception: System.ArgumentException: The path must be absolute.
Parameter name: root
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
   at Microsoft.AspNetCore.StaticWebAssetsFileProvider..ctor(String pathPrefix, String contentRoot)
   at Microsoft.AspNetCore.StaticWebAssetsLoader.<>c.<UseStaticWebAssetsCore>b__2_0(ContentRootMapping cr)
   at System.Linq.Enumerable.SelectEnumerableIterator`2.MoveNext()
   at System.Linq.Enumerable.OfTypeIterator[TResult](IEnumerable source)+MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssetsCore(IWebHostEnvironment environment, Stream manifest)
   at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssets(IWebHostEnvironment environment)
   at Microsoft.AspNetCore.WebHost.<>c.<ConfigureWebDefaults>b__9_0(WebHostBuilderContext ctx, IConfigurationBuilder cb)
   at Microsoft.AspNetCore.Hosting.Internal.GenericWebHostBuilder.<>c__DisplayClass8_0.<ConfigureAppConfiguration>b__0(HostBuilderContext context, IConfigurationBuilder builder)
   at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
   at Microsoft.Extensions.Hosting.HostBuilder.Build()
   at WebApplication6.Program.Main(String[] args) in C:\Users\anurse\source\repos\WebApplication6\WebApplication6\Program.cs:line 16

The manifest file appears to have a Windows path:

<StaticWebAssets Version="1.0">
  <ContentRoot BasePath="_content/microsoftaspnetcoreidentityui" Path="C:\Users\anurse\.nuget\packages\microsoft.aspnetcore.identity.ui\3.0.0-preview6.19307.2\build\..\staticwebassets\" />
</StaticWebAssets>

The docker tooling does a local build (on Windows) and then projects the application in to the (Linux) container via a volume mount so a Windows path is invalid here.

@javiercn sounds like this is the stuff you added recently? (cc @mkArtakMSFT)

[javiercn]

@anurse Yes.

I didn't think of docker scenarios, and this might be a headache. @SteveSandersonMS @danroth27 we should fix this.

[javiercn]

This is problematic because due to the way it works some things would have to happen:

• An original manifest gets generated with the machine paths.
• Those paths need to be mapped into the container.
• A new manifest needs to be generated with the container paths.

[analogrelay]

Why are we burning in absolute paths here? Is this a dev-only experience?

[javiercn]

@anurse Yes

[javiercn]

We can use HasContainerTargets to detect if docker is enabled and based on that we might be able to hook into additional targets to add additional file path mappings when the container runs and produce an updated manifest.

[javiercn]

Hmm, I think we need to investigate this more. AFAIK the docker file will do a publish step

FROM build AS publish
RUN dotnet publish "project.csproj" -c Release -o /app

and run the app like

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "project.dll"]

There should be no manifest involved in that.

It might be that the way the docker tools run has changed and we might need to adapt the manifest.

[analogrelay]

Right, but if you F5 directly, you can see in the output window that the commands it uses are to build the base image and then run that directly, injecting the Windows-built app in as a volume mount.

[javiercn]

@anurse I see. Then I think we might need to do something for this case. That won't work even for referenced projects.

[analogrelay]

If you just need to resolve the path to a NuGet package at dev-time, it might be better to leave out the absolute path and use something like the [appname].runtimeconfig.dev.json file. Let me take a quick look and see if I can get more details for you (particularly if it works for docker).

[javiercn]

@anurse Can you try something quick for me given that you have this setup already? Could you setup $(ContainerDevelopmentMode) to Regular in your msbuild project and see if that fixes it?

Ultimately we have a manifest that I think has the wrong paths because it gets generated on windows and used on Linux, so a proper fix to this is gonna involve mounting additional volumes and overriding this manifest.

[analogrelay]

Yeah, the docker tools do the "right thing" here, and you can even access this data at runtime via AppContext.GetData.

So, if you are just trying to resolve content relative to a specific NuGet package, rather than burning in the full path, you can burn in the ID, Version and Relative path:

<StaticWebAssets Version="1.0">
  <ContentRoot BasePath="_content/microsoftaspnetcoreidentityui" PackageId="Microsoft.AspNetCore.Identity.UI" Version="3.0.0-preview6.19307.2" Path="staticwebassets" />
</StaticWebAssets>

Then at runtime you can take AppContext.GetData("PROBING_DIRECTORIES") to get a list (separated by Path.PathSeparatorChar) of probing directories that are expected to have NuGet packages. Normally this is provided by [appname].runtimeconfig.dev.json:

{
  "runtimeOptions": {
    "additionalProbingPaths": [
      "C:\\Users\\anurse\\.nuget\\packages",
      "C:\\Microsoft\\Xamarin\\NuGet",
      "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder"
    ]
  }
}

The docker tools do take care of projecting each of these paths into the container via a volume mount. They also execute the app by providing the host with these new, container-local, paths as probing paths:

docker exec -i -e ASPNETCORE_URLS="https://+:443;http://+:80" -e ASPNETCORE_HTTPS_PORT="44335" e4c52d5383b314169e9ccb836d4def9ac95a31b35768fe890691cec2d134a4ed "dotnet" --additionalProbingPath /root/.nuget/fallbackpackages3 --additionalProbingPath /root/.nuget/fallbackpackages --additionalProbingPath /root/.nuget/fallbackpackages2  "bin/Debug/netcoreapp2.2/WebApplication5.dll"

So when you query AppContext.GetData("PROBING_DIRECTORIES") at runtime, you get the right values:

/root/.nuget/fallbackpackages3:/root/.nuget/fallbackpackages:/root/.nuget/fallbackpackages2:

[analogrelay]

Once you have those paths, you can probe by simply splitting on Path.PathSeparatorChar and checking if the Path.Combine(probingPath, PackageId.ToLowerInvariant(), PackageVersion.ToLowerInvariant()) directory exists. If it does, you found the package. If not, try the next path.

Can you try something quick for me given that you have this setup already? Could you setup $(ContainerDevelopmentMode) to Regular in your msbuild project and see if that fixes it?

I don't have the project handy to try that now. If that forces the entire build to happen in Docker, I expect it would fix the issue. It seems significantly limiting though.

[javiercn]

@anurse What you are suggesting is not an option as files on the package are defined through msbuild props files within the package, and not by some convention, and that also doesn't take into account referenced project with static assets.

We also don't want to be bundling that resolution logic at the runtime level. I already started a thread about this with the appropriate people, I think making it go through the regular path is good enough for now if it worksaround it, while we work on a more complete fix.

I think ultimately we will produce a list of paths that need to be mapped and have docker consume it, and we will produce an additional manifest that can be used with docker during development.

[endeffects]

I have the same issue, is there any workaround available?

[javiercn]

@endeffects try setting <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode> on your csproj file and see if that fixes your issue.

[endeffects]

Thanks for your reply. But this does not fix the issue.

[endeffects]

When i run docker compose from console i'm getting the following error,
so maybe this is related to something else?

The wwwroot of the client cannot be found:

docker-compose up
Creating network "application-public-net" with driver "bridge"
Creating My.server ... done Attaching to My.server
My.server |
My.server | Unhandled Exception: System.IO.DirectoryNotFoundException: /src/My.Client/wwwroot/
My.server | at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
My.server | at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
My.server | at Microsoft.AspNetCore.StaticWebAssetsFileProvider..ctor(String pathPrefix, String contentRoot)
My.server | at Microsoft.AspNetCore.StaticWebAssetsLoader.<>c.b__2_0(ContentRootMapping cr)
My.server | at System.Linq.Enumerable.SelectEnumerableIterator2.MoveNext() My.server | at System.Linq.Enumerable.OfTypeIterator[TResult](IEnumerable source)+MoveNext() My.server | at System.Collections.Generic.List1..ctor(IEnumerable1 collection) My.server | at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)
My.server | at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssetsCore(IWebHostEnvironment environment, Stream manifest)
My.server | at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssets(IWebHostEnvironment environment)
My.server | at Microsoft.AspNetCore.WebHost.<>c.b__9_0(WebHostBuilderContext ctx, IConfigurationBuilder cb)
My.server | at Microsoft.AspNetCore.Hosting.Internal.GenericWebHostBuilder.<>c__DisplayClass8_0.b__0(HostBuilderContext context, IConfigurationBuilder builder)
My.server | at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
My.server | at Microsoft.Extensions.Hosting.HostBuilder.Build()
My.server | at My.Server.Program.Main(String[] args) in /src/My.Server/Program.cs:line 10

Within Visual Studio i receive an other error by running the composer project:

Exception thrown: 'System.ArgumentException' in Microsoft.Extensions.FileProviders.Physical.dll
An unhandled exception of type 'System.ArgumentException' occurred in Microsoft.Extensions.FileProviders.Physical.dll: 'The path must be absolute.'
Stack trace:

at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
at Microsoft.AspNetCore.StaticWebAssetsFileProvider..ctor(String pathPrefix, String contentRoot)
at Microsoft.AspNetCore.StaticWebAssetsLoader.<>c.b__2_0(ContentRootMapping cr)
at System.Linq.Enumerable.SelectEnumerableIterator2.MoveNext() at System.Linq.Enumerable.<OfTypeIterator>d__611.MoveNext()
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssetsCore(IWebHostEnvironment environment, Stream manifest)
at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssets(IWebHostEnvironment environment)
at Microsoft.AspNetCore.WebHost.<>c.b__9_0(WebHostBuilderContext ctx, IConfigurationBuilder cb)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
at My.Server.Program.BuildWebHost(String[] args) in C:\Prototyping\Services\My\My.Server\Program.cs:line 15
at My.Server.Program.Main(String[] args) in C:\Prototyping\Services\My\My.Server\Program.cs:line 11

[dustinlacewell]

I am having the same issue with a bare-bones blazorserver template.

##
## STAGE: frontend
##
FROM node:alpine as frontend
WORKDIR /Source

# npm clean install (installs exact versions from package-lock.json)
COPY Frontend/package.json ./
COPY Frontend/package-lock.json ./
RUN npm ci

COPY Frontend/. ./
RUN npm run build:Debug -- --output-path /Build
ENTRYPOINT npm run build:Watch -- --output-path /Build


##
## STAGE: build
##
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY Disunity.Store/*.csproj ./asp/
RUN dotnet restore asp

# copy frontend
COPY --from=frontend /Build/. ../Frontend/dist

# copy everything else and build app
COPY Disunity.Store/. ./asp/
WORKDIR /app/asp
RUN dotnet publish -c Release -o out


##
## STAGE: runtime
##
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY --from=build /app/asp/out ./
ENTRYPOINT ["dotnet", "Disunity.Store.dll"]

The resulting error is,

web_1       | Unhandled Exception: System.IO.DirectoryNotFoundException: /root/.nuget/packages/microsoft.aspnetcore.identity.ui/3.0.0-preview6.19307.2/staticwebassets/
web_1       |    at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
web_1       |    at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
web_1       |    at Microsoft.AspNetCore.StaticWebAssetsFileProvider..ctor(String pathPrefix, String contentRoot)
web_1       |    at Microsoft.AspNetCore.StaticWebAssetsLoader.<>c.<UseStaticWebAssetsCore>b__2_0(ContentRootMapping cr)
web_1       |    at System.Linq.Enumerable.SelectEnumerableIterator`2.MoveNext()
web_1       |    at System.Linq.Enumerable.OfTypeIterator[TResult](IEnumerable source)+MoveNext()
web_1       |    at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
web_1       |    at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
web_1       |    at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssetsCore(IWebHostEnvironment environment, Stream manifest)
web_1       |    at Microsoft.AspNetCore.StaticWebAssetsLoader.UseStaticWebAssets(IWebHostEnvironment environment)
web_1       |    at Microsoft.AspNetCore.WebHost.<>c.<ConfigureWebDefaults>b__9_0(WebHostBuilderContext ctx, IConfigurationBuilder cb)
web_1       |    at Microsoft.AspNetCore.Hosting.Internal.GenericWebHostBuilder.<>c__DisplayClass8_0.<ConfigureAppConfiguration>b__0(HostBuilderContext context, IConfigurationBuilder builder)
web_1       |    at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
web_1       |    at Microsoft.Extensions.Hosting.HostBuilder.Build()
web_1       |    at Disunity.Store.Code.Startup.Program.Main(String[] args) in /app/asp/Code/Startup/Program.cs:line 25
store_web_1 exited with code 139

If I add the following line as the second-to-last-line in the Dockerfile then it works:

COPY --from=build /root/.nuget /root/.nuget

But this seems really bad. Does my production container really need all my nuget dependency packages?

[javiercn]

You don’t. This is a bug we are working on solving

[analogrelay]

I don't believe we directly control the Dockerfile used here, it's the VS Docker Tools that do it. @glennc may know who to reach out to.

[javiercn]

I've confirmed that with an updated docker file (see below) <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode> just works

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0.0-preview7-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["mvcpreview7docker.csproj", ""]
RUN dotnet restore "./mvcpreview7docker.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "mvcpreview7docker.csproj" -c Release -o /app

FROM build AS publish
# Put the publish content into its own folder
RUN dotnet publish "mvcpreview7docker.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
# Copy only the published content
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "mvcpreview7docker.dll"]

[javiercn]

@danroth27 @mkArtakMSFT I consider my work here done until we decide if we need to do a fix on our side to enable fast mode (or is something that the docker tooling takes care of) or if the current guidance to turn on regular mode is good enough. @danroth27 is gonna get in touch with the right folks to discuss what can be done here.

Should we close this issue and open a new one to track that?

[endeffects]

@javiercn I still can't get it to work, i have provided a sample here:
https://github.com/endeffects/DockerTest/

The sample uses a docker-compose project and a client side blazor application hosted on a .net core server. It also contains the third party library (BlazorStrap) that includes some static assets.

I had the following issues with your last suggestion:

1. The fix for the docker file does not fix the problem with visual studio. Means, i'm not able to run the docker-compose project from VS, I have to run docker-compose from console.
2. If i apply the fix, the routing for blazor does not work anymore, i can not open the default page.
3. If i remove the fix, i'm receiving the error for the missing static assets of the third party component.
4. If i also remove the third party component, i'm receiving the path error from above.

[javiercn]

@endeffects On your dockerfile for the server you are setting the publish output to the same folder as the build output which is wrong and the root cause of the <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode> not working properly.

https://github.com/endeffects/DockerTest/blob/master/DockerTest.Server/Dockerfile#L16-L19

[endeffects]

Yes, i also tried this as described above.

[javiercn]

What error are you seeing.

[endeffects]

1. The fix for the docker file does not fix the problem with visual studio. Means, i'm not able to run the docker-compose project from VS, I have to run docker-compose from console.
2. If i apply the fix, the routing for blazor does not work anymore, i can not open the default page.

[javiercn]

1. The fix for the docker file does not fix the problem with visual studio. Means, i'm not able to run the docker-compose project from VS, I have to run docker-compose from console.

You mean <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode> does not work?

• Do you see the app being published?
• Have you checked the publish output to make sure everything is in there?

2. If i apply the fix, the routing for blazor does not work anymore, i can not open the default page.

• Does it crash with an exception?
• Do you get a 404?

[javiercn]

@mkArtakMSFT We worked with the docker folks and the right changes have been made or are being made, so I'm closing this issue as we don't have any further action here.

[cowlinb6]

I'm still getting this issue. If I reference Microsoft.AspNetCore.Identity.UI then when I try and run this through VS it fails to start with this error:

An unhandled exception of type 'System.ArgumentException' occurred in Microsoft.Extensions.FileProviders.Physical.dll: 'The path must be absolute.'
Stack trace:

at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)
at Microsoft.AspNetCore.Hosting.StaticWebAssets.StaticWebAssetsFileProvider..ctor(String pathPrefix, String contentRoot)
at Microsoft.AspNetCore.Hosting.StaticWebAssets.StaticWebAssetsLoader.<>c.b__2_0(ContentRootMapping cr)
at System.Linq.Enumerable.SelectEnumerableIterator2.MoveNext() at System.Linq.Enumerable.<OfTypeIterator>d__611.MoveNext()
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Microsoft.AspNetCore.Hosting.StaticWebAssets.StaticWebAssetsLoader.UseStaticWebAssetsCore(IWebHostEnvironment environment, Stream manifest)
at Microsoft.AspNetCore.Hosting.StaticWebAssets.StaticWebAssetsLoader.UseStaticWebAssets(IWebHostEnvironment environment, IConfiguration configuration)
at Microsoft.AspNetCore.WebHost.<>c.b__9_0(WebHostBuilderContext ctx, IConfigurationBuilder cb)
at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.<>c__DisplayClass8_0.b__0(HostBuilderContext context, IConfigurationBuilder builder)
at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at WebApplication1.Program.Main(String[] args) in d:\code\test\WebApplication1\WebApplication1\Program.cs:line 16

Setting the ContainerDevelopmentMode to Regular and updating the Docker file with the alternate publish folder makes no difference.

Anything else that I maybe missing?

[javiercn]

Hi @cowlinb6

It looks like you are posting on a closed issue!

We're very likely to lose track of your bug/feedback/question unless you:

1. Open a new issue
2. Explain very clearly what you need help with
3. If you think you have found a bug, include a link to a github repo with a minimal repro project and detailed steps describing the problem. Please also indicate your visual studio version.

[cowlinb6]

Just in case anyone has similar issues, the problem looks to be resolved with Visual Studio 2019 Preview (16.4.0 P1).

[endeffects]

I'm running the latest Preview and still have the issue. Currently i'm waiting for the next visual studio and the .net core release.

[digitalsigi]

same here. I'm using VS2019 16.3.9 and occasionally I get System.IO.DirectoryNotFoundException: C:\root.nuget\packages\microsoft.aspnetcore.identity.ui\3.0.0\staticwebassets\V4\ wenn starting the app directly. Surprisingly the error disappears when swithing to IIS and back.