ASP.NET Classic Support - Revisited

[jzabroski]

First off, this looks like an amazing project/rabbit hole I found myself down on a Saturday afternoon.

Second, I found @clairernovotny 's comment here interesting (emphasis mine):

I looked into getting ASP.NET projects working with the new project system about six months ago, but was blocked by the project system itself. While I could get an ASP.NET site to compile and generate publish packages, I could not make a local run/debug experience work. From what I can tell, that requires support within the project system itself to wire up IIS Express and launch the processes the right way.

For now, I don't have a workaround. If someone comes up with a way, I'm certainly happy to incorporate it.

I'd like to unpack this comment:

1. Why does ASP.NET Classic Support require support from within the project system itself?
2. When you say the "project system", what are you referring to so that we're on the same plane of conversation?
3. What does it mean to "wire up IIS Express" and "launch the processes the right way"? Which processes need to be launched - the w3svc worker processes that host the ASP.NET AppDomain?

I'm not an expert in IIS Express, the .NET SDK Project System, or even ASP.NET. But my ignorance might just give me the gusto to try to get this working. My motivation is to be able to have Visual Studio Manage Packages window seamlessly manage my packages without me needing to describe all my transitive references.

For some background, I think launching the debugger might not be too hard: There are already Visual Studio Gallery Extensions such as AttachToAnything that automatically attach to processes by name. I have written a PowerShell binary cmdlet called Debug-Command that attaches the current pwsh.exe process to a Visual Studio instance; the only hole is that if you have multiple Visual Studio instances running, you may have to select the instance to attach to, as I could not figure out how to auto-magically do it.

CC @Nirmal4G