.Net 6 + WinUI 3 + UWP

[Lorymi]

Please respect the wishes of users.
Please use the Windows Phone experience and do not immerse UWP to death

With the advent of Windows 11 and the implementation of native Android applications on Windows, I'm happy about this, but you practically limited the development of .NET desktop On the other hand, you removed UWP from the WinUI 3 roadmap

The development of WPF has been delayed for many years..

What the hell is this?

What we want .Net 6 + WinUI 3 + UWP

[ghost]

What we want .Net 6 + WinUI 3 + UWP

I hope here "WE" doesn't refer the 12 people on earth who is doing "UWP". LOL

Windows 11 Android apps have literally KILLED any reasons that BARELY existed for developing "UWP apps" on desktop. why each time it's the same 2/3 people again and again who cries once every month for this !

UWP folks should enjoy their 1 or whatever number of year existence on HoloLens and Xbox they still have till "Win32 AppContainer" apps reach there.

[ccarlo88]

I hope here "WE" doesn't refer the 12 people on earth who is doing "UWP". LOL

Funny, I can count only 5 thumbs up against 38 thumbs down. So based on basic math, there are 7.6x more people interested in UWP. 😄

[ghost]

who is doing "UWP". LOL

interested in UWP. 😄

bad defense. Doing was the term used. "interested" or "mere interests" or "mere virtual thumbs ups" in any matter or subject doesn't translate to Doing. Indeed pretty Funny.

[axodox]

@pjmlp Please note that UWP is still used on Xbox and HoloLens. The deprecated stuff on HoloLens is the use of WinRT Mixed Reality APIs, which are being replaced by OpenXR, but it is still UWP. Apps (but not games) still use UWP on the Xbox. Since it is not likely that these will get the old, depreceted Win32 shell on them, what is more likely that Windows App SDK will support UWP like targets later, and for most purposes they will be UWP under a different name.

MS is rebranding like it did with Windows 7 and Vista. People think UWP is still very bad, so MS renames it to give it a second chance. The ability to use WinRT in desktop apps were there for years, as was XAML Islands. It was also possible to package desktop apps to MSIX, you already could write apps which use their own "UWP" XAML UI on the desktop.

Now that all of those works, MS decided to pack it up into a big box, decouple it more from the OS, and stamp Windows App SDK sticker on it. At least that is what I have seen.

[pjmlp]

Anyone that cares about games should move into the Win32 GDK, as for apps on XBox, did anyone actually got any money out of them?

Those poor folks are going to get burned yet again with the AppSDK, one just needs to track down the increasing number of issues and corner cases popping left and righ every week.

Microsoft should stop acting as if we don't anything better than rewrite our applications every year.

[axodox]

I think the steaming apps do generate money and they need some app API, even if it is 90% a WebView, so MS will need to provide some app platform for Xbox, be it UWP, PWA or otherwise.

It needs to be there even if it is just for only 10 popular streaming apps, as if they are used by the users and are there on PlayStation they need a platform for apps for competitiveness. If devs need to use Direct2D and COM directly for their 2D UI, they won't be made. - I am not developing for Xbox so no experience with GDK, but since it is for games, I expect it uses low level APIs for rendering.

[maxkatz6]

WinUI 3 for UWP is still kind of planned in the future, but without any roadmap promises, as we can see from MS comments in random places.
See #989 (comment)

[Lorymi]

I saw this.
Microsoft is known as a software giant
But why this software giant not hire more developers and programmers to develop both WPF and UWP together?
Why does Microsoft always introduce a technology or platform and obsolete it a few years later?
I feel that it will obsolete ASP in the next two years and introduce a new system again 😐😂

[robloo]

Why did they fragment the WPF and UWP Xaml to begin with. This whole situation is a masterclass in how not to run a company.

[pjmlp]

@robloo I think the political feuds that we from outside know between WinDev and DevDiv are to blame for that.

It has always been like that when the focus switches from .NET to C++, or back into .NET, since Visual Studio.NET was introduced.

Or just look how they killed C++/CX without any consideration for our work, to this day editing IDL files alongside C++/WinRT feels like we are back in Visual C++ 6.0 and early COM days, early 2000's.

[robloo]

Yes, Microsofts politics and team silos certainly is a primary factor. Lack of leadership vision at a high enough level is another. Terry wasn't liked enough to bring things to fruition but I do think he was on the right track before being pushed out.

Edit: Of course the mistake was still forcing people to use UWP when it wasn't ready and dropping existing tech. Had development continued and concepts like WinUI3 allowed at the time we would have had a different outcome.

[Pinox]

The reality is the right people at Microsoft is not paying attention to this. By the right people I mean the people that can throw money at the problem not the employees that is currently working on MAUI / .NET / Xamarin etc,

The Windows Store is only coming right now that MS has realized you need to listen to many stakeholders and build a business model that is all inclusive. Most importantly you need a good team that has experience in building quality apps to build the MS Store. I think everyone is hopeful and excited to finally have a MS Store that works and cater for diverse interest groups.

Common sense has prevailed in Windows 10X and rather than fragment the market with another separate OS , MS is making the right decisions to rather incorporate into the existing OS , therefor Windows 11.

I have personally asked the question in the past why can't .net core be integrated into everything including Xamarin and why can't we have a performant core that is lightweight. (I posted this question on a github issue) as I'm no expert here but it's just logical to me. The answers I received ranged from there is not a common BCL to this is not worth it , too much work etc. What do we have today in .net 6 - we have progress on something that is fairly obvious to most and that makes alot of people excited.

So , if we look at the UWP haters (including some MS employees ) they will say UWP was never embraced by the community and that is true , but there are reasons that UWP was not fully embraced by devs

1. Terrible MS Store experience
2. Terrible app submission experience (takes days to get your app approved and published)
3. Walled garden by MS Store
4. Underperforming API's that is slow (eg file saving)
5. performance is not a feature in API surface of UWP
6. higher cost to develop, many traditional 3rd party vendors offering basic controls like a proper datagrid that is non existent in UWP

The list can go on and on and they are all valid reasons for not supporting UWP., but now that MS is seeing the light (.NET 6 MAUI and renewed MS Store) does it mean the core of UWP is bad. I don't think so , you remove all the friction points listed above and you can have a great cross device solution. (note that I'm not saying cross platform but cross device)

If you ask me for a wish list it would be this :

• .Net 6 + WinUI 3 + UWP that can be compiled with NativeAOT
• tight integration with cross devices such as: Xbox , Rasberry Pi (IOT) where I can start incorporating AI and ML /voice recognition /
  camera recognition into my main app,
• Native speed on devices to run AI / ML solutions on device.
• Powerful graphics core if I want to incorporate something visually cool ( think Unity as example.)
• .NET MAUI for my cross platform (mobile device) needs.
• Blazor for my cross platform "desktop" needs.
• new opensource controls like advanced datagrid (therefor less reliance on costly third party controls.)

Most of the building blocks for the above are already there , we just need someone at MS with vision to reorganize / unite the separate pieces. It's like someone at MS has decided that UWP is "bad" and therefor no more development when in fact there is a golden opportunity to make right (fix the friction points) and have an awesome cross device platform that is build for the future.

IOT is the future. (input sensors )
Camera / Video inputs are the future.
AI / ML are the future.
Native cross device execution with build in redundancy is the future. (without permanent internet connection - think remote sqlite ) - is the future.
Powerful immersive graphics is the future.
2D /3D visualizations are the future.
and so I can go on.

Who is the leader in MS that is taking ownership for IOT , Cross device AI /ML. ????

The point is this, just like .NET 6 was supposedly not possible a couple of years ago. It looks like it's going to be a roaring success and many devs are super excited about it. You need someone at MS to see the big picture and throw money at the problem and make it happen as someone did in MS Store's case.

When MS pays $7.5 billion for Github , the problem is not money , the problem is vision and someone driving this process on a board level. MS has come a long way in correcting their mistakes and I personally believe alienating developers yet again by lack of urgency and most notably lack of vision is not very comforting when it's fairly obvious to anyone else.

[robloo]

the problem is vision and someone driving this process

Exactly! no one with power is driving a cohesive XAML UI layer. WPF team was disbanded and then the tech rolled into the OS/Windows Team for UWP. All that was necessary so non managed code could use it; however, the .NET team at the time should have kept control. Now the silos and teams within Microsoft prevented it from ever taking off. I'm skeptical of WinUI3 itself honestly.

You also seem positive about MAUI. Unfortunately, I think this is just one more mistake on Microsoft's part. As it is driven by the same .NET team it should not deviate in so many ways from WPF. It is basically WinForms in terms of power and controls - XAML is heavily underutilized.

[Pinox]

the reason I like MAUI is that it simplifies project structures and finally we can have one project with all the different device targets.
This and the fact that c# language enhancements ( minimalistic code ) should make it super easy for beginners to start , this is all good for the ecosystem that is very important to drive growth. Also some notable enhancements in MAUI / .NET that I like:

• one BCL finally - so there is a collective effort by MS engineering teams.
• performant base - leveraging from .net core where performance is a feature.
• HOT RELOAD with VS22 - productivity in .NET has always been terrible , I hope this can significantly improve our overall
  iteration cycles.
• COM interop - hopefully we can start interacting again with office apps like excel directly without going through a cloud api (
  cloud is fine for basic needs but advanced scenarios requires direct link)
• BLAZOR desktop with webview - awesome tech without using Electron.
• BLAZOR mobile - rendered by using native XF
• CLI tooling across .NET

So the MAUI effort is good in my opinion but the cross device (windows devices / UWP ) effort is non existent. Just like MS employed a new team to write the new MS Store I would create a new team to drive cross device tech in parallel to the MAUI effort. The problem is simply lack of resources and vision from a board level. I mean we all know that that UWP / .NET 5 is possible as per #105 but the will is not there from a board level within MS to make this happen.

The moral of the story never leave your developers behind always give them a good migration path forward and you will have the respect of the community. Look at the Xamarin team within MS, it's build into their DNA by default, not a single Xamarin Forms 5 dev will be left behind with the move to MAUI. Look at the Blazor team, they listen to the community and then solve the problems, they actively drive innovation and Blazor forward. As someone once said "You show me the team and I'll show you their future".

The DNA of the old MS is to always do their own thing, never listen to the community and then they wonder why things don't work out. MS has been working hard to change that old mentality and I can only hope that there is someone in MS with integrity that is fighting to remind those in power that this is indeed a worthy effort.

[robloo]

I agree with several of your points. Single project, common BCL, etc. is amazing. These aren't really tied directly to MAUI though and could have been done with any UI layer. The design of MAUI itself is deficient. You cant even put an image inside a button with the default implementation. It is notoriously diffuclt to work with and get consistent interfaces on all platforms. Bugs have been an issue. It is just a fundamentally inferior design compared to what UWP provided even for mobile devices. Uno Platform has proven it was always possible to do it correctly, Xamarin at the time went and did their own thing though which isn't good. Fragmentation, and inferior power tech is the result. They should have taken UWP itself cross platform exactly like Uno Platform does.

[pjmlp]

Exactly, wrapping Catalyst for macOS seems like a shortcut to me, specially given the restrictions of Catalyst versus Cocoa or SwiftUI.

[robloo]

I fully agree with the spirit of this discussion. The issue here is simple: Microsoft promised UWP as the future and then proceeded to burn everyone who invested in it. It hasn't been updated for years. Microsoft's pattern is clear and they did the same to Win32/WPF/SilverLight/WinForms developers with UWP itself that they ironically are trying to fix by doing more of the same.

The incompetence is staggering and it makes no business sense to continue following this path. I have a large UWP app, I will be moving it away from Microsoft UI tech as soon as possible. I suggest everyone do the same.

[pjmlp]

I am mostly a .NET dev on the Microsoft stack, yet C++ is still relevant to me, and a bet lots of us, as many Microsoft teams refuse to make .NET APis to their beloved C++ APIs.

It was specially infuriating that DirectX team refuses to make UWP components, despite UWP also being COM based, so we are dependent on third parties for Microsoft APIs.

Well at least, C++/CX made wrapping C++ less painful, as it was the first time that Microsoft finally offered some tooling similar to C++ Builder, or .NET for that matter (C++/CLI never had GUI tooling support like C++/CX).

And what they do? They just killed it and make us code in C++ with an ATL like framework, like in the days before .NET was created.

I am not so drastic as yourself, but I am advising people on .NET to just stay on WPF/Forms, and if they are into C++, better jump into Qt or C++ Builder if within their budgets.

[robloo]

Good points: to be clear I'm only recommending those using a XAML UI layer to investigate other tech. I'm also heavily biased towards C# so ignore me for those using C++ as it's a different situation.

AvaloniaUI is far better positioned to come out top in the long run. WPF is now too old although now that its getting NET5/6 support even before UWP it has life left. Of course you can also stay the course and migrate to WinUI3 with .NET (no UWP) but you inevitably will encounter the same issues a few years down the road. As someone who started with WinForms and even VB6, I'm tired of this cycle and there finally is a way out using 3rd party tech. Its too much of an expense and headache to follow Microsoft in this space.

The .NET team, except for MAUI, is on the right track. C# is still an amazing productive language I'm not looking to move away from. Its always been the UI layer and cross platform support that is the hang-up. Both Avalonia and Uno offer alternatives.

[Lorymi]

Does anyone know who in Microsoft is responsible for the .NET desktop (UWP, WPF ...) map? Please mention them in this conversation.

[ghost]

I'm skeptical of WinUI3 itself honestly. WinUI3 with .NET (no UWP) but you inevitably will encounter the same issues a few years down the road. As someone who started with WinForms and even VB6, I'm tired of this cycle and there finally is a way out using 3rd party tech. Its too much of an expense and headache to follow Microsoft in this space.

i'm no expert. thinking a little tells me WinUI 3 is the ultimate UI tech from MS/it won't be dropped in a few years. so is WinRT.

=> why ?
Because Both WinRT and WinUI 3 are based on the same core native technology that is COM. [COM here means COM version 2, introduced in windows 8 with IInspectable/winRT types]

The WinUI 3 framework is a set of WinRT components.
https://blogs.windows.com/windowsdeveloper/2020/07/07/a-deep-dive-into-winui-3-in-desktop-apps/

=> what's so special about COM?
languages agnostic/futures proof. C based Win32 api are becoming irrelevant for new devs

=> MFC/ATL were dropped some years later so?
Because of .NET framework and it's shiny new winforms/wpf at that time.
1990-2000 were the time people were using C based win32 apis. COM was not so much needed there. C was king.

=> eh, WinForms and WPF were also based on same .NET framwork so?
data binding, media services, templates, animations, direct3D, and alternative input, xaml , web browser plugin all that winfroms couldn't do. tbf it was so simpler that a new framework release was obvious.

most probably need of native/managed code interop c++/cli was another of them.

=> huh, so why UWP ?
around 2010 when suddenly Smartphone Apps were blowing up , some souls at MS assumed that Desktop software were dead, they felt the need for less dense UI for windows phones aka metro apps hence UWP apps were born :)

=> what's the gurantee that WinUI 3 won't be dropped in a few years?
[anything that's not C, must be COM based, heck if you dig enough you can even interact with ASM in COM :)]
unlike MFC => ATL => winform => wpf => uwp these complete architectural changes/shifts , winui 3's core technology will always be the same and winui3 is extensible unlike these+will be open sourced.

for the same COM based reason, WinRT is the ultimate api surface. CsCOM/CsWinRT should have happened in 2002, however it's never too late.

All the new/modern WindowsAppSDK inventions/apis are COM based (Dynamic Dependenices , Push Notification, App LifeCycles/MRT Core and upcoming windowing APIs)

You also seem positive about MAUI. Unfortunately, I think this is just one more mistake on Microsoft's part. As it is driven by the same .NET team it should not deviate in so many ways from WPF. It is basically WinForms in terms of power and controls - XAML is heavily underutilized.

can't comment on MAUI haven't used yet. in a few years, at best it will be renamed to something else. because it's open source and closs-platfrom. those cross-plat devs won't forgive sudden changes in 2/3 years and MS knows that.

TL;DR : WinUI 3 and WinRT are the ultimate combo ; the combo that should've been there since 2000. It just took MS 20 years to realize the correct way to do things :)

[pjmlp]

Well, the team enjoys COM so much, that they deprecated C++/CX and replaced the experience with a time travel to the early days of IDL files editing experience in Notepad, compiling them in the command line with midl.exe and making use of ATL wrappers, and to top that they gave us two bindings, C++/WinRT and WIL, because while the tooling hasn't been updated since 2000, there are not enough COM smart pointers to choose from.

[ghost]

I prefer languages' idiomatic library bindings rather than extension bindings, so that's much natural. from 2000 to 2014 .NeT FrAmEwOrK was windows' son, it's not the case anymore, that's maybe the logical reason toolings are that from 2000. also proper tooling support is an IDE's responsibilities. as long as a compiler is present anyone can build any COM projections/bindings. eg, swift/winrt

one is COM binding another one is same old C interop. I guess wil should only be used by kmdf drivers devs.

there are not enough COM smart pointers to choose from.

directly accessing and managing lang's std libs objects/data groups is OO Programming. If I'm not mistaken, smart pointers translates to interface pointers in COM programming. and then there's ref counts and hresults. by design, COM is one kind of it's own.

[juwens]

Practically i support the wish.

But, i think it's not necessary anymore, because MS added a lot of glue-technologies to create Apps wich behave like "UWP-Apps" from regular .Net Applications.

Or rather, which Part of UWP do you want to use in .Net 6?

Because UWP is such a ambiguous term.

What somebody can mean, when using the term "UWP":

• a .Net Runtime, compiled for/running on WinRT
• the WinRT-API-Surface (eg. Windows.Storage. Windows.Management.Deployment.PackageManager or Windows.Storage.StorageFolder)
• UWP-Control-Library (eg. System.Windows.Window, Label, Button, etc.)
• UWP-Application-Class System.Windows.Application
• Packaging aka MSIX

When i take a look at the different aspects of UWP:

• UWP-/WinRT-API from .Net 5, ✅ already available (via TargetFramework in csproj see link)
• Packaging/Installation/Packages-AppData-Folder: ✅ already available (via Package Project, just add your .Net 5 Project as a reference to the package project)
• Controls: WinUI 3 is the future of Controls-Libraray for Desktop-Developement (IIRC they are written in C++ on the WinRT-API level)

[robloo]

@juwens This sounds good but there are still some issues. Off the top of my head:

1. CsWinRT due to architecture differences will never have as good of performance
2. NativeAOT is missing from the story so far. UWP natively compiles which is a noticeable performance advantage -- and it help with obfuscation.
3. There are still several things missing in WinUI3 that prevent migration: inking, map control, etc.

They are not at feature party and it isnt a smooth migration going from UWP app model to .NET and WinUI3. It does seem we have no choice at this point so its a waiting game to see when enough features come over to justify a rewrite. Still planning to move away from Microsoft long term myself though.

[DjArt]

@juwens, You missed one important detail: Application lifetime. It's really important thing, that allow apps to be "lighter" than any another apps(background activity w/o loading UI as example) and secure for end user.

[juwens]

@juwens, You missed one important detail: Application lifetime. It's really important thing, that allow apps to be "lighter" than any another apps(background activity w/o loading UI as example) and secure for end user.

yes i miss that too. I created a small package (msix) that contains two .net 5 apps.
The msix is over 100MB for one tiny wpf app and one tiny console app.
But because they are two separate self contained apps, the msix contains two frameworks (one framework for every app).

My suggestion to Imo Landwert was: deploy .NEt Framework via Windows Update.
Or that they should use the msix framework dependencies mechanism, which is used by regular UWP apps. So the appinstaller could have installed the runtime, and the msix wouldn't need to contain the runtime.

Essentially all needed tools (appinstaller + msix) are available and stable and built into windows/appinstaller already.
They only need to push the framework to the needed server location, where appinstaller can find it.

example of a AppManifest.xml with framework dependency (look for "Microsoft.NET.Native.Runtime.2.1"):

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3" xmlns:uap6="http://schemas.microsoft.com/appx/manifest/uap/windows10/6" IgnorableNamespaces="uap mp uap3 uap6 build" xmlns:build="http://schemas.microsoft.com/developer/appx/2015/build">
  <Identity Name="Microsoft.XAMLControlsGallery.Debug" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="1.2.16.0" ProcessorArchitecture="x64" />
  <mp:PhoneIdentity PhoneProductId="1DE51B2F-78B7-4c23-9045-66DD91CDFE62" PhonePublisherId="00000000-0000-0000-0000-000000000000" />
  <Properties>
    <DisplayName>XAML Controls Gallery (Debug)</DisplayName>
    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
    <Logo>Assets\Tiles\StoreLogo-sdk.png</Logo>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17134.0" MaxVersionTested="10.0.22200.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.22929.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.UI.Xaml.2.6" MinVersion="2.62107.6002.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.NET.Native.Framework.Debug.2.1" MinVersion="2.1.26424.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.NET.Native.Runtime.2.1" MinVersion="2.1.26424.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.29231.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>

[juwens]

i mean, you can install Net 5 or 6 manually on the target machine once.
Then you can create a framework dependent .Net 6 app, which should be relatively small again.

[ianier]

I have a large UWP app too and I feel confused (not to say abandoned by Microsoft) too like the other people in this discussion.
While sticking to a specific technology isn't my priority, I'd simply like to know what the migration path for my app is (or will be) to whatever technology Microsoft decides UWP should be replaced with.

[jonasnordlund]

I understand the concerns about UWP but I think Microsoft painted themselves into a corner both platform-wise and architecture-wise:

Platform: Windows Phone was not a success and Apple essentially owns the tablet space, and thus fell an important pillar of UWP because of the very small cross-section of apps that must run on both PC and Xbox.

Architecture: UWP is its own thing in the .NET world because of all the hoops Microsoft had to go through to make .NET Native a reality, so it becomes this black sheep that does not follow along the .NET Core journey that was later to evolve into .NET 5 and soon .NET 6. It becomes frozen in time and a lot of effort is needed to push it forward. Effort that might have been warranted if Windows Phone and Windows Tablet with custom operating systems were things, but now...?

There's a certain element of irony in that the "Universal Windows Platform" became anything but universal. The true universal platform on Windows is .NET 5+ where you can build business apps and games, for Windows, Android, macOS, iOS and Linux, for smartphones and tables (that are actually alive!), for desktops and servers,

So, the true successor to UWP is WinUI 3 because it's designed to no longer be hamstrung by the architecture issues above and be able to better follow along the greatest and latest in Windows.

I must say I don't quite understand the original topic here because WinUI 3 is not a control library like WinUI 2: it's an entire framework like UWP was. It's not that it doesn't "want" UWP, it doesn't even need it. So instead of .NET 6 + WinUI 3 + UWP we are getting .NET 6 + Windows App SDK (where WinUI 3 is its UX stack). UWP users should feel quite at home and in many cases it's mostly about renaming namespaces.

As far as I can tell, the migration path should be towards .NET (or C++ if you fancy, or even Rust!) and Windows App SDK. The only remaining issues I can see are performance (but do we have enough of a sample size of WinUI 3 apps to even compare to, or is this a theoretical argument?) and obfuscation by native compilation but there are several tools to help here.

[ianier]

@ccarlo88 It's just a matter of time until AOT in .NET 7 works for other project types. Personally I don't care too much about AOT because the performance-critical parts of my app are written in C++/WinRT (migrated from C++/CX, which BTW is going the same path to obsolescence as UWP, though the transition to C++/WinRT is really smooth).
I'd just wish UWP app migration could be done incrementally rather than through the big bang approach MS came up with, so we developers could spread the migration cost over time. The situation today for many UWP apps is that migrating them to WinUI 3 may just not be worth it as compared to porting them to other platforms/frameworks.

[pjmlp]

It is the first time I see the crap development experience dealing with IDL files and C++ code generation, unchanged since COM glory days (20 years ago), being referred to as really smooth.

[ianier]

@pjmlp: I said the transition was smooth, and indeed it is: you can just link C++/WinRT into an existing C++/CX or ABI project and move the code at your own pace across releases.
It's clear that we need a better way to bring native C++ code to .NET. The now-also-almost-deprecated C++/CLI was IMHO pretty good in that sense.

[pjmlp]

Having rewritten Windows Runtime components from C++/CX, while having to deal with IDL crap, was anything but smooth.

In fact, the way this whole issue has been managed by Microsoft is one reason why I went back to ASP.NET as my main source of income.

[ianier]

I don't have such strong feelings about C++/WinRT, but I totally get your point.

[pubtom]

If you need .NET>5 in UWP please give a vote on this: https://developercommunity.visualstudio.com/t/Add-NET-678-support-to-UWP/1596483

[LancerComet]

The dev experience using Windows App SDK (WinUI3 + .NET 7) still can't catch up with using UWP.

It will work around the time they announce the next framework to replace it. In the meantime UWP is fine for many things.

Indeed, UWP looks good to me so far

[robloo]

Caution with UWP for new projects. Several 3rd party libraries are dropping .net standard 2.0 support. You will be locked into a small, unchanging ecosystem (never any fixes, slowly loosing compatibility). Highly recommend finding something else so you don't put yourself in a corner.

[ianier]

Caution with UWP for new projects.

I bet most (if not all) of us in this thread have existing apps.

My primary concern as a developer is to get features released to my customers. Dealing with technology is just a means to get there, not a goal. So the problem I have is that the migration path MS is offering right now just "gets in the middle" while not adding much value, rather the opposite!

The day the benefits of moving an existing app out of UWP outweigh the costs we devs will jump on the bandwagon for sure.

[axodox]

Caution with UWP for new projects. Several 3rd party libraries are dropping .net standard 2.0 support. You will be locked into a small, unchanging ecosystem (never any fixes, slowly loosing compatibility). Highly recommend finding something else so you don't put yourself in a corner.

Ironically, I have a C++ only UWP app, which still has full support, I mean I can use the latest C++ language etc. It is just weird since when I have started I felt that C++ support were pretty limited compared to dotnet.

[ianier]

I have a C++ only UWP app

3rd-party library support is still an issue. Look for example at all the work we did to port TensorFlow to UWP using vcpkg which works but ended nowhere due to lack of vendor support.

[dgellow]

Really good news: https://devblogs.microsoft.com/ifdef-windows/preview-uwp-support-for-dotnet-9-native-aot/

We’re introducing the initial preview UWP (Universal Windows Platform) support for .NET 9, providing a path for existing UWP developers to modernize their apps with the latest .NET and Native AOT.

🎉