Support deploying multiple exes as a single self-contained set

[agocke]

This is not currently supported. The closest supported deployment is publishing multiple framework-dependent apps, then setting DOTNET_ROOT before running them to use an unzipped copy of the shared framework.

Supporting this will require both runtime and SDK work to select the appropriate set of shared assemblies.

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This will require both runtime and SDK work to select the appropriate set of shared assemblies.

Author:	agocke
Assignees:	-
Labels:	area-Host, feature request
Milestone:	Future

[ThomasGoulet73]

@agocke Does this include publishing an executable projet as self-contained which itself references another executable project ?Both project should end up in the publish folder and use the same self-contained framework.

[alexrp]

This feature would be incredibly useful for projects that ship multiple small and focused command line utilities in a single release.

Bonus points if trimming can be done based on the shared assembly set.

[Symbai]

@agocke Does this include publishing an executable projet as self-contained which itself references another executable project ?Both project should end up in the publish folder and use the same self-contained framework.

#52974

[agocke]

Presupposes the UI a bit by assuming that "project references to exe projects" is the right way to design this, but yeah, that's the general idea.

[MeikTranel]

This would be just splendid to be supported. I've been thinking about designs for this for a while now. One idea i had would be updating the FrameworkReference Item to take a filepath to a project file. The Project file in question would define the framework and maybe even PackageReference items used to define common libraries used by more than one project.
The latter would be increasingly useful where a modularized install scenario requires subdirectories for certain App A, B & C that all require the dotnet runtime but may depend on different versions of the same library thus should be isolated in their own directories.

A.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <OutputType>winexe</OutputType>
    <UseWPF>true</UseWPF>
    <DisableImplicitFrameworkReference>true</DisableImplicitFrameworkReference>
    <OutputPath>$(SharedOutputPath)/client</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="../runtime/runtime.msbuildproj" />
  </ItemGroup>
</Project>

B.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <DisableImplicitFrameworkReference>true</DisableImplicitFrameworkReference>
    <OutputPath>$(SharedOutputPath)/server</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="../runtime/runtime.msbuildproj" />
  </ItemGroup>
</Project>

runtime.msbuildproj

<Project Sdk="Microsoft.NET.Sdk.RuntimeCache">
  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <OutputPath>$(SharedOutputPath)/runtime</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="13.0.0" />
  </ItemGroup>
</Project>

The sdk could then use the FrameworkReference to traverse and query the outputpath of the runtimecache project and tell the respective targets to either generate .deps.json respecting those path (comparable to how it is run during debug when dlls of packagereferences etc. are resolved via path in deps) OR by declaring the outputpath of the frameworkreference project as a probingPath in the deps.json.

I know this sounds like a stretch from the original requirement, but it really is in the spirit of the change needed, because theres almost no two individual apps that would generate the exact same sets of dependencies (especially with trimming). If you build everything into a single directory msbuild would have to A) concurrently build in the same directory which is problematic of it self, but theres also the problem of a second app publishing their dependencies in the same directory which might override hard dependencies onto different versions thus generating a whole other range of issues.
We have this exact usecase and started producing per app directories for a while now and it really is a more sane experience.

[agocke]

@MeikTranel Thanks, this seems very interesting.

Fair warning though, no timeline or commitment to this yet. .NET 6 is almost certainly impossible, we have too much work to do for existing scenarios.

This could be on the table for .NET 7 though, depending on competing priorities.

[MeikTranel]

Haha sure no worries - I was expecting this 😊

One thing that would really help immensely would be just the ability to specify a probing path as a relative directory in the runtimeconconfig.json - one can already specify it in as an environment variable with an absolute path so with my utterly minimal knowledge of the host I assumed it should be possible.