Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove DCP and Dashboard from the .NET Aspire SDK Workload #4708

Merged
merged 25 commits into from
Aug 22, 2024
Merged
Show file tree
Hide file tree
Changes from 23 commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
e73ec3d
WIP: Switch from workload to instead be MSBuild SDKs for Aspire
joperezr May 22, 2024
ed4ec96
Change Dashboard to be a NuGet package dependency
joperezr Jun 26, 2024
8667f40
Bring back Aspire.Hosting.Sdk into the workload for P2P references
joperezr Jun 26, 2024
743ba94
Change DCP to be a NuGet package dependency
joperezr Jun 27, 2024
8c3a92b
Add proposal doc for the .NET Aspire Workload
joperezr Jun 27, 2024
c040418
Merge branch 'main' into workloads/MSBuildSDKs
joperezr Aug 7, 2024
6c84434
WIP
joperezr Aug 7, 2024
4b604ab
Onboarding into CPM
joperezr Aug 8, 2024
fd82056
Playground applications building and running
joperezr Aug 8, 2024
aa5ae81
Test projects building
joperezr Aug 8, 2024
015bd6b
Fix failing MSBuild test
joperezr Aug 8, 2024
1a0b6a9
Produce 8.2.0 versions and add error in case of insufficient AppHost …
joperezr Aug 9, 2024
ccf0468
Add error when insufficient version of workload is detected.
joperezr Aug 9, 2024
d5036f4
Fix build breaks due to new Error
joperezr Aug 12, 2024
3ec11e5
Fix msbuild test
joperezr Aug 12, 2024
bbfe505
Only skip Dashboard and DCP references when not running outside of repo
joperezr Aug 16, 2024
f52a55a
Merge branch main
joperezr Aug 16, 2024
928ede4
Fix minimum SDK error on Playground tests when running out of repo
joperezr Aug 16, 2024
c3cdb9b
Fix DCP path on Aspire.Hosting.*.Tests
joperezr Aug 16, 2024
bd4ea6f
WIP: Test dcp path
joperezr Aug 20, 2024
207d4a9
Fix Workload failing tests
joperezr Aug 20, 2024
7c48160
Fixing up docs, addressing feedback and final cleanup.
joperezr Aug 21, 2024
a5479c9
Adding Workload test for CPM validation
joperezr Aug 21, 2024
54340cf
Address PR feedback
joperezr Aug 22, 2024
063472a
Make items private
joperezr Aug 22, 2024
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/specs/future-of-workload.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# Design proposal for the .NET Aspire workload going forward
joperezr marked this conversation as resolved.
Show resolved Hide resolved

.NET Aspire currently ships as a .NET SDK Workload. This workload currently includes the following components:

- Aspire.Hosting.SDK (MSBuild SDK): This SDK contains some props and targets with the required logic to properly handle `ProjectReferences` in the .NET Aspire AppHost projects, which then drives the source generation that allows the AppHost project to have strongly typed references to project resources. This component cannot be changed into a regular NuGet package, as the logic it carries neeeds to be executed before the initial restore.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Aspire.Hosting.SDK (MSBuild SDK): This SDK contains some props and targets with the required logic to properly handle `ProjectReferences` in the .NET Aspire AppHost projects, which then drives the source generation that allows the AppHost project to have strongly typed references to project resources. This component cannot be changed into a regular NuGet package, as the logic it carries neeeds to be executed before the initial restore.
- Aspire.Hosting.SDK (MSBuild SDK): This SDK contains some props and targets with the required logic to properly handle `ProjectReferences` in the .NET Aspire AppHost projects. This component cannot be changed into a regular NuGet package, as the logic it carries neeeds to be executed before the initial restore.

This bit makes it sound like the source generation comes from this SDK, but it doesn't. I would just drop it to avoid confusion.

- Aspire.ProjectTemplates (.NET Template Pack): This is a set of project templates that allow users to create new .NET Aspire projects using `dotnet new` commands and Visual Studio "New Project" dialog.
- Aspire.Hosting.Orchestration (MSBuild SDK): This SDK contains two main things: the Developer Control Plane executable (DCP) as well as a targets file which defines properties for the AppHost to be able to find the DCP executable and run it.
- Aspire.Dashboard.SDK (MSBuild SDK): Similar to the Orchestration SDK, this one provides the .NET Aspire Dashboard application (self-contained app that depends on .NET 8 runtime) and the targets file that defines properties for the AppHost to be able to find the Dashboard executable and launch it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Aspire.Dashboard.SDK (MSBuild SDK): Similar to the Orchestration SDK, this one provides the .NET Aspire Dashboard application (self-contained app that depends on .NET 8 runtime) and the targets file that defines properties for the AppHost to be able to find the Dashboard executable and launch it.
- Aspire.Dashboard.SDK (MSBuild SDK): Similar to the Orchestration SDK, this one provides the .NET Aspire Dashboard application (a framework-dependent app that depends on .NET 8 runtime) and the targets file that defines properties for the AppHost to be able to find the Dashboard executable and launch it.

This isn't a self-contained app.

- Aspire.Hosting (Regular NuGet Library): This package isn't really required to be in the workload, as this is a PackageReference that all AppHost projects will have. The advantage that we get currently from having it in the workload is that this would install it into the global NuGet cache when the workload is installed, so that the AppHost projects can find it without needing to restore it from the NuGet feed. This is helpful especially for offline scenarios. The package itself provides the Aspire.Hosting library which contains all of the main logic in Aspire for building and running .NET Aspire applications.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Aspire.Hosting (Regular NuGet Library): This package isn't really required to be in the workload, as this is a PackageReference that all AppHost projects will have. The advantage that we get currently from having it in the workload is that this would install it into the global NuGet cache when the workload is installed, so that the AppHost projects can find it without needing to restore it from the NuGet feed. This is helpful especially for offline scenarios. The package itself provides the Aspire.Hosting library which contains all of the main logic in Aspire for building and running .NET Aspire applications.
- Aspire.Hosting.AppHost (Regular NuGet Library): This package isn't really required to be in the workload, as this is a PackageReference that all AppHost projects will have. The advantage that we get currently from having it in the workload is that this would install it into the global NuGet cache when the workload is installed, so that the AppHost projects can find it without needing to restore it from the NuGet feed. This is helpful especially for offline scenarios. The package itself provides the Aspire.Hosting library which contains all of the main logic in Aspire for building and running .NET Aspire applications.

The Aspire.Hosting.AppHost is the nuget package that is referenced by all AppHost projects. It has a dependency on Aspire.Hosting.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did actually mean Aspire.Hosting as that is the one that we had in the workload, but the wording is wrong here I agree, so I'll fix that.

joperezr marked this conversation as resolved.
Show resolved Hide resolved

## Problem statement

The current design of the workload has led to some usability issues, and after a lot of deep analysis, we finally understand what is the root cause of these issues. SDK Workloads are meant to be used for tooling components, which lifetime should be tied to the lifetime of the SDK itself. When we were originally designing the workload, we believed that both DCP and Dashboard were tooling components, and that they should be installed as part of the workload. However, we have come to realize that this is not the case. DCP and Dashboard are tightly coupled to the version of Aspire.Hosting package that the AppHost project references, and therefore are part of the AppHost itself, as opposed to tooling that supports it. This is the root cause of the issues that we have seen with the workload, such as the need to ensure that the version of the workload installed matches the project reference of Aspire.Hosting, which is also a problem when trying to work with multiple Aspire projects that reference different versions of Aspire.Hosting. SDK typically makes the assumption that customers want to always be in the latest version of all of the workloads, which is likely the right thing to do for tooling components; however, this is a problem for .NET Aspire given the tight coupling between the AppHost and the DCP/Dashboard.

## Proposed solution

Given the above, we propose to move the DCP and Dashboard components out of the workload, and into NuGet packages that are dynamically referenced by the Aspire.Hosting.SDK. This will allow the AppHost project to reference the version of Aspire.Hosting that it wants, and then the DCP and Dashboard will be referenced automatically by the Aspire SDK as dependencies of that version of Aspire.Hosting. This will allow the AppHost project to have full control over the version of the DCP and Dashboard that it wants to use, and will also allow customers to have multiple AppHost projects that reference different versions of Aspire.Hosting without any issues. This will also allow us to update the DCP and Dashboard independently of the workload, which will allow us to ship updates to these components more frequently and with less risk, with a far less complex compatibility matrix.

Also, there is no real need of including the Aspire.Hosting package as part of the workload, as there is no guarantee that this is the version that the AppHost project will want to use, therefore we would also remove this package from the workload. In the end, the workload will only contain the Aspire.Hosting.SDK and Aspire.ProjectTemplates components, which are the ones that can be truly considered as tooling components, and in both cases you would want to always be in the latest version. These two are also not tightly coupled to the version of the Aspire.Hosting package that the AppHost project references, so they can be updated independently of the AppHost.
joperezr marked this conversation as resolved.
Show resolved Hide resolved

### Pros

This proposal has many benefits which will solve the issues we currently have with the workload:

- The AppHost project will have full control over the version of the DCP and Dashboard that it wants to use.
- Customers can have multiple AppHost projects that reference different versions of Aspire.Hosting without any issues.
- We can update the DCP and Dashboard independently of the workload, which will allow us to ship updates to these components more frequently and with less risk.
- Customers can stay in the latest version of the workload without worrying about compatibility issues with the AppHost project.
- Because Aspire.Hosting.SDK targets get imported before the initial restore, we can still have the same experience as before, where the AppHost project will end up restoring only the DCP and Dashboard packages for the platform that is being targeted, as opposed to needing to restore them for all platforms.

### Cons

- Workloads have a way of keeping a reference count on workload packs, so it is able to clean them up when workloads don't reference it any more (for example, if you update your workload, then the old DCP package will be cleaned up automatically). This doesn't happen with regular NuGet packages, where customers are responsible for cleaning up their NuGet package caches themselves.
4 changes: 3 additions & 1 deletion eng/Build.props
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
<Project>
<ItemGroup Condition="'$(DotNetBuildFromSource)' != 'true' and '$(DotNetBuild)' != 'true'">
<ProjectToBuild Include="$(RepoRoot)src\**\*.csproj" Exclude="$(RepoRoot)src\Aspire.ProjectTemplates\templates\**\*.csproj" />
<ProjectToBuild Include="$(RepoRoot)tests\**\*.csproj" />
<ProjectToBuild Include="$(RepoRoot)eng\dcppack\**\*.csproj" Exclude="$(RepoRoot)src\Aspire.ProjectTemplates\templates\**\*.csproj" />
<ProjectToBuild Include="$(RepoRoot)eng\dashboardpack\**\*.csproj" Exclude="$(RepoRoot)src\Aspire.ProjectTemplates\templates\**\*.csproj" />
joperezr marked this conversation as resolved.
Show resolved Hide resolved
joperezr marked this conversation as resolved.
Show resolved Hide resolved
<ProjectToBuild Include="$(RepoRoot)playground\**\*.csproj" />
<ProjectToBuild Include="$(RepoRoot)tests\**\*.csproj" />
</ItemGroup>
<!-- If we are building for SourceBuild, then we only want to build the Aspire manifest package -->
<ItemGroup Condition="'$(DotNetBuildFromSource)' == 'true' or '$(DotNetBuild)' == 'true'">
Expand Down
6 changes: 3 additions & 3 deletions eng/Versions.props
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@
<PropertyGroup>
<!-- This repo version -->
<MajorVersion>8</MajorVersion>
<MinorVersion>1</MinorVersion>
<PatchVersion>1</PatchVersion>
<VersionPrefix>8.1.1</VersionPrefix>
<MinorVersion>2</MinorVersion>
<PatchVersion>0</PatchVersion>
<VersionPrefix>8.2.0</VersionPrefix>
<PreReleaseVersionLabel>preview.1</PreReleaseVersionLabel>
<!--
When running package validation as part of the build, we want to ensure we didn't break the API against the previous
Expand Down
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.linux-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we creating all these RID specific packages for the Dashboard just so we can get RID specific app hosts? 99% of the nuget package is identical. The only difference is the executable that launches the app?

Could we make it more like a .NET global tool and only have to ship 1 nuget package?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, I believe. We actually no longer need to have all of these separate projects anymore, so in a follow up PR I am going to explore how to reduce and simplify this.

<PropertyGroup>
<DashboardRuntime>linux-arm64</DashboardRuntime>
<DashboardPlatformType>Unix</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.linux-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>linux-x64</DashboardRuntime>
<DashboardPlatformType>Unix</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.osx-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>osx-arm64</DashboardRuntime>
<DashboardPlatformType>Unix</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.osx-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>osx-x64</DashboardRuntime>
<DashboardPlatformType>Unix</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.win-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>win-arm64</DashboardRuntime>
<DashboardPlatformType>Windows</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.win-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>win-x64</DashboardRuntime>
<DashboardPlatformType>Windows</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dashboardpack/Aspire.Dashboard.Sdk.win-x86.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DashboardRuntime>win-x86</DashboardRuntime>
<DashboardPlatformType>Windows</DashboardPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
65 changes: 65 additions & 0 deletions eng/dashboardpack/Common.projitems
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
<Project>
<Import Sdk="Microsoft.NET.Sdk" Project="Sdk.props" />

<Import Project="$(SharedDir)Workload.targets" />

<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<IsPackable>true</IsPackable>
<!-- Unset PackageType as that is being set by Workload.targets to DotnetPlatform, which this package no longer is. -->
<PackageType />
<SuppressDependenciesWhenPacking>true</SuppressDependenciesWhenPacking>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<IncludeBuildOutput>false</IncludeBuildOutput>
<PackageOutputPath Condition=" '$(PackageOutputPath)' == '' ">$(ArtifactsShippingPackagesDir)</PackageOutputPath>
</PropertyGroup>

<PropertyGroup>
<Description>Dashboard browser interface for .NET Aspire.</Description>
</PropertyGroup>

<ItemGroup>
<TextReplacementValue Include="PlatformRuntime" NewValue="$(DashboardRuntime)" />
<TextReplacementValue Include="PackageName" NewValue="$(AssemblyName)" />
</ItemGroup>

<ItemGroup>
<None Include="build*/*.props;**/*.targets" Pack="true" PerformTextReplacement="true" PackagePath="%(RecursiveDir)$(AssemblyName)%(Extension)" />
</ItemGroup>

<Import Sdk="Microsoft.NET.Sdk" Project="Sdk.targets" />

<Target Name="Build" />


<Target Name="BeforeBuild" BeforeTargets="Build">
<MSBuild Projects="../../src/Aspire.Dashboard/Aspire.Dashboard.csproj" Targets="publish"
Properties="Configuration=$(Configuration);Platform=$(Platform);TargetFramework=$(TargetFramework);RuntimeIdentifier=$(DashboardRuntime);PlatformName=$(DashboardRuntime)" />

<!-- After publishing the project, we ensure that the published assets get packed in the nuspec. -->
<ItemGroup>
<_PublishItems
Include="$(DotNetOutputPath)Aspire.Dashboard/$(DashboardRuntime)/$(Configuration)/$(TargetFramework)/$(DashboardRuntime)/publish/**/*" />
<None Include="@(_PublishItems)" Pack="true" PackagePath="tools/" />
</ItemGroup>

<MakeDir Directories="$(DashboardPublishedArtifactsOutputDir)/$(DashboardRuntime)" />
<ZipDirectory
SourceDirectory="$(DotNetOutputPath)Aspire.Dashboard/$(DashboardRuntime)/$(Configuration)/$(TargetFramework)/$(DashboardRuntime)/publish"
DestinationFile="$(DashboardPublishedArtifactsOutputDir)/$(DashboardRuntime)/aspire-dashboard-$(DashboardRuntime).zip"
Overwrite="true" />

<!-- Throw an error if _PublishItems is empty. -->
<Error Condition="'@(_PublishItems)' == ''"
Text="No files were found to pack. Ensure that the project being packed has a publish target defined." />
</Target>

<ItemGroup>
<None Include="Sdk.props" Pack="true" PackagePath="build/$(AssemblyName).props" />
<None Include="Sdk.in.targets" Pack="true" PerformTextReplacement="true"
PackagePath="build/$(AssemblyName).targets" />
<None Include="UnixFilePermissions.xml" Pack="true" PackagePath="data/"
Condition=" '$(DashboardPlatformType)' == 'Unix' " />
</ItemGroup>

</Project>
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,15 @@

<!-- *** BEGIN *** -->

<PropertyGroup>
<PropertyGroup Condition="'$(NETCoreSdkRuntimeIdentifier)' == '@PlatformRuntime@'">
<AspireDashboardDir Condition=" '$(AspireDashboardDir)' == '' ">$([MSBuild]::NormalizeDirectory($(MSBuildThisFileDirectory), '..', 'tools'))</AspireDashboardDir>
<AspireDashboardDir>$([MSBuild]::EnsureTrailingSlash('$(AspireDashboardDir)'))</AspireDashboardDir>
<AspireDashboardPath Condition=" '$(AspireDashboardPath)' == '' ">$([MSBuild]::NormalizePath($(AspireDashboardDir), 'Aspire.Dashboard'))</AspireDashboardPath>
<AspireDashboardPath Condition=" '$(OS)' == 'Windows_NT' and !$(AspireDashboardPath.EndsWith('.exe')) ">$(AspireDashboardPath).exe</AspireDashboardPath>
<AspireDashboardPath Condition="$([MSBuild]::IsOsPlatform('OSX')) and !$(AspireDashboardPath.EndsWith('.dll'))">$(AspireDashboardPath).dll</AspireDashboardPath>
</PropertyGroup>

<ItemGroup>
<ItemGroup Condition="'$(NETCoreSdkRuntimeIdentifier)' == '@PlatformRuntime@'">
<ProjectCapability Include="AspireDashboard" />
</ItemGroup>

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
<Project>
<Import Project="..\build\@PackageName@.props" />
</Project>
joperezr marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
<Project>
<Import Project="..\build\@PackageName@.targets" />
</Project>
joperezr marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
<Project>
<Import Project="..\build\@PackageName@.props" />
</Project>
joperezr marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
<Project>
<Import Project="..\build\@PackageName@.targets" />
</Project>
joperezr marked this conversation as resolved.
Show resolved Hide resolved
51 changes: 0 additions & 51 deletions eng/dashboardpack/dashboardpack.csproj

This file was deleted.

Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<Project>

<PropertyGroup>
<PropertyGroup Condition="'$(NETCoreSdkRuntimeIdentifier)' == '@PlatformRuntime@'">
<DcpDir Condition=" '$(DcpDir)' == '' ">$([MSBuild]::NormalizeDirectory($(MSBuildThisFileDirectory), '..', 'tools'))</DcpDir>
<DcpDir>$([MSBuild]::EnsureTrailingSlash('$(DcpDir)'))</DcpDir>
<DcpExtensionsDir Condition=" '$(DcpExtensionsDir)' == '' ">$([MSBuild]::NormalizeDirectory($(DcpDir), 'ext'))</DcpExtensionsDir>
Expand Down
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.linux-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>linux-arm64</DcpRuntime>
<DcpPlatformType>Unix</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.linux-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>linux-x64</DcpRuntime>
<DcpPlatformType>Unix</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.osx-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>osx-arm64</DcpRuntime>
<DcpPlatformType>Unix</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.osx-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>osx-x64</DcpRuntime>
<DcpPlatformType>Unix</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
2 changes: 0 additions & 2 deletions eng/dcppack/Aspire.Hosting.Orchestration.props

This file was deleted.

9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.win-arm64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>win-arm64</DcpRuntime>
<DcpPlatformType>Windows</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.win-x64.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
<PropertyGroup>
<DcpRuntime>win-x64</DcpRuntime>
<DcpPlatformType>Windows</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
9 changes: 9 additions & 0 deletions eng/dcppack/Aspire.Hosting.Orchestration.win-x86.csproj
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
<Project>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we replace these, and the Dashboard Sdk's arch specific projects with one project, and pass in the properties of DcpRuntime, and DcpPlatformType?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we probably can now. We originally needed the individual projects because we were having P2P references from the AppHost package, beacause we needed to have a package reference. Now that those are being dynamically added by the SDK, we no longer need this. I'll try to get this done in the next day but if I can get to it I may have to punt this to a follow up PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up PR sounds perfectly reasonable for this.

<PropertyGroup>
<DcpRuntime>win-x86</DcpRuntime>
<DcpPlatformType>Windows</DcpPlatformType>
</PropertyGroup>

<Import Project="Common.projitems" />

</Project>
Loading