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. https://github.com/dotnet/aspire/discussions/4842 and https://github.com/dotnet/aspire/issues/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.
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.
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. https://github.com/dotnet/aspire/discussions/4842 and https://github.com/dotnet/aspire/issues/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
Eventsin 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
azdseems 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.