[Feature] New Integration: Legacy ASP.NET/IIS Express

[Sebbs128]

Keeping in line with the contribution guidelines, here's a proposal for a new feature integration: support for legacy ASP.NET (.NET Framework).

There has been previous discussions in the dotnet/aspire repo (eg. dotnet/aspire#4842 and dotnet/aspire#4984) about adding support for ASP.NET (and/or .NET Framework) in Aspire. However, Microsoft's/the Aspire team's position is (understandably) that they don't want to support it, and any integration for it should be a community effort or project.

The Aspire Community Toolkit seems like it should be a good home for such an integration.

Why would/do developers want this?

Speaking for myself, for those of us on the ASP.NET->ASP.NET Core migration path (using the incremental approach), the developer inner loop can be a bit rough. For a simpler solution of a database, web api, and frontend web app, config already gets a bit more complex (db conn string, web api URL, plus the legacy web projects now being proxied by the aspnetcore projects). And we now have four projects we need to ensure Visual Studio starts. (Side note: glad to see the improved "multiple startup projects" UI appears to have made a return in the latest VS 2022 release).

I think it would be great if we could make this part of the developer inner loop easier, which in essence is a goal of Aspire as well.

Existing POCs

Some of us have working proof of concepts of orchestrating ASP.NET with Aspire that can form the basis of this integration. I have one at https://github.com/Sebbs128/AspireNetFramework, and I know CZEMacleod has one at https://github.com/CZEMacLeod/C3D.Extensions.Aspire.IISExpress, based on her MSBuild.SDK.SystemWeb project SDK

Areas needing help

We've both had difficulties with getting the debugger attached automatically (this might be something the new Events in Aspire 9 helps with, if attaching the debugger can be driven from the AppHost), and a bit more work is likely needed for telemetry/diagnostics, health checks, and service discovery.

Provisioning and Publishing might have to be left off the table, I'm not sure...

For those of us in Azure with existing ASP.NET apps, we're likely publishing directly to an App Service, or a Windows Container that runs in App Service (Windows containers apparently also work in AKS, but aren't on the roadmap for Azure Container Apps). Bicep resource definitions exist for these, and azd seems to support [publishing to app services](https://github.com/[Azure-Samples/quickstart-deploy-aspnet-core-app-service](https://github.com/Azure-Samples/quickstart-deploy-aspnet-core-app-service), however that sample is for ASP.NET Core, and I'm uncertain (leaning towards the side of "no") Aspire could tie it in anyway. Teams with ASP.NET apps likely have existing deployment pipelines anyway, which they could continue to use.

[aaronpowell]

I've been ponding on this since you raised the issue and having a look at the attached references, and there's a couple of aspects of the topic that I'll try to respond to, but I'll do so in reverse order.

Deployment

You're right in that azd supports deploying to AppService, and while Aspire uses azd for deployments, it has an opinionated structure as to what your deployment options are. The focus of Aspire for deployment to Azure is containerised workloads, focusing on Azure Container Apps as the hosting model.

But you can always bypass this, either partially or wholly. If you already have a deployment process, there's no need to adopt Aspire for deployments to Azure, stick with what's already working (and that includes if you were already deploying to ACA). Alternatively, you can use azd to deploy but if you had something targeting a compute resource that isn't ACA, you would exclude that from the generated Aspire manifest and can add it as a service in the azd azure.yaml file, deploying that way.

Adding additional deployment resource types is beyond the scope of what we can handle in the Community Toolkit.

Debugging

I agree on the value of being able to debug the application launched by the app host, but this also falls into an area that we can't solve in the Community Toolkit - I actually have zero idea on where you'd even start with that!

We see this same problem with other runtimes, like Node.js, Python, etc.

Hosting integration

As you've noted, there's a couple of attempted to create hosting integrations for IIS Express projects, and they both appear to have their challenges, mostly due to how IIS Express is designed and orchestrated.

Ultimately though, I feel like the Community Toolkit is ill suited as a home for this integration. It would require some major changes to the infrastructure of the repo, for example, we heavily rely on Linux as our CI platform (it's where the NuGet packages are generated), which would not be possible with the introduction of something that is tied to .NET Framework (and by extension, Windows). Our recommended dev environment is Linux too, as we have a devcontainer that sets up all dependencies. again something that would cause issues.

But then there are the different models between .NET and .NET Framework for things like config management, how would you pass references and have them mapped? People wouldn't be setup for success when it comes to client integrations, as they are not supported on .NET Framework so there's a lot of additional overhead required to achieve an optimal inner loop.

I would encourage investment in the existing approaches, because I don't believe that the Community Toolkit would be the right fit for the integration.

[Sebbs128]

Thanks for the feedback Aaron 😊

On deployment, that was pretty much the conclusion I'd come to; anyone deploying ASP.NET to Azure likely already has an existing deployment process. And notably the Azure Static Web Apps integration in the Community Toolkit doesn't support deployment either. It's good to know azd can still handle it separately from the Aspire manifest though.

Debugging is definitely a tough nut to crack, if automating attachment of the debugger is even possible. As you say, there's precedent for Aspire not attaching a debugger for certain official Aspire integrations like Node.js and Python, so while it would be nice to figure out it's not that big a deal if the debugger doesn't automatically attach for this case (and luckily, Debug->Attach to Process in Visual Studio does still work).

The only part in CI that would require .NET Framework (and thus Windows) is the client integration; the hosting package itself is still .NET 8/9, and it can skip the resource work on non-Windows via an OS check at runtime. The current dotnet-*.yml workflows look like they're currently including Windows, and adding a condition to only run the step to build that client package in the Windows runner isn't difficult. But maybe there's something I've missed in my admittedly brief look.

Regarding config management, my current proof of concept makes use of the EnvironmentConfigBuilder in the web.config to make references passed from the AppHost available in ConfigurationManager, and some extension methods to do some light service discovery. However, the service discovery part could be moved into a config builder that extends EnvironmentConfigBuilder, so the extension methods (and modifications to existing code to use them) would no longer required. Nuget packages are capable of automatically adding the config builder to the web.config using config file transformations which will simplify that stage for developers adding the client integration as well.

Overall though, despite my arguments for those concerns we can solve, if you feel it's not a good fit for the Community Toolkit then that's fair enough. I certainly appreciate the time you spent mulling it over and your feedback 😊

[aaronpowell]

Finally back after a few weeks of conferences and again as I read over this I'm going to close it. While I agree that there are challenges faced by organisations that are taking an incremental migration to ASP.NET Core/.NET from .NET Framework, the complexities that would be required in building and maintaining this integration are beyond what we'd be capable of doing in the Community Toolkit.

I'd encourage you to drive this through the integration you've already spiked out (or the other one you mentioned, perhaps combining the two). Do take inspiration from the model we have here in the Community Toolkit, if it makes sense.

[CZEMacLeod]

For reference - the major issue of ensuring the debugger attaches to IIS Express is resolved in my latest version of https://github.com/CZEMacLeod/C3D.Extensions.Aspire.IISExpress

This is still fairly MVP - but it does work with SystemWebAdapters, EF6 using MDS, OTEL, etc. and provides a fairly complete coverage of the major scenarios.

I've done some code cleanup - but think that maybe some default behaviours need to change based on the latest work.