.NET Runtime as MSIX dependency

[LadderLogic]

This might be a repeat, but I am unable to locate this in search.

The appx packaging helps nicely to separate application into one msix, and windows app runtime, VCLibs as dependencies into their own msix. However, the .net runtime is part of the application msix. How can we pull the .net runtime to be it's own msix and part of dependencies? I understand the self-contained vs. framework-dependent paradigm of .net, but I don't see where msix packaging could come into play in framework-dependent (?) solution

[rocksdanister]

Related: dotnet/runtime#51574

[sylveon]

I don't think people are interested in using a MSIX-packaged runtime when unpackaged.

This issue is more about using getting a framework package for packaged apps to use, instead of needing to bundle the entire runtime with their app, bloating up download sizes and used storage space.

This issue is already solved when unpackaged by also using the unpackaged .NET runtime. While you can use the unpackaged .NET runtime in a packaged app, it's a violation of Store policy to do so, so using the unpackaged .NET runtime is not really a solution for packaged apps, leaving people with the far heavier SCD as the only option.

[DrusTheAxe]

I don't think people are interested in using a MSIX-packaged runtime when unpackaged.

Fair enough. Just covering the bases as I've heard it mused upon a time or two.

Regardless, thanks for your input! Community feedback is invaluable to help us prioritize amongst the many options we could pursue

[LadderLogic]

Don't want to beat a dead horse here, but I agree with the sentiments:

1. .net dependency as a package is relevant to packaged (Store/LOB/Sideloaded) apps only
2. Not convinced that building a .NET MSIX package is of a high-priority to the .net team than the Windows SDK team. I'll be happy to package my own .NET as msix, but that defeats the purpose of msix portability. How can the community help expedite this process?

[AdamBraden]

Please see #2478. We are delivering support for ILtrimming in self contained applications. That won't solve every issue, but its an approach we and the .NET team agree on as a first step. Once it is ready, would be great to get feedback on its strenghts and weaknesses.

[LadderLogic]

@AdamBraden We are looking forward to a release version of ILTrimming. We've tried the preview version without much success. That being said, ILTrimming is great for monolithic applications. I am trying to envision how that would work for an application that has multiple packages, both dependencies and optional packages. Can the packages "aggregate" .net or do they each have to repeat the same IL? I guess we'll have to wait for the release :)