Support containerization of client-side webassembly applications

[baronfel]

Currently users that containerize a standard blazorwasm .NET SDK template end up with something unrunnable - because this style of application is compiled to WASM and then intended to be run from a browser, our defaults are all wrong.

We should detect (or allow the user to tell us) that they want to serve static content and then specify or infer

• an image to act as an http server
• the root to serve data from

I was able to make this work today with the busybox image, which includes an http server in it, using the following configuration:

<PropertyGroup>
  <ContainerBaseImage>localhost:5010/library/busybox:1.35</ContainerBaseImage>
</PropertyGroup>

<ItemGroup>
    <ContainerEntrypoint Include="busybox;httpd;-f;-v;-p;80;-h;./wwwroot" />
</ItemGroup>

The main annoyance is that you can't change the working directory directly to wwwroot because we copy the publish contents to the working directory by default, so the relative host directory of the app had to be changed via CLI argument.

[baronfel]

Ideally we'd be able to defer to maybe a YARP container with a trimmed YARP exe that could be configured to host simple sites, but that's still an issue that's under discussion: dotnet/yarp#247

[tmds]

because we copy the publish contents to the working directory by default

I think this behavior stems from ASP.NET which looks for some files in the working directory.

You could add an additional property that determines where the published output goes, that can be set separate from the ContainerWorkingDirectory.

Probably it makes sense to use that property as the default value of ContainerWorkingDirectory to match the ASP.NET behavior.

[baronfel]

We're not going to dig into this with any urgency, but if someone made this up and submitted a sample for docs purposes that would be lovely.

[baronfel]

In addition to blazor wasm, we should support wasi-wasm targets. This would be a very simple container, coping the built .wasm module and invoking it with wasmtime's container as the base image.

[baronfel]

Mismatched blazorwasm RIDs is currently the second-most cause of error using the SDK containers feature:

So if we wanted to reduce that error entirely we should implement this feature.

[dolejska-daniel]

Hi @baronfel, is the workaround with the custom base image still working? I can't seem to get through the container build using:

dotnet publish -p:PublishProfile="DefaultContainer"

C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018: The "CreateNewImage" task failed unexpectedly. [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018: System.NotImplementedException: CONTAINER2003: The manifest for library/busybox:1.35 from registry https://registry-1.docker.io/ was an unknown type: application/vnd.oci.image.index.v1+json. Please raise an issue at https://github.com/dotnet/sdk-container-builds/issues with this message. [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018:    at Microsoft.NET.Build.Containers.Registry.GetImageManifestAsync(String repositoryName, String reference, String runtimeIdentifier, IManifestPicker manifestPicker, CancellationToken cancellationToken) in /_/src/Containers/Microsoft.NET.Build.Containers/Registry/Registry.cs:line 194 [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018:    at Microsoft.NET.Build.Containers.Tasks.CreateNewImage.ExecuteAsync(CancellationToken cancellationToken) in /_/src/Containers/Microsoft.NET.Build.Containers/Tasks/CreateNewImage.cs:line 83 [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018:    at Microsoft.NET.Build.Containers.Tasks.CreateNewImage.Execute() in /_/src/Containers/Microsoft.NET.Build.Containers/Tasks/CreateNewImage.cs:line 36 [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Execute() [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(TaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [D:\Git\selfhosted\root\WasmTest\WasmTest\WasmTest.csproj]

with

<PropertyGroup>
    <ContainerBaseImage>docker.io/library/busybox:1.35</ContainerBaseImage>
</PropertyGroup>

<ItemGroup>
    <ContainerEntrypoint Include="busybox;httpd;-f;-v;-p;80;-h;./wwwroot" />
</ItemGroup>

[baronfel]

This is slightly different - it looks like we don't understand how to read image indexes, regardless of registry. I think this may be coming with dotnet/sdk#43085, but will need to check. If not, we will need to add read support for Image Indexes before you'd be able to use this image.

[baronfel]

dotnet/sdk#43631 will fix at least part of this. However, we still need to teach the tooling what to do with browser-wasm as a RID. There's no golang architecture that directly maps here. In the meantime, when this fix releases, you'll need to specify <ContainerRuntimeIdentifier>linux-x64</ContainerRuntimeIdentifier> (or linux-arm64, or whichever is relevant for your situation) until we have full browser-wasm support.

[lbussell]

Related: dotnet/dotnet-docker#5070