Would using an external ServiceCollection be possible?

[willdean]

Justification

We have a number of applications where it is useful to serve the same UI both locally and remotely. (e.g. equipment with touch-panel displays which can also be used remotely)

At present we tend to do this by running a web server and then using a full-screen browser locally to render a local copy of the UI. This is invariably a pain - all the browser kiosk modes are crapulous to some degree, and multi-monitor support is particularly grim.

So the BlazorDesktop stuff would be great for us - we could render the UI into WebWindow on the local machine, and serve exactly the same server-side Blazor experience remotely via ASP.Net/Kestrel.

Issue

I played around with this "local + web" idea with the WinForms BlazorDesktop demo a couple of weeks ago, and it wasn't very difficult to get working, but there's one fly in the ointment, which is that the all-in-one ComponentsDesktop.Run method creates its own ServiceCollection, which is a different collection to the one which ASP.Net creates in WebHostBuilder. This means that DI'd state is not shared between the local and remote UI, which would be a bit sad in real life (one would need to create some other mechanism for sharing state).

How sensible would it be to refactor ComponentsDesktop so that it could (optionally, of course) be called with a pre-existing ServiceCollection, so that 'local' (WebWindow) and 'remote' (ASP.Net / Server-side Blazor) worlds could share a DI container?

I have had a go at this and it's quite a significant change because of the relationship between the service collection build and the window initialisation - I guess I'm just trying to see if anyone else thinks this is in the slightest bit worthwhile, or if I could perhaps promote a slightly more modular design of ComponentsDesktop.

[jimbuck]

As a work-around, have you tried just using the Blazor apps to hit the 'remote' URL? Skip the built-in Blazor integration and just build it as a thin-client that just hits the same URL as remote. That it way it keeps the same ServiceCollection. I've used that approach with Electron, but it does require two running processes (one server and one client).

If you need to the keep it to one process (open WebWindow and start Kestrel server) then you might have a point. I haven't played with this yet, but that will be my first experiment!

[willdean]

@jimbuck I would much prefer a single-process solution. But now you've made me think about it, I guess there's no particular reason (probably some minor perf stuff) not to just have the built-in webview connect to a URL which is served by Kestrel in the same process.

It is so long since there's been a useful WebView on Windows (if there ever was) that I am not used to thinking about the possibilities.

[SteveSandersonMS]

I think @jimbuck's solution is great - much simpler. I'll close this because it doesn't seem like there's a mainstream need for a different feature.