Discussion: Simplify WinUI3 deployment for unpackaged Win32 desktop app

[smourier]

Discussion: Simplify WinUI3 deployment for unpackaged Win32 desktop app.

Today (and this has been like that for about 20 years...) if I want to write any kind of UI App for Windows (and want to stick with Microsoft tech and languages), I will use one of these:

• A plain C++ Window Win32 app
• A Winforms .NET app (C#)
• A WPF .NET app (C#)

With these technologies, it basically "just works".

Note: I favor .NET thanks to its wonderful "Any CPU" compilation feature, to really support any Windows OS w/o pain.

Today, I want to replace old these legacy technologies by WinUI.

The issue:

I've been attended the WinUI Community Call of May 20 2020, and if I understand correctly, the envisaged deployment scenarios for WinUI desktop apps are:

• packaged app where my app will reference another "WinUI" package => fine, seems pretty easy and (hopefully) seamless for end-user
• unpackaged app where my app (even in PublishSingleFile mode) will have to ship with possibly hundreds of .dlls and other files that I can't control => huh???

What I'd like is really get rid of Winforms and WPF, but still be able to ship Windows UI apps with a simple deployment model.

This is far from being a cosmetic or nitpicking issue. Not even mentioning the x86 vs x64 problem, try to compile the "Visual layer samples for desktop applications" here https://github.com/microsoft/Windows.UI.Composition-Win32-Samples and you'll see there are already issues with Win2D and the VCRTForwarders because packages and references have not been updated, etc. It doesn't "just work". And of course tech support is more important if you have more files to ship.

Proposal:

In an ideal world, I'd like the whole "runtime" payload to be included with the app itself.

But let's be reasonable. It think would be ok for example if when the user starts the app, some download happens to install what's needed to make it work (like when you don't have old .NET frameworks, they are installed automagically) with some sort of bootstrapper technology. And maybe in some future, Windows will have these packages already installed (again, like .NET Framework)

To me it's really a showstopper. The package app model is ok, but most of the times, we don't write packaged apps. If Win32+WinUI deployment is not simple enough I will only move to WinUI for packaged apps.

[stevenbrix]

As you alluded to, this can be accomplished in .NET apps through PublishSingleFile.

There isn’t a way to accomplish something similar in C++. if you want an unpackaged Win32 app in c++, you need to ensure the .dlls are copied next to the exe.

[smourier]

@stevenbrix - PublishSingleFile will put everything in a single file? including all native dlls that I can see today in my, say, win-x64 directory? Or are you just talking about the .NET Core side of things (which doesn't answer my overall "deployment" question with regards to what can be done today with legacy techs).

[weltkante]

With WinForms and WPF in .NET Core there is a "shared runtime" package one can install and target so one doesn't have to deploy the DLLs. Would it make sense to provide a set of WinUI DLLs in the shared runtime package as well? (If WinUI releases faster than the runtime you'd still have to deploy DLLs if you need a newer version than the runtime package you target contains.)

[smourier]

@weltkante - absolutely, that's exactly my point, a super simple deployment is an absolute must. I personally can't invest on WinUI today w/o any confidence in that area. I'd love to.

[gaessanty]

"copy -> run"
This is very similar to the experience of existing users.
The existing app was very simple and I hope it will be the same on the Win32 desktop.

[stevenbrix]

@smourier I'm a bit confused by your requirements. Where are you trying to deploy the unpackaged app? Are you just trying to run it on your machine, or do you want to place it on a different machine?

/cc @MikeHillberg and @jevansaks

[smourier]

@stevenbrix - I don't want to "deploy" an unpackaged desktop app (as in UWP "deploy"). I'd like it to be very simple to use it, for example just copying an .exe, without having to deploy 300 satellite dll like what's demonstrated in the current WinUI 3 preview. That's what frightens me.

I don't see this as a "requirement", this is what we have today with .NET Winforms, WPF, or with Plain Win32 app using any language or tool: C/C++, MFC, Delphi, QT, whatever. All these tools can produce one binary that can be copied to any Windows (almost, ok, let's say version 10+) machine.

[stevenbrix]

@smourier I'm using the term "deploy" generally to refer to getting an app on a machine and running it. I'm not using it to distinguish between packaged/unpackaged. Is there a different term that I should be using?

In an ideal world, I'd like the whole "runtime" payload to be included with the app itself.

From this part of your proposal, it seems like PublishSingleFile is exactly what you want, or am I missing something?

As for C++ apps, we don't support static linkage of our libraries. I'm assuming that's how frameworks like Delphi or QT work to produce a single .exe file?

[smourier]

@stevenbrix - About PublishSingleFile, you already asked above, and I believe I already answered. Will this include all the ~300 dll (and also non binary files) that I have today aside my WinUI 3 .exe?

A single .exe can be produced differently than using static lib. Anyway, I'm not looking strictly for a single .exe, I'm looking for a "decent" way of deploying an unpackaged app. Today it's almost 300 files (for around 170MB) . This is not what I'd call "decent" for something that's not "packaged" or from some kind of store.

[ranjeshj]

We need the dependent binaries somewhere. I think we are talking about these options.

1. Loose files next to the exe
2. In the exe itself using PublishSingeFile
3. As a framework package installed through the store (or some installer), and the app takes a dependency on the package.

@smourier, are you asking if there is some 'installer' option for unpackaged apps similar to msi ?

[stevenbrix]

Sorry, yeah PublishSingleFile will create a single .exe file without all the .dll's next to it. See this blog post for more on that https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

[smourier]

@stevenbrix - ok, so, making sure I understand, it means I will have a 170MB or so for a "hello world" app (with say, 1% of it taken by the hello world code)?

@ranjeshj - Maybe, I mean some support file that I don't have to ship with my binaries (bootstrapper, msi, runtime, nuget, winget, call it the way you want, possibly on the internet) and that will "just work" when I run my app.

It's not only a size or number of binaries problem, it has also other implications in dev, like compilation time. A not so small C# program today is around 1 or 2 sec. compilation time on a decent PC, not what I observe with WinUI 3 preview today.

[ranjeshj]

@marb2000 @MikeHillberg @Austin-Lamb as FYI

[stevenbrix]

so, making sure I understand, it means I will have a 170MB or so for a "hello world" app (with say, 1% of it taken by the hello world code)?

If you use PublishTrimmed it will reduce a Hello World app from around 70MB to 28MB, and the WARP tool can take it down to 13MB. Definitely not ideal, and if the benefits of this deployment model don't outweigh the costs of the slight size increase of your app, then we can discuss something else.

A not so small C# program today is around 1 or 2 sec. compilation time on a decent PC, not what I observe with WinUI 3 preview today.

I definitely sympathize with you. There are 2 major buckets that are causing slow compilations times:

• XAML Compiler.
• MSIX packaging

There's nothing special about Desktop/Preview1, we've had painfully slow compilation times with UWP for some time. Since you're asking about unpackaged apps, the MSIX portion isn't really relevant to this discussion.

I'm sorry if the answers I'm giving aren't what you want, I'm really trying to understand what it is that you're after, so please bear with me. Is there an example of some other tech that you have in mind that you'd like us to model this after?

[smourier]

@stevenbrix - well the other techs are really the legacy ones : Winforms, WPF, or plain/old Win32/desktop development. They're all very fast to compile, very easy to copy ("deploy") and run. But they are legacy.

For example, today, I can use the Microsoft.Windows.SDK.Contracts nuget with an "old" .NET Framework 4.8, C# 7. From there I can use Windows.UI.Composition which is a dual API, so is allowed in desktop apps, and write my own Direct2D interop layer in C# (w/o Win2D) and benefit from all performance (flip sequential swapchain, etc.). With this type of project, I have a size of 3rd party assemblies reduced to 0K. My compilation Time is 2sec with Visual Studio 2019. Potential deployment issues/risk to customers: 0%. But I don't have all the features that's inside WinUI 3, so I have to write lots of "framework" code.

BTW, initially (Windows XP time if I remember correctly), the first .NET apps required .NET to be installed on Windows before they can run. But it was quite a simple process, just install the .NET redist of that time and off you ran. And then, Windows integrated .NET in its core (sort of), so that part wasn't necessary. Even today, if you run an old .NET 2.x app, Windows will ask and install quite seamlessly the required .NET 2 redist. All these were/are quite transparent for everyone: the developer because it already has the .NET runtime, the user because it's basically one dialog and click away from running (an experience similar to what we have with UWP packaged app from the store).

[stevenbrix]

Thanks @smourier, that really helped connect the dots. I now better understand the type of model that you are looking for.

But it was quite a simple process, just install the .NET redist of that time and off you ran. And then, Windows integrated .NET in its core (sort of), so that part wasn't necessary. Even today, if you run an old .NET 2.x app, Windows will ask and install quite seamlessly the required .NET 2 redist.

So as @weltkante mentioned, this does exist today with .NET5 (at least in some form). If you try to run an app and the runtime isn't installed, you'll get a popup notifying you to go and install it with a link that you can click. It does require the user to have admin privileges to run the installer.

From the spec on single file publishing, it looks like you should be able to have a single .exe file that contains the WinUI dependencies, but not the .NET runtime (see the part on "Framework Dependent Publish"): https://github.com/dotnet/designs/blob/master/accepted/2020/single-file/design.md#user-experience

One of the benefits of WinUI3 is that we are decoupling from the OS, so that new features can work downlevel. The downside is that you do have to pay the extra cost of WinUI being bundled with your app, but at least you wouldn't have the entire .NET runtime. Does that satisfy your needs?

[smourier]

@stevenbrix - I'm not sure yet :-) , the preview does not demonstrate these aspects. I understand the "cross platform" benefit, but I don't really want to pay for its probable burden if I'm only targeting (more than 1 billion?) Windows boxes. And AFAIK, from a high level, this "bundle" could also be just there, already installed, in the Windows case.

For example, UWP is very attractive (modern UI, performance, D2D integration, etc.) but I don't want to pay the "sandbox" + "package" + "compilation price", unless I need to ship it to the store (because the store in itself adds value). If developing a desktop app (with WinUI 3) brings me the same kind of constraints (w/o the sandbox I believe), then I doubt I will use WinUI 3 very often.

I guess "The devil is in the detail".

[marb2000]

@smourier Thanks for your feedback and open this necessary discussion.

You have a very fair point about the WinUI deployment in Desktop apps just doing an Xcopy (no using packaging/deployment mechanism like MSIX, MSI, or ClickOnce).

The current disk footprints for C++ and .NET basic apps are approx :

• .NET: 270 files
• C++: 60 files

I believe there are rooms for improvement for these disk footprints.

For instance, .NET WinUI 3 apps should be compatible with the .NET publish features like:

• PublishSingleFile: place everything in one EXE
• PublishTrimmed: remove unused .NET assemblies

Unfortunately, we don't have a story like .NET for C++ yet. Any feedback/guidance is welcome here.🙏

One thing that we can do to reduce the footprint of C++ and .NET apps is to deploy the WinUI 3 runtime in a shared folder (similar to .NET Core that is using %ProgramFiles%\dotnet\shared\Microsoft.NETCore.App). This mode is called framework-dependent, reusing the .NET argot. That means that all the WinUI 3 apps that opt-in for this mode will use the latest minor-version of the shared folder. However, the Plan-of-Record is that for 2020 the WinUI 3 runtime deployment is self-contained (again taking the term from .NET argot).

We are eager to listen to customers with scenarios where not having self-contained is a blocker so that we can adjust the prioritization of this feature against others.

[myokeeh]

Does "Hosted App Model" help here? Can that concept be applied here to have the "just works" effect? https://blogs.windows.com/windowsdeveloper/2020/03/19/hosted-app-model or is this too round about/missing the point?

[Tlaster]

Just happy to see WinUI 3 for Win32 to be self-contained without packaging. Current UWP app does look fancy and beautiful but not every UWP apps is suitable for store publishing, and side-loading UWP app is difficult and painful for most of the end-user.

[smourier]

@myokeeh - Thanks for pointing that article that I hadn't seen. It's a bit like the reverse of a runtime way. Well, that's another brick that could be used maybe, something like a universal "WinUI Host". Why not if it has all the benefit we want (fast compilation, xcopy deployment, etc.).

[smourier]

@marb2000 - thanks for the clarification about self-contained.

As a Windows developer, what I would expect is just use Win32 (or WinRT) and use WinUI 3 without any dependency.

If you look at the picture here: https://docs.microsoft.com/en-us/windows/uwp/composition/visual-layer, today, right now, I can use all 3 layers with zero dependency, .NET (not necessarily .NET core) or C++ or any language that likes Windows (using a combination of Win32 and WinRT), so, why can't I do that tomorrow with WinUI 3 (which will replace the current "Framework Layer") ? Why do I even need to "publish" or "package" something? Or suffer increased compilation time? Because that (fundamental) part has gone cross-platform, we can't program Windows like we used to?

IMHO, the scenarios you describe will not ease adoption of WinUI 3 as a complete replacement from what was before (I can at least speak for me). It's not necessarily a "blocker" as such, but it will still be so much simpler in most aspects to use legacy techs, tools, languages.

[Urmeli0815]

It may be worth to look at what the Edge-Chromium team does with the WebView2 distribution model. See https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#microsoft-edge-webview2-runtime

When I replace "WebView2" with "WinUI" and "Edge browser" with "WinUI-Runtime" it is almost the description of a perfect distribution model for me:

1. have the option to use/reference a shared Runtime which just needs to be installed once and which is maintained by the OS by applying updates ("evergreen distribution model"). Quote: "Installing the runtime once will support many WebView2 applications running on the client machine".
2. or choose a fixed version of WinUI for restricted environments which gets bundled with your application

Option 1 would require rock-solid versioning concept (like semantic versioning) to prevent breaking of apps in the future.

As WebView2 is also part of "Project Reunion" I think it makes sense to offer similar distribution models for the different components of this project.

[stevenbrix]

and side-loading UWP app is difficult and painful for most of the end-user.

@Tlaster could you file an issue in https://github.com/microsoft/ProjectReunion repo detailing the trouble you are having?

[tomasfabian]

@marb2000 We are most specifically interested in displaying (video) content rendered by DirectX11 or DirectX12 in a similar fashion as D3DImage does with DX9. We found out in the WPF repository that its targeting only DX9.
I'm talking in a theorethical way right now, since I haven't had enough time to explore the whole WinUI 3 ecosystem.
We would like to also test if there is a performance / penalty cost for marshaling between DX11 and DX9 in XAML islands, but this is probably not relevant for this forum.

[CoderTyn]

I have the same question.

[bughandler]

I highly agreed with this post's opion, and I gonna ask again.
When we can get the unpackaged desktop deployment support?

Thank u :)

[sudongg]

@tomasfabian
Have you found a way to render video in WinUI 3? Just like WPF D3DImage.

[JaiganeshKumaran]

Please use MSIX if you need an installer. Keep it unpackaged only if you don't need an installer

[kevmoens]

I installed .net 6 preview 3. I created a new WinUI3 project and saw that there is a packaging project which creates a MSIX package. I am hoping to create a non-sandboxed application that allows for auto update features where we can use a command line to package/publish the application. As we ship our solution to customers and they host our applications on premise. ClickOnce has been our solution but I am interested in moving our WPF app to .Net MAUI but currently I have only seen ways to create apps with our best solution being a sideloaded application. We also have thousands of customers who get modifications which we maintain and need to easily ship product so they can host on their machines. We do use SmartCards for personal identification / verification (optional) and biometric devices (optional). Our goal would be to make apps that run on Windows and Android. I know I am pushing the limit yet currently we are stuck to windows and ClickOnce and with Android tablets being able to run on a shop floor with a low cost and long battery life it would make sense to leverage those devices.

[lcsondes]

It's hard to understand why you're picking an unpackaged app. What things would Microsoft need to do to convince you to package everything in an MSIX?

@lukemcdo Can I take one of the starter projects, build it into a single file and hand it out to non-technical people to double-click install without providing an extra page of instructions? Bonus points for AnyCPU. If there's a way to do this, it's very well-hidden, and arguably it should work out of the box when you create a template project from VS. I could only find the usual change Windows settings + install certificate UWP nightmare that prompted many people to just simply ignore its existence and stick with the old low-friction stuff.

Please use MSIX if you need an installer. Keep it unpackaged only if you don't need an installer

@JaiganeshKumaran This sounds nice on paper but the reality is that there's strong competition from existing MS tech and honestly I don't even want to convince stakeholders to enter this new overcomplicated world of software delivery. I don't really have arguments for it but arguments against are plenty, and not using it will make my life easier as a developer, too. "Microsoft says this is the future" has no weight, UWP was also the future and to this day most people probably won't miss a single program from their computer if they completely ignore its existence.

Right now I can easily build an .msi with WiX that deals with installation, uninstallation, upgrades, downgrades, etc. in a way that I can tightly control and is familiar to all Windows users. WinUI 3 being tied to MSIX essentially invalidates it right now, a GUI library should not dictate installation.

[kevmoens]

We sell our apps which get hosted on-premise on customer servers. Is it possible to update the update url so they can host the app with a packaged app? That is why we use click once. It can be run and configured on the customers server

[lukemcdo]

It's hard to understand why you're picking an unpackaged app. What things would Microsoft need to do to convince you to package everything in an MSIX?

@lukemcdo Can I take one of the starter projects, build it into a single file and hand it out to non-technical people to double-click install without providing an extra page of instructions? Bonus points for AnyCPU. If there's a way to do this, it's very well-hidden, and arguably it should work out of the box when you create a template project from VS. I could only find the usual change Windows settings + install certificate UWP nightmare that prompted many people to just simply ignore its existence and stick with the old low-friction stuff.

MS was supposed to deliver some sort of Azure App Signing service nearly a year ago, so your criticism is valid until that finally lands. It's pretty absurd a service that's necessary to use any modern MS technology in a corporate setting turned into vaporware. My comments assumed that the vaporware was months from materializing, as was hinted at the time.

I don't quite understand why you want to control installation, uninstallation, upgrades, or downgrades. Upgrades -- as in dynamically loading additional DLLs? Or just version updates, something MSIX can provide for free? The other three items don't seem like something you can do meaningfully better than the MSIX built-in functionality.

The primary reason to pick MSIX is because it's an extremely straightforward installer that can be automated easily, and included in prebuilt customer Windows 10/11 images extremely easily.

[lcsondes]

I don't quite understand why you want to control installation, uninstallation, upgrades, or downgrades.

Example scenario: you build test versions of your program that you give to scientists to test. The msi is configured to uninstall every other version of itself including newer ones. Regular installers don't do downgrades. I'm not saying that MSIX can't do these, just that it doesn't do anything extra beyond this that's immediately obvious and worth the tradeoff.

The primary reason to pick MSIX is because it's an extremely straightforward installer

I strongly disagree. Setting a computer to developer mode and installing a trusted certificate is anything but "extremely straightforward". Double-clicking an msi or exe is extremely straightforward. That is its competition.

There are tons of scenarios where you can't (management doesn't think it's worth the extra x in the filename and/or the risk of moving to a different install tech) or don't want to (special builds, manual one-off installations for testing, hardware keys don't work well with the weird legacy builds of your company, etc.) get a full code signing certificate.

[lukemcdo]

I strongly disagree. Setting a computer to developer mode and installing a trusted certificate is anything but "extremely straightforward". Double-clicking an msi or exe is extremely straightforward. That is its competition.

"MS was supposed to deliver some sort of Azure App Signing service nearly a year ago, so your criticism is valid until that finally lands."

[lcsondes]

I got that, but Azure makes me think of it being a cloud-based service. Does/will it support building actually-installable packages completely offline without having to get a purchase signed off? If it did, that would be lovely.

[lukemcdo]

It has to be online realistically, the whole point is that your packages are being signed by an authority. The expectation was that it would be free/cheap. I haven't heard anything about it recently though, I'll ask around.

[shelllet]

I strongly disagree. Setting a computer to developer mode and installing a trusted certificate is anything but "extremely straightforward". Double-clicking an msi or exe is extremely straightforward. That is its competition.

Develop unpakcage desktop app is very important, it even determines whether I will choose winui3 to develop ui applications.

[jonasnordlund]

To give an example of a typical scenario for us here; we develop a large GIS application and many of our clients are thus in the energy business or municipalities. Many are thus strongly restricted for security reasons and we need to support cases where we only have a single communication towards the outside world via an open port 80 to our IP address from within a virtual machine. Obviously, Microsoft Store is long since out of the question and probably even disabled via a Group Policy.

Not only do we need to deploy unpackaged apps, but they can also not pull in things from various parts of the Internet at install time or runtime. They'll hit a wall if they suddenly need to go into some poorly documented Microsoft IP range that may change over time on Microsoft's whim. So we need to have the complete set of files ourselves.

We also cannot ask these users to switch their systems to a reduced-security "Developer Mode" due to side-loading. They aren't the developers, so they shouldn't have anything to do with these settings.

I'm unsure exactly where WinUI deployment is heading but nothing of this is currently a problem if we just have them run an offline .NET Framework installer (in case it's not preinstalled which it increasingly more often is) and xcopy our files into a folder where our applications are Console, WPF or WinForms apps.

[jaymarvin98]

Hi,
What is the status of this feature? Can I now get a sample of compiling a UWP/WinUI3 app that will run as a standard old-fashioned .exe, and not require Store or Sideloading?
Thanks,
Jay

[zadjii-msft]

I believe that version 1.0 of the Windows App SDK will support this. See:

• https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-10
• https://docs.microsoft.com/en-us/windows/apps/winui/winui3/create-your-first-winui3-app?pivots=winui3-unpackaged-csharp
• https://docs.microsoft.com/en-us/windows/apps/winui/winui3/create-your-first-winui3-app?pivots=winui3-unpackaged-cpp
• https://portal.productboard.com/winappsdk/1-windows-app-sdk/c/8-unpackaged-app-support
• https://github.com/microsoft/WindowsAppSDK/issues?q=is%3Aissue+unpackaged

Admittedly, I'm not keeping closely up-to-date with the state of WASDK.

[MikeHillberg]

Yes, the 1.0 release includes support for unpackaged apps. A couple of notes:

• It's a Desktop app rather than UWP.
• This isn't a fully self-contained app; it still needs an installer to install the WinAppSDK

[AtosNicoS]

Hey guys,
I am experimenting with WinUI for the first time and got a few questions using the packaging option:

• When running UWP Apps it requires to define capabilities. Is there also a way to NOT use capabilities/restrictions with WinUI? Maybe with the unpackaged version?
• I was able to get the App running by adding <WindowsPackageType>None</WindowsPackageType> to the project file. This works for both, the Black App, Packaged (WinUI 3 in Desktop) and Black App, Packaged with Windows Application Packaging Project (WinUI 3 in Desktop). For the later I must add it to the non-package project. But what is the actual difference, than having the package option in a separate project? To me it all looks the same?
• Is there now a difference between WPF and UWP when using WinUI3? Or is it all the same? From my understanding it is an evolution of UWP and it does not use WPF behavior by default?

Would be nice if someone can clarify. There are not many blog articles out there, and those that are, are using the 0.5 but not the 1.0 version.

[537mfb]

What are my options if I:

1. only work in software to be used inhouse - so windows store is out of the question
2. can't mandate all user PCs to be in developer mode - that wouldn't be good security wise
3. because it's all to be used inhouse, spending money in a software certificate doesn't make any sense
4. I need the software to self update - like clickonce does - when I release an update

[myokeeh]

What are my options if I:

1. only work in software to be used inhouse - so windows store is out of the question
2. can't mandate all user PCs to be in developer mode - that wouldn't be good security wise
3. because it's all to be used inhouse, spending money in a software certificate doesn't make any sense
4. I need the software to self update - like clickonce does - when I release an update

For our use, Store for Business worked/works but that's going away.

[jonasnordlund]

What are my options if I:

1. only work in software to be used inhouse - so windows store is out of the question
2. can't mandate all user PCs to be in developer mode - that wouldn't be good security wise
3. because it's all to be used inhouse, spending money in a software certificate doesn't make any sense
4. I need the software to self update - like clickonce does - when I release an update

Since everything but point 4 is actually already supported thanks to the unpackaged app support, and now with Windows App SDK 1.1 Preview 1 onwards, also in a self-contained fashion with no dependency on Windows App SDK, I suppose all that remains is to tack on auto-updating support with something like Squirrel (see the .NET Core notes though if considering this framework).

[537mfb]

@jonasnordlund the unpackaged also has a few limitations as compared to packaged one - for example, ApplicationLanguages.PrimaryLanguageOverride and ApplicationLanguages.Languages don't work for localization purposes in unpackaged version - only in packaged version
Ther could be others - but this are the first I noticed

[mbodm]

@smourier brought up a LOT of valid/important points here, for many of us, imo. Kudos for that.

To be honest: As it is actually, It´s a complete horror. At least for me.

After more than 8 hours i was able to realize that i need

• to instantly update the NuGet packages (of an empty project) or everything goes wrong
• to add <WindowsPackageType>None</WindowsPackageType>
• to add <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
• to check it´s <OutputType>WinExe</OutputType> (which is the 99% case)
• and that i do NOT need to use <WindowsAppSdkUndockedRegFreeWinRTInitialize> when above 3 previous facts are given (MSDN docs say so)

to produce an unpackaged self-contained WinUI3 app.

And all of this (reading through endless documents about "packaged vs unpackaged" and "self-contained" specific stuff) was just the easy part. Let´s not talk here about Visual Studio integration or templates, when it comes down to creating a WinUI3 app.

After that, i realized that VS 2022 17.5.5 completely fucks up everything related to publish profiles. In example

• wrong selections
• profiles and platforms not matches
• output paths become weird AF (subfolders of other platforms, etc.)

when dealing with a WinUI3 project.

After that, i checked the Produce single file checkbox. Which only worked, when not paired with deploying Windows App SDK as self-contained. Also the settings were lost every single publish button press.

And after that, i selected the Trim unused code checkbox. No comment...

There is sooo much stuff flying around, like:

• a .csproj file, full of stuff nobody understands in 1 week.
• hundreds of pages about compiling or deployment details.
• a million missinformations by confused users or version changes.

Literally nobody can see through that jungle, to handle such a type of beast, imo. It was by far the most negative experience i had in software development, since a decade or so.

Imo it’s not possible yet, to produce a single file exe that is also using self-contained deployment of Windows App SDK. Either you create a single file exe, but then a popup to install the Windows App SDK shows up on the target machine. Or you deploy the Windows App SDK self-contained (no install popup on target machine), but then you can not create a single exe file. Both at the same time seems impossible. At least i did not achieved that goal.

Long story short: After 20+ hours i do not yet have a "Single .exe file unpackaged self-contained WinUI3 app". I would call all this stuff a "late beta". At best. Very dissappointing and not the quality MS normally delivers.

But that´s just my experience and my 2 cents.

[vsTianhao]

Now PublishSingleFile has almost no effect, hello world will generate hundreds of files, and the main file is more than 100MB

[manishcanarymail]

Do you have any updates on using a single MSI or EXE with unpackage?

[minfrin]

Am I assuming there is no planned support for packaging a WinUI3 app outside of MSIX?

I am limited in that I am forced to build a native messaging browser application, which still lives in the old world of updating the registry of the browser to work, something I understand is impossible to achieve in MSIX.

I have now tried to take a WinUI3 app and deploy it with MSI using Wix, and again, nothing works - the app works fine in Visual Studio but crashes after being installed with what looks like this: #7163. The app is utterly useless without a working installer, if we can't get the code to run after being installed we're nowhere.

As per #2500 (comment) above I feel winui3 is still alpha quality code, and this is almost 4 years after this bug was opened. Going from nothing to something absolutely shouldn't take this long or involve this much effort.

[felpsey]

I have now tried to take a WinUI3 app and deploy it with MSI using Wix, and again, nothing works - the app works fine in Visual Studio but crashes after being installed with what looks like this: #7163. The app is utterly useless without a working installer, if we can't get the code to run after being installed we're nowhere.

I can corroborate after spending hours debugging.

Why has Microsoft/WinUI 3 team blatantly ignored this thread for over 4 years?