Running a .NET project using `AddProject` with the csproj path fails if the project has not been previously built

[asimmon]

I'm really glad that Preview 2 of Aspire added the AddProject overload so we can reference a .NET project by providing an arbitrary project path. However, I feel like Aspire currently assumes that this project is part of (and referenced by) the app host solution, which would result in the project being built before being orchestrated by Aspire. If my project is not part of the app host solution and it has not been compiled yet, Aspire will fail to run it as it uses --no-build when preparing the projects.

In my opinion, this process somewhat defeats the purpose of using AddProject with a custom path because if my project is already part of my solution, I would simply use AddProject<> with the generated service metadata.

Is there any plan to consider building the .NET project prior to running it when using AddProject with a custom path? I believe this overload would be beneficial for scenarios where developers deal with multiple solutions in a monorepo (or even multiple repos).

[davidfowl]

Yes I think we should enable this. But you also want debugging inside of the IDE as well right?

[asimmon]

Yes, that would be great, although I'm not sure about the specifics of the experience. For now, building the project before running it would be enough.

When thinking about the debugging experience in .NET Aspire, I consider the possibility of instructing my app host code to attach the debugger to a specific resource right at its startup. On another note, I also think about a way to interact with the dashboard to manually attach to a process as needed. For now, I can already copy the process ID and manually attach to it from the IDE.

I remember that Tye uses a host startup hook to attach the debugger to the process at startup. But that's only valid for .NET apps.

[davidfowl]

Following up with some conversations the team has had about this topic. The solution we propose is building the project from the app host if it isn't part of the solution and adding support for attaching to arbitrary processes within VS. We think that combination of fixes will address this gap.

[DamianEdwards]

The solution we propose is building the project from the app host if it isn't part of the solution

Curious, how do we know that? Are we just assuming if the project is added via a .csproj path then it's not part of the solution and will try to build it, or do we have a more concrete signal? I'm concerned what will happen if we try to kick off a build of a project that's already being managed by VS.

[davidfowl]

I think that’s what we’d do. If it’s not added as a reference to the apphost then we build it. Not sure what else we can glean.

[rem-coding]

I know #1486 has been closed, as thought this was fixed for preview 5. But seems there's a potential regression in preview 6. Using the same example as previous with the AspireStarter template and changing to AddProject by path and removing appservice from the solution it fails as per the below screenshot. Works fine from the command line with dotnet run, but not from Visual Studio.