MS Store + WinUI3 + Win32 + CS : How to package .net framework and WebView2 dependencies.

[applefanbois]

When a customer get our app from the MS Store. He will be warned that a .net framework is required and the person will be asked to download and install it from the download folder. Once the app start, the WebView2 will just not work because MS did not bother to do anything (very professional).

You must install .NET Desktop Runtime to run this application.
...
6.0.21

Contrary to all App Store on the planet for the past 15 year (Android, Apple(macOS, iOS), Linux, PS5, Xbox, Nintendo), the MS store does not install dependencies automatically. First, MS Should stop behaving like an abandoned 90's legacy (CPM compliant) OS and fallow what the others are doing. Microsoft, wake up : your store should install dependencies and not bother their users and not bother the programmers either.

Is it possible to make everything works automatically like all other app stores?
I tried to package the .net framework (x64 + arm64) but nothing works.
There are no places in Visual Studio to do that and all the solution on the internet are dead ends.

A - How to make the store install all dependencies automatically without bothering the users.
B - How to package the frameworks in my app so the user does not have to do anything.

[DarranRowe]

All of the packages I generate for C# has the .NET runtime as part of them. What's more, the publish profile that is part of the C# project enables SelfContained by default, meaning that this is the default layout.

<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <PublishProtocol>FileSystem</PublishProtocol>
    <Platform>x64</Platform>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
    <PublishDir>bin\$(Configuration)\$(TargetFramework)\$(RuntimeIdentifier)\publish\</PublishDir>
    <SelfContained>true</SelfContained>
    <PublishSingleFile>False</PublishSingleFile>
    <PublishReadyToRun Condition="'$(Configuration)' == 'Debug'">False</PublishReadyToRun>
    <PublishReadyToRun Condition="'$(Configuration)' != 'Debug'">True</PublishReadyToRun>
   <!-- 
    See https://github.com/microsoft/CsWinRT/issues/373
    <PublishTrimmed>True</PublishTrimmed>
    -->
  </PropertyGroup>
</Project>

Did you disable SelfContained?

There is also an issue using the WebView2 package along with the Windows App SDK package because the Windows App SDK also contains a version of WebView2, so this is likely going to win out.

[applefanbois]

Well the "Package & Publish" does not have any such options. <---This is the one I use to generate the .msix that I upload to the store.

"Publish" will put .exe and .dll in a folder no packages.

[DarranRowe]

The SelfContained option is in the publish profile.

But "Publish" will put the entire framework into the directory.

This is using the WinUI 3 project type from Visual Studio. The only modification I did to this project was to update it to the Windows App SDK 1.4. I tested with both .NET 6 and .NET 7.

[applefanbois]

I do have the SelfContained to true.

But Publish is useless because it does not generate a .msix
I use "Package and Publish" to generate the package.

[DarranRowe]

Yes, and as I mentioned in my first post, any .msix packages that I generate from C# single project WinUI 3 projects, which are generated using Visual Studio's Package and Publish option, have .NET in with it.
This is why your current situation is problematic. As you may guess from the theme of my posts, what you are experiencing shouldn't happen. There are two final questions.

1. Are you selecting Debug or Release when you are generating the .msix packages?

2. If you create a new WinUI 3 project and generate the .msix packages from that, do you get the same problem? It doesn't have to be uploaded to the Windows Store, you can create packages for sideloading.

[applefanbois]

1- Release
2- If adding the self contained makes it work in package and publish, maybe it already works. Will test with customers next time there is a new user.

Thanks

[applefanbois]

Ok I confirm that all the procedures above DO NOT WORK.

When on the store, the poor innocent users will be asked to go download and install the .net framework by themselves. Imagine a store that does not install dependencies in 2023 (almost 2024).

I guess if you are still using Windows in 2023, you deserve it.

No wonders techniciens always recommend windows, it never works like the other modern OS.

[JoeTomkinson]

I'm seeing this issue right now, having to get an app update recertified by Microsoft and they're bringing it up on:

10.2.4.1 Security - Software Dependencies	
Products may depend on non-integrated software (such as another product or module) to deliver primary functionality only as long as the additional required software is disclosed within the first two lines of the description in the Store. 
[.NET Desktop Runtime]

I've tried following their guides to use this as self-contained, which does increase the number of dlls in the msix package, but when testing it on a fresh Windows 11 VM it still asks the user to install the runtime on first load of the app.

This is the article I've been following and I've made the same two changes it suggests:
https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps

Definately makes a difference, but just doesnt seem to contain the desktop runtime. Anyone else come across this or have a workable solution?

[JoeTomkinson]

I appreciate the response, typically speaking the winui project doesn't generate publishing profiles when using the publish and package option, I know it makes a reference to them in the csproj file:

<PublishProfile>Properties\PublishProfiles\win10-$(Platform).pubxml</PublishProfile>

But I obviously don't have any pubxml files in the solution directory as I have never created them, which begs the question what does that xml node do if there are no publishing profiles available, maybe a question for another day.

I actually did continue to play around with this problem prior to seeing your response and managed to get it to package the Dekstop Runtime by adding in the following two additional csproj nodes:

<!-- Publish as single file -->
<SelfContained>true</SelfContained>
<!-- To embed native binaries of the core runtime that are separate files into the single file. -->
<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>

This seemed to do the trick to be fair, but it's throwing out the following little error for packaging anything other than the x64 msix packages.

error NETSDK1032: The RuntimeIdentifier platform 'win-x64' and the PlatformTarget 'x86' must be compatible.

Obviously I've checked the configurations for each rumtime target and they seem fine. So for the purposes of experimentation I'm going to create the publishing profiles and see if that changes anything.

[JoeTomkinson]

Worth saying, I've packaged and published this app many many times in the past two years and never had an issue with the app requesting to install the .NET Desktop Runtime on launch, I suspect there's been some dependency updates in the last few months that now require it, Not exactly sure the root cause of that. But again, that's another curiosity.

[DarranRowe]

I appreciate the response, typically speaking the winui project doesn't generate publishing profiles when using the publish and package option, I know it makes a reference to them in the csproj file:

It shouldn't need to, there are some already part of the project template after all. You can always find them under the Properties directory in any of the C# WinUI 3 project templates. It then uses these publish profiles when you create the package to figure out how to publish the application into the package directory.

This seemed to do the trick to be fair, but it's throwing out the following little error for packaging anything other than the x64 msix packages.

error NETSDK1032: The RuntimeIdentifier platform 'win-x64' and the PlatformTarget 'x86' must be compatible.

I would imagine this is why the project uses separate publish profiles for the different platforms.

But just to be sure, did you create the project using the C# project templates in Visual Studio:

or did you use some other means to create the project? I'm wondering if something else managed to mess up the project layout and is actually missing the publish profiles? If so, try creating the publish profiles in the location that the .csproj file expects. You could create a dummy C# project through Visual Studio to get the default contents, or you could use the online templates. Just be aware that the online templates have been updated for .NET 8 support, but this support isn't currently in the templates available in Visual Studio. This would mean that you may need to modify file names. You would have to do this if you wanted to add .NET 8 support anyway.

Worth saying, I've packaged and published this app many many times in the past two years and never had an issue with the app requesting to install the .NET Desktop Runtime on launch, I suspect there's been some dependency updates in the last few months that now require it, Not exactly sure the root cause of that. But again, that's another curiosity.

This is also why I suggested deleting those directories that I mentioned in the project.
The build can go a bit weird after Visual Studio or the .NET SDK gets updated. I mentioned that during one publish after an update, I saw an error in relation to the PublishReadyToRun setting due to the build not finding a .NET runtime. That went away after I cleaned all of the intermediate build files in the project.

[JoeTomkinson]

It shouldn't need to, there are some already part of the project template after all. You can always find them under the Properties directory in any of the C# WinUI 3 project templates. It then uses these publish profiles when you create the package to figure out how to publish the application into the package directory.

I'd have to do a bit of digging but when I first created my application I definately didn't see any publishing profiles created as part of the solution.

But just to be sure, did you create the project using the C# project templates in Visual Studio:

Yep, I originally used the template studio extension when I created my application initially. As an aside, I imagine as this has had a handful of updates since the time I first used it that there probably are some key differences between the initial project it created for me back then and what it creates today.

In all honesty I've been meaning to take a look at some point to see if there are any quality of life improvements now vs back then that I might want to implement or include within my solution.

This is also why I suggested deleting those directories that I mentioned in the project.
The build can go a bit weird after Visual Studio or the .NET SDK gets updated. I mentioned that during one publish after an update, I saw an error in relation to the PublishReadyToRun setting due to the build not finding a .NET runtime. That went away after I cleaned all of the intermediate build files in the project.

I've done a bit more fiddling and I think I can see the issue and apologies for this as I've taken the long way around to the solution you provided, but now I understand a bit more as to the 'why of it all'.

I had the below two items in my csproj file:

<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
<SelfContained>true</SelfContained>

If I removed SelfContained I have no issues running the packaging, however obviously it still asks to install the .Net Desktop Runtime when the app is installed and first launches. Looking at some of the links you posted and some I have been glancing over I now understand that the 'SelfContained' option is specific to .Net packaging which currently only works if a single RID is specificed as the runtime target (I.E using just 'win-x64') and not having multiple platforms listed like the below, which is what I currently have.

<Platforms>x86;x64;arm64</Platforms>
<RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>

Essentially 'WindowsAppSDKSelfContained' doesn't seem to have any issues with multiple RIDs when using "Package and Publish", but 'SelfContained' does. So in your setup using publishing profiles, it must assign the appropriate RID for the target platform you're creating the package for and therefore not running a foul of the issue.

[DarranRowe]

Well, the linked I previously provided for the online WinUI 3 project templates contains 3 of them. One for each supported platform. As concrete example, win-x64.pubxml contains:

    <Platform>x64</Platform>
    <RuntimeIdentifier Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) >= 8">win-x64</RuntimeIdentifier>
    <RuntimeIdentifier Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) &lt; 8">win10-x64</RuntimeIdentifier>

This contains the platform and the runtime identifier for the platform it is publishing for. The two things that must be noted, first is that this is the x64 version, the x86 and ARM64 publishing profiles contain the respective platform and runtime identifiers. Also, this online version of the project templates contain the fixes for .NET 8. This is why it has the check for the .NET framework version in the condition. It is also why these are lacking the 10 in the file name.

[applefanbois]

Why can't microsoft VS Studio do everything that needs to be done for us like Xcode and Android Studio do?
Why can't the MS Store install dependencies automatically without bothering our customers?

Hey Microsoft, you know that the Android Store, Linux Stores and Apple App Store all install everything the app needs automatically?

We are so tired about the low quality of the MS SDK and Tools, we are abandoning the Windows version of our app in favour of an Android app that will be installed on Windows 11 from the Amazon App Store.

Windows native app is done, it is now a mobile and web world.
Thank you MS for pointing us in the right direction.

[DarranRowe]

Why can't microsoft VS Studio do everything that needs to be done for us like Xcode and Android Studio do?

It does. I have shown myself that Visual Studio places the .NET runtime in the package. These packages will install on a system without .NET installed and run without issue.

Why can't the MS Store install dependencies automatically without bothering our customers?

It does, but there is no .NET runtime package. This is why currently .NET has to be self contained. Or to put it another way, if you install a .MSIX package and it then asks for the .NET runtime, something went wrong with the packaging.

But this is the whole reason why I was asking questions. Visual Studio should produce a package which includes the .NET runtime in self contained mode. When the package is installed, it should just work without the desktop runtime installed. If you don't see that, then there is a bug and figuring out where the bug is would be very useful so it can be properly reported to the correct repository.

The frustrating issue is that this issue apparently doesn't produce many reports or posts. Either this means that it is rare, or people just give up very quickly. But for anyone to help, especially if they are like me where we just don't see the problem, the only way we could get an insight into figuring out the cause of the problem is to get information from people like you who are affected by the problem. This is why, when figuring out a problem, reproducing that problem is the most important first step. This is why bug reports also like to have steps to reproduce the problem, access to the project that exhibits the problem or at the very least, be provided with a smaller sample project that exhibits the same problem.

Anyway, if you have decided to not develop a Windows Store version of your application, then I wish you success with the version that you do distribute. However, I will remind you that the Windows Store isn't limited to just .MSIX packages, and WinUI 3 doesn't require being packaged up in a .MSIX package. You could always upload an executable or even .MSI installer and provide the redistributables that way.

[jonwis]

If you'd like to help, please file an issue over on the .NET repo - https://github.com/dotnet/runtime - requesting a framework package form of .NET Core for apps to use, including those that are NAOT and "Ready to Run." This is something on our long backlog to discuss, but it'd help to show community interest in it as well.

cc @jevansaks

[JoeTomkinson]

In the end I didn't need to do anything with publishing profiles, here are my settings from my csproj file, I've commented the important bits.

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<OutputType>WinExe</OutputType>
		<TargetFramework>net7.0-windows10.0.22621.0</TargetFramework>
		<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
		<ApplicationIcon>Assets/WindowIcon.ico</ApplicationIcon>
		<ApplicationManifest>app.manifest</ApplicationManifest>
		<ImplicitUsings>enable</ImplicitUsings>
		<Nullable>enable</Nullable>
		<UseWinUI>true</UseWinUI>
		<EnableMsixTooling>true</EnableMsixTooling>
		<GenerateTemporaryStoreCertificate>True</GenerateTemporaryStoreCertificate>
		<GenerateAppInstallerFile>False</GenerateAppInstallerFile>
		<GenerateTestArtifacts>True</GenerateTestArtifacts>
		<AppxBundle>Never</AppxBundle>
		<AppxBundlePlatforms>x86|x64|arm</AppxBundlePlatforms>
		<SupportedOSPlatformVersion>10.0.18362.0</SupportedOSPlatformVersion>
	        <!-- For fully self contained the below options need to be set appropriately -->
		<Platforms>x86;x64;arm64</Platforms>
		<!-- Thius one is for "WindowsAppSDKSelfContained" for packagein WinUI or Windows SDK specific assemblies within your MSIX and can use multiple RIDs -->
		<RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
		<!-- This one is for "SelfContained" which packages .Net assemblies into your MSIX and needs to only ever use a single RID -->
		<RuntimeIdentifier>win10-$(Platform)</RuntimeIdentifier>
		<!-- Publish as single file -->
		<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
		<SelfContained>true</SelfContained>
		<!-- To embed native binaries of the core runtime that are separate files into the single file. -->
		<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
	</PropertyGroup>
	
	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x86'">
		<PlatformTarget>x86</PlatformTarget>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
		<PlatformTarget>x64</PlatformTarget>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|arm64'">
		<PlatformTarget>arm64</PlatformTarget>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x86'">
		<PlatformTarget>x86</PlatformTarget>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
		<PlatformTarget>x64</PlatformTarget>
	</PropertyGroup>

	<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|arm64'">
		<PlatformTarget>arm64</PlatformTarget>
	</PropertyGroup>
</Project>

[DarranRowe]

If this works for you, then great.
But honestly, this seems like it a lot of working around the underlying problem. It also seems that you are moving things that are in the publish profile or calculated from the publish profile into the project file instead.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <Nullable>enable</Nullable>
    <TargetFramework>net7.0-windows10.0.19041.0</TargetFramework>
    <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
    <RootNamespace>CsMeh</RootNamespace>
    <ApplicationManifest>app.manifest</ApplicationManifest>
    <Platforms>x86;x64;ARM64</Platforms>
    <RuntimeIdentifiers Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) &gt;= 8">win-x86;win-x64;win-arm64</RuntimeIdentifiers>
    <RuntimeIdentifiers Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) &lt; 8">win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
    <PublishProfile>win-$(Platform).pubxml</PublishProfile>
    <UseWinUI>true</UseWinUI>
    <EnableMsixTooling>true</EnableMsixTooling>
  </PropertyGroup>
<!-- Other book keeping things here -->
</Project>

That is the main PropertyGroup from the test project I am using. I have already linked to the publish profiles that I am using. This makes trimmed packages with the .NET runtime as part of the package.

[JoeTomkinson]

For completeness it's worth my mentioning that I did go though the process of creating publishing profiles based off of your initial comment to that other person, just to see if it made a difference. Unfortunately it just didn't do anything. I think there's a big disconnect between what's created using the latest version of template studio and what happens when you right click publish and create publishing profiles for each of the runtimes.

For me, on a project created with template studio a couple of years ago, adding a way to pass through the single RID so that the .Net Assembly packaging works properly is the easiest way forward. The other thing of note which I find odd related to the delineation between 'publish' and 'package and publish' options is that why would there would be a dependency on publishing profiles (typically used for publishing something to Azure, File, or Click Once Install) and 'Package and Publish' which is specifically designed to create a package to be sideloaded or submitted to the Microsoft store.

<RuntimeIdentifiers Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) &gt;= 8">win-x86;win-x64;win-arm64</RuntimeIdentifiers>
RuntimeIdentifiers Condition="$([MSBuild]::GetTargetFrameworkVersion('$(TargetFramework)')) &lt; 8">win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>

Personally I think two conditions above are the main reason it works for you, I think when this runs it provides a single RID depending on the TargetFramework at build time.

Out of sheer curiosity I wonder what would happen if you removed <PublishProfile>win-$(Platform).pubxml</PublishProfile> from that csproj, would it still package appropriately.

[DarranRowe]

Personally I think two conditions above are the main reason it works for you, I think when this runs it provides a single RID depending on the TargetFramework at build time.

That is part of the .NET 8 compatibility. If you switch the framework to .NET 8 or newer, it would use the more portable win- version of the runtime identifiers, older versions would use the less portable win10- version. Basically, this shouldn't affect anything more than providing the build process runtime identifiers it expects for the targeted .NET version.