Windows target publishing/archiving

[davidbritch]

We need a doc on publishing Windows apps using the CLI. The process is doc'd at dotnet/maui#4329. While Windows publishing uses msbuild, support is being added to the dotnet command but it's unlikely to land for GA.

The doc should link to any relevant Windows/WinUI 3 publishing docs, including uploading the package to the store.

The doc should go in a new node at the bottom of the TOC that's called something like Deployment/Publishing/Packaging. Maybe Publishing, as the other platforms use the dotnet publish command.

It seems that both package and unpackaged apps are now supported: dotnet/maui#3166 and dotnet/maui#4460

[davidbritch]

there are 2 kinds of "self-contained" when talking about WinUI:

• .NET runtime "self-contained" (MSBuild Property name "$(SelfContained)") - the default is true
• WinUI runtime "self-contained" (MSBuild Property name "$WindowsAppSDKSelfContained)") - the default is false and only allows true with Windows App SDK 1.1

Note that you can't set $(SelfContained)=false with Maui because of dotnet/maui#7170. So all Maui Windows apps are ".NET Runtime self-contained", meaning the .NET runtime ships with the app.

[davidbritch]

RC2 (allegedly) supports using dotnet build.

[Dbquity]

@davidbritch

RC2 (allegedly) supports using dotnet build.

But it seems to no longer support msbuild. See the workaround found in this issue: dotnet/maui#6831, which seems to indicate that calling msbuild from the command line is no longer needed (in fact, it does not work). Instead, building the Release profile targeting Windows Machine from the VS UI nicely produces a .msix file.

[davidbritch]

The dotnet publish variant:

dotnet publish /p:TargetFramework=net6.0-windows10.0.19041 /p:configuration=release /p:GenerateAppxPackageOnBuild=true /p:AppxPackageSigningEnabled=true /p:PackageCertificateThumbprint="EA8A18C1ED0CCB30E5D841F3F0135BBEDE618F08" /p:PackageCertificatePassword="password"

However, you might run into the MSIX not running afterwards. Currently there's a dependency on the Visual C++ Redistributable. Three options:

1. Install the Visual C++ redistributable package on the client machine (if it isn't installed already)
2. Add the 1.0.3.1 version of the Microsoft.Win2D NuGet to your client
3. Add the C++ redist to the Package.appxmanifest so that it will become a dependency the msix will pull in. See: https://github.com/dotnet/maui/pull/6758/files (but instead of removing it, add it)

This should be fixed for RC3 so that none of the above is necessary.

It should be possible to omit /p:AppxPackageSigningEnabled=true with RC3.

[jfversluis]

@Dbquity both dotnet publish as well as msbuild work as long as the TFM in the command-line parameter and the csproj match

[Dbquity]

@jfversluis
I see - makes sense. Thanks!

[Dbquity]

@davidbritch
Thanks for the C++ redist tip - that'll save the day on my end :-)

[Dbquity]

I am not sure, if this is the right place to ask this question, but since the context is set here, I will try:
Earlier, the .msix produced by the steps that @jfversluis wrote up (dotnet/maui#4329) was named ..._AnyCPU.msix, recently the name ends with ..._x64.msix.
Does that make a practical difference?

A fine answer could be that I need to read up on MSIX :-)