Support running composed projects in WSL

[DamianEdwards]

It should be possible to configure a composed project resource to run in WSL. We'll need to consider the integration/composition with VS support for WSL and whether we build the project in the host or in WSL itself.

[mitchdenny]

I think we should consider the Use verb as the way we handle targetting execution during local development. We already have precedent with the Azurite storage emulator support on the Azure Storage resource types. Here would be an example:

UseWsl(...)

This would ultimately result in a DCP annotation being set that makes it launch in WSL via VS. If you were already running on Linux it would be a no-op.

[DamianEdwards]

Similarly for running projects in containers support too. I do worry Use isn't clear enough as an indicator for things that target local dev only though. I don't mind the As prefix you used for the docker file support for node/npm apps, which is coupled with a suffix to make it clear that method represents transforming the resource in a specific context, e.g.:

• AsDockerFileInManifest
• AsContainerInLocalDev
• AsWslInLocalDev

A method like AsContainerInLocalDev could be a pattern that's available for lots of resource types, e.g. the various databases, Redis, RabbitMQ, etc., and neatly addresses some of the concerns with abstract resources or completely independent resources, e.g. they provide a logical place to plug in a customization method:

builder.AddPostgres("catalogdb")
    .AsContainerInLocalDev(container => container
        .WithDataVolume()
        .WithInitDb("../data/scripts/catalogdb")
        .WithEnvironment("POSTGRES_DB", "AppDb")
    );

Of course, Use is likely just as good a choice, or maybe better, once you add a context suffix, e.g. UseWslInDev arguably reads better than AsWslInDev.

[mitchdenny]

The challenge there is that AsContainerInLocalDev would need to know how to translate PostgresServerResource to ContainerResource correctly. We would need to some kind of standardized mechanism so components can opt into this behavior (e.g. IResourceSupportsContainer ... terrible name but you get the point).

There is also a question of what happens to the resource that is in the app model already. Does AsContainerInLocalDev remove it from the app model and replace it with the container resource.

What happens if you end up with code like this:

var postgres = builder.AddPostgres("catalogdb");
var app = builder.AddProject<Projects.Frontend>(...)
    .WithReference(postgres);
postgres.AsContainerInLocalDev(container => container
        .WithDataVolume()
        .WithInitDb("../data/scripts/catalogdb")
        .WithEnvironment("POSTGRES_DB", "AppDb")
);

That would probably break a bunch of callbacks. I think what we'd probably end up having to do here is have a shim resource type like this:

public class PostgresContainerResource(PostgresServerResource innerResource) : ContainerResource(innerResource.Name)
{
   // Redirect Annotations to inner resource.
}

That way all the APIs you want for container like things are there, but you are really just leveraging the fact that its the annotations that really drive all the behavior.

[DamianEdwards]

We might want more lifecycle stages to better enable resources to be mutated while the model is being built. It's not super clear to me today where the line is between things that should live directly on resources vs. be captured in annotations. I think this is one of the things we need to solidify in the app model.

[mitchdenny]

Yeah, I think this is fair. I've often thought that we need some kind of transformation mechanic.

[JulianoAlexandre]

A simple flag indicating that the project is using WSL, or reading this from the command line and running with WSL would be sufficient.

[JulianoAlexandre]

Being able to set up WSL for now would already be excellent.

[mitchdenny]

We've just added WithDockerfile. In theory if your .NET project has a Dockerfile we can build it and run it as a container in WSL. What we would be missing is attaching the debugger.

Paging in @danegsta and @BillHiebert since we've done magical things in VS in the past to support spinning up a .NET project within a container.

[maxiar]

Any News?

[mitchdenny]

It's not something we are prioritizing right now but we'll leave this open to collect feedback. We know there is some interest.

One question on this. If we were able to enable this scenario so that you could deploy to WSL as a container, but initially the debugger didn't attach - is that worthwhile? (just thinking if we could take a baby step).