Integrating a traditional ASP.NET website with WASM client

[SerratedSharp]

After trying alot of different options over the last couple years, I thought I'd share what I've settled on as a setup that integrates a WASM client with a traditional ASP.NET website, such as a ASP.NET MVC site. This would be a setup for someone wanting to build a traditional website, but use WASM in lieu of javascript for client side UI logic.

Three projects:

• .NET Console App "WasmClient"
• ASP.NET Core Web App (Model-View-Controller)
• Class Library "ClientShared" (to hold classes shared by the WASM client and MVC host such as client API models used when calling JSON endpoints from WASM client to MVC host).

Console app references Uno.Wasm.Bootstrap, *.DevServer, "ClientShared" Class library,
MVC app references "ClientShared" Class library.

Make sure the console app has a Properties/launchSettings.json, but set launchBrowser: false and inspectUri is not needed.

Edit the MVC project's launchSettings.json, change the inspectUri's domain to point to the localhost:port of the WasmClient. I.e. if the WasmClient's "applicationUrl": "https://localhost:44444;http://localhost:44445" then set the MVC project's launchSetting's inspectUri to:
"inspectUri": "https://localhost:44444/_framework/debug/ws-proxy?browser={browserInspectUri}"

Right click the solution and Configure Startup Projects. Set both the MVC and the WasmClient projects as startup projects. We will launch two web hosts for our dev environment locally.

In MVC's _Layout.cshtml add <div id="uno-body"></div> and <script src="https://localhost: 44444/embedded.js"></script> just before the RenderSectionAsync at the bottom.

Configure the WasmClient csproj with <WasmShellMode>BrowserEmbedded</WasmShellMode>

• So what's gonna happen when we run the solution is we'll get two console apps, one hosting the ASP.NET MVC app, and one self hosting the Bootstrap DevServer that serves the static WASM modules but also listens for debugging connection.
• Only one browser will launch which will request the root of the ASP.NET MVC app and load its homepage, which will in turn load the embedded.js which is served from the second WasmClient host.
• The key part here is because we repointed the inspectUri of the MVC app to the WasmClient host, then debugging/breakpoints in the WasmClient will work successfully when interacting with the browser launched by the MVC project(assuming all the other requisite Wasm settings are flipped).

We disable launchBrowser on the WASM client because having two browsers launch and connect debuggers will consume the server's websocket needed for debugging on one and not allow the other to connect and throw errors.

It's pretty fun seeing for instance my C# event handler's breakpoint getting triggered on each keystroke of a HTML DOM input event.

Of course once deploying anywhere beyond local dev, then the /package_ artifacts can be copied into the MVC wwwroot, static mime types set, and change the embedded.js reference to just be a relative URL to root or whatever subpath the WASM module is in: <script src="embedded.js"></script>, so that in test/prod you just need a single host.

I glazed over some details, but I am working on cleaning up more thorough documentation and an updated sample using this approach, which I'll link to once complete. Any feedback appreciated.

[jeromelaban]

Thanks for the writeup!

In the full Uno Platform templates, we have the "server" wizard option which creates a separate project that can be hosted from a ASP.NET website. The only difference at this point is that deploying this way will not enable debugging (the debgugger startup needs to be routed differently and it's not enabled yet).