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: