OS dependent packages update package.lock.json

KarlWindhager commented 1 month ago

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug

In our team we have developers with different operating systems. Whenever one or the other checks in their changes, the package.lock.json is updated for the os dependent Aspire packages:

Aspire.Dashboard.Sdk.osx-arm64 vs Aspire.Dashboard.Sdk.win-x64 Aspire.Hosting.Orchestration.osx-arm64 vs Aspire.Hosting.Orchestration.win-x64

It is not a big issue, but a nuisance, as it is a change file in every other commit and Pull Request.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

eerhardt commented 1 month ago

cc @joperezr @radical

joperezr commented 1 month ago

Hello @KarlWindhager, thanks for logging the issue. You are correct, the experience today of using aspire if you have RestorePackagesWithLockFile set to true in your project and you are checking this file in, is not great. This is because, as you noted, the dashboard and dcp dependencies that are brought in by the project will change based on the platform that is being used to build the project. We can take a closer look at this, but it would be hard to fix as we want to prevent forcing people to have to download dashboard and dcp for all platforms, which would be one way of fixing this.

michaelhahn-doka commented 1 month ago

Hello @joperezr! I'm also in the team of @KarlWindhager and face the same issue. We tried to reference both the win-x64 as well as the osx-arm64 versions of those packages in our apphost project file (as you mentioned that as a workaround) since it is no issue for us to download dashboard and dcp for both platforms.

Unfortunately this leads to the following issue on my mac:

System.IO.FileNotFoundException: The Aspire orchestration component is not installed at "/Users/user/.nuget/packages/aspire.hosting.orchestration.win-x64/8.2.1/tools/dcp". The application cannot be run without it.
File name: '/Users/user/.nuget/packages/aspire.hosting.orchestration.win-x64/8.2.1/tools/dcp'
   at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 50

So this means it somehow "thinks" that we are running on windows now and obviously is then using the wrong tools.

When adding the following assembly metadata attributes to my apphost project it would work theoretically:

[assembly: System.Reflection.AssemblyMetadata("dcpclipath", "path-to-osx-version-of-dcp/dcp")]
[assembly: System.Reflection.AssemblyMetadata("dcpextensionpaths", "/path-to-dcp-ext/")]
[assembly: System.Reflection.AssemblyMetadata("dcpbinpath", "/path-to-dcpbin/")]
[assembly: System.Reflection.AssemblyMetadata("aspiredashboardpath", "/path-to-aspire-dashboard/Aspire.Dashboard.dll")]

But then I have to hardcode those paths into my Program.cs which is not really a good solution.

Is there any setting that I can use so that aspire "knows" both on windows and on macos which dcp/dashboard tools to use, even though both of the packages are referenced?

joperezr commented 3 weeks ago

Hey @michaelhahn-doka, sorry for the delay in the response. Yeah, the problem you are hitting is that since you are referencing both packages, then both of the props files from each of the packages are getting loaded into your project's evaluation, and that would make it such that one would be overriding the other so it would depend on the order in which they are imported (which AFAIK is non-deterministic) whether they work or not. This is, of course, not a supported scenario.

I would not suggest setting the AssemblyMetadata attributes yourself, and instead I would probably try setting the properties drive these attributes in a targets file that gets imported late on your build that would override the ones being imported by both of the packages.

michaelhahn-doka commented 3 weeks ago

Hey @michaelhahn-doka, sorry for the delay in the response. Yeah, the problem you are hitting is that since you are referencing both packages, then both of the props files from each of the packages are getting loaded into your project's evaluation, and that would make it such that one would be overriding the other so it would depend on the order in which they are imported (which AFAIK is non-deterministic) whether they work or not. This is, of course, not a supported scenario.

I would not suggest setting the AssemblyMetadata attributes yourself, and instead I would probably try setting the properties drive these attributes in a targets file that gets imported late on your build that would override the ones being imported by both of the packages.

Thanks for your reply but how would I handle the path resolution properly since with every update of the package the path to the dcp directory as well as the dashboardpath would change, right?

dotnet / aspire