When making a bundle project, building fails when InstallerRuntimeIdentifiers is manually set inside.

• This issue is blocking
• This issue is causing unreasonable pain

For some reason I been hitting this issue when experimenting with making an installer bundle similar to those found in dotnet/runtime using the arcade package Microsoft.DotNet.Build.Tasks.Installers.

The issue happens on this line:

https://github.com/dotnet/arcade/blob/943d03f62955c771825dfa1f1bdeb8f853a2d7dd/src/Microsoft.DotNet.Build.Tasks.Installers/build/installer.targets#L85-L86

The following is what is in my bundleproj file:

<Project Sdk="Microsoft.Build.NoTargets/3.2.9">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AssemblyVersion />
    <!--
      Name, used to generate the bundle upgrade code. Must stay the same to allow bundles in a given
      product band to upgrade in place.
    -->
    <BundleInstallerUpgradeCodeSeed>Elskom Shared Framework Bundle Installer</BundleInstallerUpgradeCodeSeed>
    <BundleThemeDirectory>$(MSBuildProjectDirectory)</BundleThemeDirectory>
    <ArchiveName>elskom-runtime</ArchiveName>
    <InstallerName>elskom-runtime</InstallerName>
    <InstallerRuntimeIdentifiers>win-x86;win-x64;win-arm64;osx-x64;osx-arm64</InstallerRuntimeIdentifiers>
    <BundleNameSuffix>Runtime</BundleNameSuffix>
    <ProductBrandPrefix>Elskom</ProductBrandPrefix>
    <MacOSBundleTemplate>$(MSBuildProjectDirectory)/shared-framework-distribution-template-$(TargetArchitecture).xml</MacOSBundleTemplate>
    <MacOSBundleIdentifierName>com.elskom.dotnet.Elskom.Sdk.App.$(ProductVersion).osx.$(TargetArchitecture)</MacOSBundleIdentifierName>
    <MacOSBundleResourcesPath>osx_resources</MacOSBundleResourcesPath>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.DotNet.Build.Tasks.Installers" Version="*-*" />
    <PackageReference Include="Microsoft.DotNet.Build.Tasks.Archives" Version="*-*" />
    <BundleComponentReference Include="../sfx/Elskom.Sdk.App.sfxproj" />
    <BundleComponentReference Include="../sfx/Elskom.Sdk.App.Ref.sfxproj" />
  </ItemGroup>

  <Target Name="PublishToDisk">
    <Error Condition="'$(OutputPath)' == ''" Text="Publishing to disk requires the OutputPath to be set to the root of the path to write to." />
    <MSBuild Projects="@(BundleComponentReference)" Targets="PublishToDisk" Properties="OutputPath=$(OutputPath)" />
  </Target>

  <!-- <Target Name="PublishSymbolsToDisk">
    <Error Condition="'$(SymbolsOutputPath)' == ''" Text="Publishing to disk requires the SymbolsOutputPath to be set to the root of the path to write to." />
    <MSBuild Projects="@(BundleComponentReference)" Targets="PublishSymbolsToDisk" Properties="SymbolsOutputPath=$(SymbolsOutputPath)" />
  </Target> -->

</Project>

Perhaps that line can be made to not error when InstallerRuntimeIdentifiers is set, it seems to also happen if I set RuntimeIdentifiers only as well.

I been doing this sort of experiments with the arcade stuff to learn more about what was done to set up creating them for the normal .NET SDK / Runtime installers in the first place. When I done this I expected it to just work like I see with the runtime repository. Perhaps I am missing something I have not seen yet from the runtime repository which might explain why this just fails for some reason.

[AraHaan]

Yes, it’s part of a runtime people can have their programs depend on. And it’s located at https://github.com/Elskom/runtime/ It contains useful things that can be used by anyone including MiniDumping, plugin loading, encryption/decryption (blowfish), a packaging command for a gui application so it can package itself (and dependencies that get copied directly to their build output folder) into a zip file for distribution, reading embedded git metadata (generated from a source generator I created that goes with that runtime in a way), an lua 5.1~5.2 decompiler library, and an semi broken (currently checked to be broken on macos) zlib implementation.

The above that gets packaged together into an installer is useful for not just normal developers, but also for developers of games as well (as they can use it to pack their game files) without them needing to implement similar things themselves.

[NikolaMilosavljevic]

Thanks @AraHaan. We don’t support building multiple RIDs at once. We build .NET runtimes for a single RID only. It simplifies deployment as most customers need those individual runtimes., most often a machine native one.

You shared what you’d like to see implemented and how that affects your build system. However, it would be helpful to get a complete picture of your plans. Is this all for a sample/test project, and you were experimenting with installers, or is this for a product that ships to customers? How many customers and if this is open source on GitHub, can you share the link?