Aspnetcore: Docker

[grahamehorner]

Please consider testing under docker; I'm experiencing issues getting Blazor to work and/or finding files when running in docker

[SteveSandersonMS]

We'll definitely need to make sure Blazor apps are nice to develop under Docker, so adding this to backlog. For now I'd recommend not running under Docker (or providing a PR that fixes whatever the issues are).

[grahamehorner]

The issue with Blazor and docker is that the Blazor client code lies outside of the Blazor hosting project folder that docker references and therefore when package using docker compose the client assemblies aren’t copied to the docker image, IMHO the location of the client assemblies should be relocated to a folder inside/under the hosting project. Not sure if you’re call the good old iis bug of website parent folder access :) it would also simplify folder permissions etc.

[SteveSandersonMS]

The Blazor client app needs to be outside the hosting project directory, because it's a separate .NET project. It has to be compiled separately because it targets a different architecture and references different assemblies.

I'm sure it's possible to set up a docker container that hosts both the client and server projects, but it will have to allow them to be in separate directories.

[glennc]

I can take a look at this on Monday with @danroth27 if you want.

[danroth27]

@glennc That would be great!

[grahamehorner]

@SteveSandersonMS maybe a post build step is needed to copy the Blazor bin folders etc into the hosting project that will deliver the wasm and other resources?

[glennc]

This problem isn't uncommon in .NET. If you follow the default Docker guidance then you will end up with something like a Dockerfile next to the csproj of your app. However, this falls over as soon as you want a second csproj to form part of your solution. A class library or test project that runs in the build container are other common examples of where you need a solution context instead of a project one.

The way to handle this scenario is to:

1. re-write the paths in your Dockerfile to assume that they are copying from the sln directory rather than a project one.
2. Either run docker build <path to sln dir possible ../../> or move the Dockerfile to your sln directory and run build as normal. The . used in docker build . is the location of the build context that is sent to the Docker engine as the files that can be copied when building. By doing this you will have the entire solution to access and your Blazor build should work fine and be able to be copied as you need.

Does that all make sense? If you look at the way that Visual Studio works it will create a Dockerfile like this but when it is built it passes the sln directory as the build context. I think I have a preference for moving the Dockerfile to the sln dir, but either should work.