.NET Aspire solutions can't build when their projects are in folders with source trees inclusive of other Aspire App Host/Defaults projects

[bradygaster]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The summary of this issue is that .NET projects that have already been orchestrated with Aspire can't be included in subsequent solutions orchestrated with Aspire unless the solution's App Host and Defaults projects are deleted or the project-to-be-included is moved into another directory. Whilst an edge case, this issue could be a manifestation of the "multi-repo scenario," or any multi-developer scenario in which:

1. one developer is primarily responsible for the orchestration (thus, the App Host and Defaults projects) and other developers build node projects (APIs, front end web apps, and so forth)
2. individual developers work on individual node projects without much consideration beyond their individual nodes for what's included in the App Host or Defaults projects, and they worry about it later during an integration phase of their release process

Expected Behavior

When a developer is working on a .NET Aspire solution and they add a project to the solution that's in another .NET Aspire solution, the project references to the Defaults project is updated appropriately following orchestration and everything builds and runs once the project has been orchestrated into the destination .NET Aspire solution.

Steps To Reproduce

This repro takes a Visual Studio approach, but the build exception is resident when replicating this process via the command line, too.

1. Create a new Aspire Starter App named DestinationApp at [for example] c:\src\TheApp\DestinationApp\DestinationApp.sln in a new instance of Visual Studio

2. Create a new Empter Aspire App named NewIncomingAppNode at [given example in step 1]: c:\src\TheApp\NewIncomingAppNode\NewIncomingAppNode.csproj in a second instance of Visual Studio

3. Add a new Web Api project named TheApi to the NewIncomingAppNode solution

4. Close the NewIncomingAppNode solution and go back to the DestinationApp solution's instance of Visual Studio

5. Add the TheApi project to the DestinationApp solution via the "Add -> Existing Project" menu in Visual Studio

6. Right-click TheApi project and "Add Aspire Orchestration" and note VS tells you it's going to use the App Host and Defaults project in the existing solution

7. Note the TheApi project has been added to the App Host project's Program.cs

8. You may need to edit the TheApi.csproj file if both Defaults projects have been added. You'd need to change:

   <ItemGroup>
     <ProjectReference Include="..\..\Destination\Destination\Destination.ServiceDefaults\Destination.ServiceDefaults.csproj" />
     <ProjectReference Include="..\NewIncomingAppNode.ServiceDefaults\NewIncomingAppNode.ServiceDefaults.csproj" />
   </ItemGroup>
   

   into:

   <ItemGroup>
     <ProjectReference Include="..\..\Destination\Destination\Destination.ServiceDefaults\Destination.ServiceDefaults.csproj" />
   </ItemGroup>
   

9. F5 the solution

Exceptions (if any)

Metadata file 'C:\src\TheApp\NewIncomingAppNode\NewIncomingAppNode.ServiceDefaults\obj\Debug\net9.0\ref\NewIncomingAppNode.ServiceDefaults.dll' could not be found

.NET Version info

.NET SDK:
 Version:           9.0.200-preview.0.24611.4
 Commit:            6d67e2a457
 Workload version:  9.0.200-manifests.6448c051
 MSBuild version:   17.13.0-preview-24569-04+8f6b8ad0a

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.200-preview.0.24611.4\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.13.35707.81, VS 17.13.35617.110
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  9.0.200-preview.0.24575.35 [C:\Program Files\dotnet\sdk]
  9.0.200-preview.0.24611.4 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Anything else?

To work around this issue, go to the C:\src\TheApp\NewIncomingAppNode folder and delete the App Host and Defaults projects. Then, rebuilding/running the Destination solution works. This is sub-optimal, as a developer working on the incoming app might prefer to work on their app in an isolated manner; they may have tests set up already, custom code in their App Host they're not finished testing, or anything else.