dotnet / dotnet/sdk-container-builds

Support containerization of client-side webassembly applications

Open
#199 10 comments 4 reactions 0 assignees View on GitHub
Area: Task
Dominant language
No language data
Stars
197
Forks
53
PR merge metrics
No merged PRs in 30d

Description

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:

```xml

localhost:5010/library/busybox:1.35

```

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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the standard blazorwasm SDK template and trace how container publishing handles ContainerBaseImage, ContainerEntrypoint, publish contents, and the working directory. Compare that behavior with the busybox configuration in the issue; done means a client-side WebAssembly application can serve its static content from a container without manual CLI path changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
wasm
Domain
build-system
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.