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

[anurse]

_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/core-sdk#2644_

[anurse]

_From @livarcocc on Wednesday, June 26, 2019 5:10:25 PM_

@anurse another one that belongs in asp.net?

[anurse]

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.

[anurse]

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.

[anurse]

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.

[anurse]

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.

[anurse]

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:

[anurse]

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.ToListTSource
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

[endeffects]

Still exists on preview7.

[javiercn]

We are aware of this issue and we are working on a fix. In the mean time you are likely to be able to work-around it by settting <StaticWebAssetsEnabled>false<StaticWebAssetsEnabled> in your project.

Let us know if that helps.

[endeffects]

I tried this, but it does't work for me. The assets are provided by a third party component.

Unhandled exception. System.IO.DirectoryNotFoundException: /root/.nuget/packages/blazorstrap/1.0.0-preview7-01/staticwebassets/
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root)

[javiercn]

@endeffects You are right.
I think this might get you unblocked in the mean time

<PropertyGroup>
  <GenerateStaticWebAssetsManifestDependsOn>
    $(GenerateStaticWebAssetsManifestDependsOn);
    _RemoveAllStaticWebAssets
  </GenerateStaticWebAssetsManifestDependsOn>
</PropertyGroup>

<Target Name="_RemoveAllStaticWebAssets" DependsOnTargets="ResolveStaticWebAssetsInputs" >

    <ItemGroup>
      <StaticWebAsset Remove="@(StaticWebAsset)" />
    </ItemGroup>

</Target>

[javiercn]

This does it

  <Target Name="_RemoveAllStaticWebAssets" BeforeTargets="_CreateStaticWebAssetsInputsCacheFile" DependsOnTargets="ResolveStaticWebAssetsInputs">

    <ItemGroup>
      <StaticWebAsset Remove="@(StaticWebAsset)" />
    </ItemGroup>

  </Target>

[javiercn]

As a more general solution if you want to consume the static web assets, this solves the issue with docker

  <Target Name="_ContainerizeStaticWebAssets" BeforeTargets="_CreateStaticWebAssetsInputsCacheFile" DependsOnTargets="ResolveStaticWebAssetsInputs">

    <PropertyGroup>
      <OutDirContainerFormat>$(OutDir.Replace('\','/'))</OutDirContainerFormat>
    </PropertyGroup>

    <ItemGroup>

      <_StaticWebAssetContent Include="@(StaticWebAsset->'%(ContentRoot)%(RelativePath)')">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        <CopyToPublishDirectory>Always</CopyToPublishDirectory>
        <TargetPath>staticwebassets\%(BasePath)\%(RelativePath)</TargetPath>
      </_StaticWebAssetContent>

      <ContentWithTargetPath Include="@(_StaticWebAssetContent)" />

      <_UpdatedAssets Include="@(StaticWebAsset)">
        <ContentRoot>/app/$(OutDirContainerFormat)staticwebassets/%(BasePath)/</ContentRoot>
      </_UpdatedAssets>

      <StaticWebAsset Remove="@(StaticWebAsset)" />
      <StaticWebAsset Include="@(_UpdatedAssets)" />
    </ItemGroup>

  </Target>

[endeffects]

i tried the first both solutions, but it also did not worked for me.
I'm testing the third one now.

[javiercn]

I tested the second one on a vanilla app and was working without issue. Maybe you need to restart the container. The third one also works

[javiercn]

How are you running your container?

[endeffects]

I got the container running from console now, the error does not raise again.
I also saw some application messages, but there are no pages available nor swagger.
I'm getting an ERR_EMPTY_RESPONSE when i try to open them.
So the routing seems not to work anymore.

An other issue i'v noticed is, that i'm no longer able to run the docker container
from visual studio due the patched content root.

System.IO.DirectoryNotFoundException: '/bin/Debug/netcoreapp3.0/staticwebassets/_content/BlazorStrap/'

The folder exists, but visual studio seems to run on an other / higher working directory.

[javiercn]

@anurse I tracked this down.

This is an issue with the docker file. For fast mode, one could use the snippet above, but for
<ContainerDevelopmentMode>Regular</ContainerDevelopmentMode> the issue lies in the docker file.

And I don't think the way we build the production image is correct. Explanation follows:

• We create build, publish and final
• build is the result of doing dotnet build -o /app
• publish starts from build (not sure why) and dumps everything also into /app
• then final, simply copies the contents of /app into the final image.

This is wrong because final contains the union of the build artifacts and the published artifacts, then messing up the publish output.
Publish is the bit responsible for producing something executable, and its output should be put in a clean slate.
With static web assets, what happens is that given how we build the contianer, the staticwebassets.xml file which is intended only to be in the build folder, not the publish one, ends up in the published output, which causes the app to fail (because it runs in development and there's a file present, which triggers the runtime to try and use it).

For starters we should get the dockerfile fixed, i'm not sure why we do things this way, but unless there's something I'm missing is plain wrong.

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/_build

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

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

[anurse]

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.ToListTSource
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.