Using IDE session endpoint requests outside of Aspire

[epsitec]

We've been experimenting with Aspire and found that the DEBUG_SESSION_PORT and DEBUG_SESSION_TOKEN environment variables would be very helpful in our own code, in order to help debugging a multi-project solution. Specifically, we'd like to use the Visual Studio IDE-execution API described here, without having to include Aspire.Hosting .

Somehow, adding <IsAspireHost>true</IsAspireHost> does some magic behind the scenes, which makes Visual Studio provide both DEBUG_SESSION_PORT and DEBUG_SESSION_TOKEN environment variables. How can we trigger the same behavior, without setting <IsAspireHost> in the *.csproj?

[davidfowl]

How are you launching multiple projects in the first place?

cc @BillHiebert @karolz-ms

[epsitec]

We've been using two approaches up to now, none being really satisfying.

• Visual Studio's Configure Startup Projects helps in solutions where projects can be launched independently one from another; we have to cheat if there are dependencies and hardwire the arguments. For our current scenario, this is not ideal, since we have to predefine the ports on which the various processes operate and can't use the dynamic port allocation used in production, and we have to add delays when starting some projects, replace Process.Start() with dummy code in our orchestrator, etc.
• Starting only the main project from Visual Studio, then attaching afterwards to the other processes, either manually through Debug > Attach to process, or by adding calls to Debugger.Break() in every Program.cs. But this is not really satisfying...

After discovering Aspire's use of the IDE-Execution API (and DEBUG_SESSION_PORT + DEBUG_SESSION_TOKEN) we've used it to launch child processes by asking the IDE to start their associated .csproj file. However, this only works when Aspire's magic kicks in (<IsAspireHost>true</IsAspireHost>). We don't want to include Aspire itself into our solution (please assume we have some valid reason for this ;-) or else I wouldn't have to ask). Removing the project reference on Aspire seems to have unexpected side effects, such as the fact that referenced assemblies no longer get properly referenced (missing references). I suppose this has something to do with how the Aspire SDK rewires the build process to generate the dependencies and manifests.

Basically, I'd be very happy to be able to have Visual Studio start my main project without Aspire, while still making its IDE-Execution API available to it. Is this possible? What is the trick which makes Visual Studio activate this feature?

[davidfowl]

So you’re building your own orchestrator/launcher and you want to hook into the debugger the same way aspire does?

You probably need this project capability to begin with. I think this is what makes VS launch with the debug session token and port. Then you have to implement the protocol.

The project capability is here:

aspire/src/Aspire.Hosting.Sdk/SDK/Sdk.targets

Line 12 in ceae04d

<ProjectCapability Include="AspireOrchestration" />

The protocol is here

https://github.com/dotnet/aspire/blob/main/docs/specs/IDE-execution.md

Hope that helps

[epsitec]

Switching from:

<ProperyGroup>
  <NoWarn>ASPIRE002</NoWarn>
  <IsAspireHost>ture</IsAspireHost>
</PropertyGroup>

to

<ItemGroup>
  <ProjectCapability Include="AspireOrchestration" />
</ItemGroup>

did indeed solve my issues.

• Starting the main project indeed injects the DEBUG_SESSION_... environment variables.
• Project references through <ProjectReference Include="..."/> work as expected.

Thank you very much!

[davidfowl]

No problem!