Probably a far off thing, but Blend needs to be overhauled and needs a design focused workflow.

The XAML designer needs to be robust, and powerful.

Some way to visualise the layered structure of the page/window, especially important with elevated controls.

Ways to visualise UI elements outside of a page, such as an individual control/template.

Display control customisations that are made for CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, all within the designer.

Combined designers for XAML mixed with WinForms, WPF, MFC, and all the other Frameworks that WinUI Desktop will work with.

Good ways to import and export XAML, so designers can work in Blend isolated from the main app, and then hand them to the development teams to bring into the app.

Better visualisation and listing of system resources, as well as great ways to pull out those global resources that can be light styled to override the defaults, and the design surface reflects those changes in real time.

Better ways to test for different DPI scaling with apps involving WinForms, MFC etc.

Templates for new controls, customised theme resource dictionaries, integrate the Fluent Theme Editor, templates for supported app combinations (Win32 MFC with Xaml UI, etc) .

Templates for shell integration points, like file pickers, task tray flyouts.

Those are just a few thoughts...

My thoughts are as follows:

1. MSIX is all well and good, but I still use good old MSI to install more complex applications that require features that MSIX doesn't support. I am also leery to use MSIX because of how expensive the required Authenticode certificates are. (I can easily sign my code with a self-signed cert, which I believe is just as secure as one I buy from a firm, but then Windows won't load it. Windows will happily accept a self-signed MSI file, however.) As long as I can use WinUI 3 from a MSI-based application, I'm happy.
2. A better XAML designer would be greatly appreciated, but I don't need the added complexity of integrating the WinUI XAML and WinForms/WPF designers into one. I'm perfectly OK with flip-flopping between different tabs in VS.
3. As I commented earlier, decoupling the XBF compiler from the C# and Visual Basic project systems would be very useful. (It would be even better if the XBF compiler source, or documentation sufficient to recreate it, was released, but I don't know how likely that is to happen.)
4. Better support for C++/WinRT and MIDL 3 in the C++ project system. Currently, the project support for using C++/WinRT is brittle and clunky. (For example, if you change the namespace in the IDL file — which is often required if there is a dot in the project name that you want to use in namespaces, as the template converts those to underscores automatically — your project will fail to compile, and fixing the problem in my experience requires moving the *.h and *.cpp files aside, regenerating them from scratch, copying over code, and then unloading and editing the vcxproj file to fix the nesting.) As much as I'd like to use something more modern and flexible than vcxproj, I can't do so due to the hard dependency the XBF compiler has on it.

If anything else comes up, I'll be sure to post it here. Thanks!

1. What I'm wondering here, is... Well, will I need to use the namespace prefix like <winui:Listview or <controls:listview or whatever the devs decides? I think it would be much better, if possible, to use have the same experience as now, just <Listview, no prefix.
   Prefix is ok, and awesome, for just a few controls. But when you start using all over the place, this makes XAML reading a nightmare and very.
   Doesn't make sense to use a namespace prefix, as it won't be possible to use Windows.UI.Xaml.Controls and as WinUI will be the default choice.

2. Right now I don't even use XAML designer. I literally disable in the settings. XAML Designer it's sluggish, and need a better support. It was good for WPF, but not UWP, specially if you want to do responsive design, dealing with pages, showing data, etc.
   This is probably a feedback for the far future, but I think is a good feedback to look at. WPF designer is much faster.
   Is this because of sandbox or what?

3. Would be interesting a tool to do a migration. Especially as it may have a few compat problems with updated WinUI 3.0 controls, like ScrollViewer. So if there is a tool, it would need to at least show possible warnings on these updated/rewritten controls.

1. We need robust, xaml code editor with IntelliSense separated from designer.
   Most of the time I'm just writing xaml code like C#. Currently, the code editor is slow and fragile, explained in my previous comment. The IntelliSense experience is also quite simple. No quick documentation info, no member renaming.
2. Design data support for x:Bind may be quite hard, as I'm writing complex helper in function bindings. But things can be better if xaml built-in functionals can replace some helpers.
3. I want much more free combinations of packaging model for my applications. May be off-topic, but I can't find anywhere to feedback to the app model team.

TL;DR I want an app model support arbitary instance co-existance. Even the same version can run with difference data/option set, like Visual Studio hives. Currently the only solution seems to be xcopy.

Can anybody tell me how to collapse this?

First, I'm also using the app I'm developing daily(and use>>debug for most days). So make the dev build co-existing with stable build will help me a lot. Currently I have to increase the version number, package a debug msix, update installed package version to debug.
During different debug phases, I'll want different capability. For complex real world data, I want the debug instance share the data with stable one. For arbitary fake data, I want isolation though. This is theoretically solved by accessing data using folder picker, but it's so sorry that SQLite in UWP doesn't support that, and there's no other embedded ACID engine as I know.

Oh, and another thing. I would really, really appreciate it if something could be done about how vcxproj requires the use of packages.config for NuGet package references. WinUI is distributed as a NuGet package, as is C++/WinRT and other key components. I am really don't like using packages.config. PackageReference is much more efficient (and it doesn't result in a broken build if you move the vcxproj into a different directory). It actually does work when used from a vcxproj, as long as the Restore target is run at the appropriate time. (This is because the vcxproj targets indirectly import the PackageReference restore machinery for non-SDK C# projects.) I have written a set of targets that automatically run the Restore target when the set of PackageReference items has changed, as VS won't do this itself (yet). Unfortunately, the NuGet system knows nothing about this, and as such it attempts to add a packages.config file when I add a C++/WinRT file template. This causes all sorts of havoc, resulting in an exception being thrown and a broken project file. I am not certain how best to resolve this, but I would really appreciate it if it could be at least looked at before WinUI 3 is released. Thanks!

It would be nice, if WinUI support new project sdk - Microsoft.NET.Sdk or MSBuild.Sdk.Extras.
Old style csproj files are hard to maintain. And we can't use multiple TargetFrameworks with it, which could be useful for migration to WinUI.

Why no F# support?

Should Azure DevOps and Visual Studio App Center functionality be discussed here?

Like @vitorgrs , I prefer native controls without namespace prefix, it add "noise" to the code. And it helps to see which are native controls, and which are 3rd party.

A migration tool would be nice, of course. If it works with the big 3rd party providers (Telerik, DevExpress,...) that would already be a big thing.

Templates

Is there interest/need for the previous versions of UWP XAML templates to remain in VS new project flow?

From my side there's no need to keep the templates. But could it be that UWP has a Control that is not in WinUI? If that could happen, then this could be a valid reason to build a traditional UWP app and migrate it to WinUI when the required Control is there. Then the template might be needed.

Maybe it's also confusing for developers if you have built an app and you can't create it anymore with the latest Visual Studio version.

But personally, I don't have interest to keep the templates

How can we help you be more efficient or successful with regards to templates and components in Visual Studio?

To me this looks great for UWP. Now I want to see the same for Win32. :)

Is this walk through helpful and would you like to see more of this as scenarios take shape?

Yes, definitely. This walk through is very helpful to understand what the future could and should look like. I would like to see more of this.

Migration

Would it be beneficial If we provided a migration tool that automated steps 1-3?

Definitely. Maybe a little Visual Studio Extension would be a great option for this migration. I can also think of something like a "WinUI Compatibility Analyzer" that outputs what can be migrated and what not. Something similar to the .NET portability analyzer.

What libraries are you using from outside of the Native Windows 10 control set?

Usually Telerik DataGrid and Community Toolkit

In what ways can we assist with migration that we are currently not thinking about?

If you open a UWP app in Visual Studio that has a lower version than the Win SDK you've installed, Visual Studio migrates it for you. Maybe you should think about something like that for the WinUI migration too. I'm not sure, but it's something to keep in mind. Especially when Visual Studio doesn't have the normal UWP templates anymore, it could be confusing for developers to have an application that you can't create with a template.

Others

Like mentioned already in other comments, I think it's time to switch to SDK-style .csproj files.

add winui 3.0 templates to windows template studio.

WinUI in Desktop Apps

WinUI in Desktop will allow developers to use the Windows UI Library on a Desktop Application model. @marb2000 is working on more detailed discussion post in the coming weeks. Feel free to use this thread until then for suggestions.

As a .net developer, this is the part I am most interested in.

Templates

• Is there interest/need for the previous versions of UWP XAML templates to remain in VS new project flow?

Depending on the number of templates. If the number is low (eg. only the "Blank App (Universal Windows)" per language, so 1 in the case of c#), the noise is low and can be supported. But if it involves more than a few templates, then do not include them by default and add an optional VS install component to add them.

• How can we help you be more efficient or successful with regards to templates and components in Visual Studio?

Keep a real blank template with no scaffolding (better for tutorials). Take a peek at what asp.net core is doing, there is a lot of changes they have done in their new project experience. Basically, you choose a generic template "App (UWP WinUI)", then a second screen, specific to your app model allows you to choose from different templates. Use this step to also choose the minimum and target platform version (so no additional step). You can add an option to create the app packaging project directly for example.

Also provide good support for components in the toolbox between projects. New controls should be displayed immediately in the toolbox, grouped by projects. Perhaps support for designer icons to help distinguish them.

• Is this walk through helpful and would you like to see more of this as scenarios take shape?

Yes

Language Support

• Would it be beneficial If we provided a migration tool that automated steps 1-3?

A good documentation (one page with clear steps) should be enough. If everything can be done from within VS without editing the csproj by hand, I suggest to only add a documentation page describing the steps.

If you decide (and I hope you will do) to switch to the new csproj format, then a migration tool will certainly be required, as the migration will require editing the csproj file.

Packaging

MSIX is the modern packaging method for all apps. For WinUI in Win32 should we support ClickOnce? What other packaging methods should we include support for? Especially for WinUI in Win32

Compare the differences between clickonce and msix deployment:

1. the App Installer feature does not offer the same experience on older windows versions
2. MSIX requires a valid signed package (internal or public). Clickonce supports self-signed packages.
3. the package model has some limitations, mostly caused by the isolated environment (no local appdata access for example, no elevated operation).

For me the most annoying problem is the 2. We typically have clickonce apps which are deployed internally with computers not registered with a domain. So for these kind of apps it will require us to sign the package with a valid public signing certificate.

It's hard to anticipate all the differences between these two frameworks, as the Appx packaging format is often only advertised for apps targeting the Store, and when we see limitations, we don't always know if they apply also to the Web distribution format.

• Designer Experience

Performances, performances, performances, and support for large solutions with a lot of projects.

Will the WinUI version of the Windows 10 SDK and the WinUI Xaml designer, be made open source?

Will we be able to post requests for the design time workflow, and experience?

Will the SDK follow a similar release cadence as WinUI's nuget releases?

Some additional pain:
improve the managed-unmanaged mixing debug experience.
Currently when exception happens in unmanaged code, COMException is shown in managed debug site. Things may be worse if the call stack crosses managed/unmanaged boundary more than 1 time.
Comparing to WPF, the managed call stack is always available, and the thrown exception carries a string that's helpful for debug.
I know the unmanaged world and COM model isn't so convenient as managed. But at least, when an exception(erroneous HResult) is thrown by the framework, I want necessary information to locate the line of code from the open sourced repo. The way can be manual, but should be deterministic.

We rely heavily on ClickOnce, so it would be nice to support for the short term. We would be willing to migrate to MSIX, but after similar features are offered.

As for templates, it would be nice to have one that provides boilerplate UI and code for a NavigationView and navigation.

Thx

We rely heavily on ClickOnce, so it would be nice to support for the short term. We would be willing to migrate to MSIX, but after similar features are offered.

As for templates, it would be nice to have one that provides boilerplate UI and code for a NavigationView and navigation.

Thx

The most common App "shell" structure and patterns - should be available as templates so developers can get up and running quickly. Microsoft's first party apps should be exemplars in these layouts and act as best practice in terms of behaviour, consistency, and adhearing the UI design norms for Fluent Design, and WinUI.

@shaggygi @mdtauk
For "most common App "shell" structure and patters" and "As for templates, it would be nice to have one that provides boilerplate UI and code for a NavigationView and navigation." there is the Windows Template Studio which is maintained and developed by both Microsoft and the Community. To quote its introduction:

Windows Template Studio (WTS) is a Visual Studio 2017 and 2019 Extension that accelerates the creation of new Universal Windows Platform (UWP) apps using a wizard-based experience. The resulting UWP project is well-formed, readable code that incorporates the latest Windows 10 features while implementing proven patterns and best practices.

@Felix-Dev will there eventually be WPF templates in addition to UWP?

@shaggygi There might be some good news for you! See this thread: While seemingly nothing is guaranteed at this point the idea of providing templates specifically for WPF projects is apparently being explored. As noted in the linked thread, there was a non-public sneak peek session called "Windows Template Studio - WPF Edition" hosted at Build 2019.

We’re using C++/WinRT. We don’t use the xaml designer or binding at the moment. But we will be creating controls at runtime and styling them possibly via UWP xaml. We will also need dialogs and modeless child Windows with xaml islands including docking/floating windows etc.

I've tried writing XAML for my C++ app and boy was the experience painful.

I've had to add many project properties which are undocumented and some other hacks to correctly generate everything and package it correctly.

For example:

• When creating a project to store my XAML pages into, I had to add <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> and <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform>, two project properties which are completely undocumented and only figured out by inspecting the new Terminal's source code.
• I had a cryptic "Could not create a new view because the main window has not yet been created" until I created and used an App class, which there is no way to in VS except creating a normal page and going into the properties of the XAML file in VS and changing it to an application definition, then adjusting the MIDL, source code and XAML file.
• I added the Microsoft.Toolkit.Win32.UI.XamlApplication NuGet package to create my application class and could not load it until I also added Microsoft.VCRTForwarders, again I found this when inspecting the Terminal's source, there's no indication about either package anywhere.
• The PRIs weren't getting merged into one until I added something in the .wapproj file, so it couldn't find my XAML resource.
• The XBF weren't working until I added <DisableEmbeddedXbf>false</DisableEmbeddedXbf> which surprisingly disables embedded XBF instead of enabling it. The only error I had was a XAML parse error with nothing pointing to me that the XBF files weren't working.
• maxVersionTested in my app manifest was totally ignored until I changed it all to lowercase, even though the instructions told to use the camel case version: maxVersionTested triggers build warning MicrosoftDocs/windows-dev-docs#1781 (comment)

Additionally, C++/WinRT was also being a pain in the ass:

• Each time I ran a incremental build, I had a [msg]redefinition [context]: MyClass for my custom classes which prevented me from building and did not go away until I ran a clean build which due to the C++/WinRT headers takes ages. That issue somehow magically went away midway through.
• Now when I run clean builds I get an error about missing headers. Hitting the build button a second time gets it working again.
• I had to write my own AppT<> class because of bad codegen from C++/WinRT. The Terminal app and XAML islands sample do the same, as if it was something the users will need to do instead the root issue being fixed.
• Changing anything in the MIDL files results in build errors until I do a clean build.

Even then, it still doesn't works unpackaged even when adding activatableClass stuff to my app manifest (something about not being able to find the XAML resource, like when I hadn't merged the PRIs), which is important for my app to support.

Migration

Automation for step 1-3 is defintely helpful especially since renaming namespaces on hundres of files is very time consuming and prone to errors. On top of that an compat analyzer would be nice just like the .net framework > .net core one which creates a report on how compatible the current codebase is and notes all the possible changes needed.

Tooling

As others have already said a more feature rich editor would be nice. Most of the time here at work XAML is done by hand and mostly use the designer as a guide on the rough skeleton on how the app looks like. Intellisense and smart refactorings would be really helpful, QoL things like CTRL + R + R for renaming things (e.g. Dependency properties or even the tag) for example especially when you tend to have a lot of custom UserControls and also GoTo Implementation and references. Roslyn analyzer support would be really good as well.

To expand on the namespacing improvements. It would be nice if somehow it's possible to have non prefix custom controls easier to do without adding a new XmlnsDefinitions to the default namespace, it declutters the markup imo and only would need prefixes when there's ambiguous controls found just like how classes work this would tie in nicely with GoTo implementation as well. Normally the name of the control and maybe hovering over it to show the full namespace would be sufficient to know where it comes from, you'd normally not use namespace aliases either on C# code unless it's needed.

Mostly on tooling it'd be nice if it behaves like the C# Editor to make refactorings less fragile or a hassle and navigating the markup easier. Aside from that as for the XAML language itself lessening the verbosity would be a nice too one example being Styling as discussed #62 and #279.

To expand on the namespacing improvements. It would be nice if somehow it's possible to have non prefix custom controls easier to do without adding a new XmlnsDefinitions to the default namespace, it declutters the markup imo and only would need prefixes when there's ambiguous controls found just like how classes work this would tie in nicely with GoTo implementation as well. Normally the name of the control and maybe hovering over it to show the full namespace would be sufficient to know where it comes from, you'd normally not use namespace aliases either on C# code unless it's needed.

I would like to think that the WinUI 3.0 version of the Page control would do away with the need to use a prefix for those controls. I guess this would be an SDK level thing.

Is it possible to not to change the namespaces when using WinUI?

One fix should be, that you can exclude Windows.UI.Xaml.* WinMD references from build. Now the build targets reference only the Unified WinMD aka. Windows.winmd, add an option in the targets to also refer individual WinMDs, that way, we can include or exclude the references based on the App we're building.

Is this the way, then there's no need to change namepaces, since it behaves like a .NET dll it can work with assembly redirects to a local version inside the package rather than the system supplied ones.

I know that method is specifically for .NET Framework, but for UAP, there should be solution for these kind of scenarios. I know there is FrameworkDependency on msix/appx manifest. May be we can use that to supply the new WinUI with Windows.* namespaces rather than Microsoft.* ones.

On the dev side, we'd have less pain to upgrade our apps, since we're only changing the reference and not the code!

I'd prefer not changing the namespace at all!

Benefits:

1. Don't have to change code back and forth.

2. Once local WinUI code has been stabilized, you can merge back into windows platform, so that system apps and LOB apps can take advantage of the new improvements, on every new windows release.

3. One side it's a highly stable system framework with high compatibility like .NET Framework. And the other side it's like .NET Core, with changes at faster pace, with all the benefits of both and none of the issues.

I wouldn't think it were necessary to provide a porting tool. It's a one time change, reasonably easy with Find&Replace, and the number of instances are going to be fairly low.

Also encountered more issues:

• After adding resources to the App class, my XAML could not find it until I added this, again found from the Terminal app and with not much idea about what it really does:

  <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs">
    <ItemGroup>
      <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" />
      <PackagingOutputs Remove="@(_RelocatedAppXamlData)" />
      <PackagingOutputs Include="@(_RelocatedAppXamlData)">
        <TargetPath>%(Filename)%(Extension)</TargetPath>
      </PackagingOutputs>
    </ItemGroup>
  </Target>

• The build will completely break at random with an error similar to cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication and the only way to get the project building again is to do a clean build
• I can't run the app by directly setting the vcxproj for the main exe as startup project, I have to manually start the unpackaged appx output in bin\x64\Debug\AppX and then inject a debugger from within VS, or set the app package as startup process.

@pjmlp I'm not sure why you're criticising C++/WinRT which is just a (standard compliant) C++ wrapper around Windows APIs. It's possible to write applications with C++/WinRT without needing tooling (and IDL files etc).

That is exactly the problem, zero tooling support versus the development experience of C++/CX in Visual Studio.

No editing support for IDL files, not even syntax highlighting, let alone intelisense. And then one gets told to manually copy, or merge, the generated translation units!

This is like doing ATL back in the day.

I don't care about ISO C++ compatibility, UWP is anyway Windows only and there aren't any C++ compilers without language extensions.

I fail to see how anyone can see this as progress, other than the WinDev guys that were the only users of WRL.

@pjmlp ,

I don't care about ISO C++ compatibility, UWP is anyway Windows only and there aren't any C++ compilers without language extensions.

For those of us that write large C++ cross-platform applications, being standards compliant is a big deal. The restrictions of C++/CX were awful (no member variables that aren't raw pointers, hats! (^) etc). We currently have a large C++/CLI interop library, and the pain points are too numerous to list.

No editing support for IDL files, not even syntax highlighting, let alone intelisense. And then one gets told to manually copy, or merge, the generated translation units!

Again, you're conflating C++/WinRT and tooling. They're 2 separate things. C++/WinRT is a C++ wrapper around the WinRT APIs. IDL is for code generation, and yeah, I agree it's awful, it's so bad that I don't use it.

I write a Windows only app and I still care about standards compliance since it allows me to use a different compiler in cases where MSVC fails.

@MarkIngramUK

Again, you're conflating C++/WinRT and tooling. They're 2 separate things. C++/WinRT is a C++ wrapper around the WinRT APIs. IDL is for code generation, and yeah, I agree it's awful, it's so bad that I don't use it.

I have been coding for Microsoft platforms since MS-DOS 3.3, added C++ to my toolbox in 1992 with Turbo C++ 1.0, have used most of Borland, and Microsoft products in what concerns C++ development. Don't need any lecture on what C++/WinRT is about.

What it definitely isn't, is a match to the C++ Builder and Qt (with Qt Designer) developer experience, that C++/CX showed the promise to eventually catch up with, 25 years later.

But apparently most people here just want Visual C++ 6.0 with ATL 3.0, and the rest of us should just stick with .NET 5, WPF and Win32 desktop experience, because we are a minority not worthy of consideration, otherwise C++/WinRT would never have been pushed the way it was.

Lets be honest, C++/WinRT is now almost 4 years old, and Microsoft wasn't even able to provide support even for syntax highlighting and intelisense?

Something that some of us have crafted in Notepad++ (syntax highlighting), Really?

It definitely shows where the priorities are, and it isn't this way that WinUI will gain adoption, too many rewrites since Windows 8.

@pjmlp , again you're talking about the wrong things. C++/WinRT is just C++, so it does have syntax highlighting and it does have intellisense support. Just the same as any other C++ code you have.

IDE integration could be better, like as you mentioned IDL syntax highlighting and stuff like suggesting to create a default implementation in .hpp and .cpp from the IDL (like how currently a function declared without a definition in a header prompts you with green squiggles to create one), but going back to C++/CX is a net downgrade IMO. It would require too much effort to integrate all the libraries and shared code I use with C++/CX, and force me to downgrade my project from C++20 to C++17 (which I don't want to give up, 20 gives me too many good things).

C++/WinRT is also much less intrusive than C++/CX when programs just want to consume WinRT classes, not author them.

Qt and C++ Builder achieve their experience in mostly standards compliant C++ (note that Qt has something similar to IDL, named Qt MOC). If these can, so can VS. It just requires more love from somebody in DevDiv.

And as you mentioned previously @sylveon , we're free to build with other compilers (we currently build with MSVC and Clang/LLVM). With C++/CX or other MS extensions this would be impossible.

@MarkIngramUK and @sylveon

I am done with this thread, it is quite clear that feedback like mine is not welcomed for improving the WinUI developer experience and tooling.

Have fun with your standard compliant C++/WinRT.

@pjmlp I think I understand EXACTLY what you mean.

A year or so ago I abandoned the idea of porting my UWP C++/CX code over to C++/WinRT. The incentive for porting was to be able to use Clang to compile my UWP app because MSVC++ contains a bug that I reported around 18 months ago but they simply don't seem to be interested in fixing.

However, it then turned out that Visual Studio does not support building UWP apps using Clang. Great, so the "ISO C++ only" benefit of C++/WinRT went right out the window. Add to this the fact that porting a C++/CX code base over C++/WinRT is like traveling 20 years back in time.

I've essentially given up porting our Android/iOS apps over to Windows. It's simply not feasible for a small shop like us to deal with the clusterfuck that is Windows app development in addition to developing for Android/iOS.

@MarkIngramUK It seems that you simply don't get the point that tooling IS VERY IMPORTANT. Not everyone has the resources to compensate for the lack of proper tooling him/herself.

Now, after my rant, here's my input:

Support using WinUI 3 with C++/CX. Once the tooling for C++/WinRT is acceptable for companies that don't have the resources to build their own tooling it might be ok to switch to C++/WinRT. Now it is definitely not.

@pjmlp I think I understand EXACTLY what you mean.

A year or so ago I abandoned the idea of porting my UWP C++/CX code over to C++/WinRT. The incentive for porting was to be able to use Clang to compile my UWP app because MSVC++ contains a bug that I reported around 18 months ago but they simply don't seem to be interested in fixing.

However, it then turned out that Visual Studio does not support building UWP apps using Clang. Great, so "ISO C++ only" benefit of C++/WinRT went right out the window. Add to this the fact that porting a C++/CX code base over C++/WinRT is like traveling 20 years back in time.

I've essentially given up porting our Android/iOS apps over to Windows. It's simply not feasible for a small shop like us to deal with the clusterfuck that is Windows app development in addition to developing for Android/iOS.

@MarkIngramUK It seems that you simply don't get the point that tooling IS VERY IMPORTANT. Not everyone has the resources to compensate for the lack of proper tooling him/herself.

Now, after my rant, here's my input:

Support using WinUI 3 with C++/CX. Once the tooling for C++/WinRT is acceptable for companies that don't have the resources to build their own tooling it might be ok to switch to C++/WinRT. Now it is definitely not.

Out of curiosity, what was the bug reported 18 months ago? Do you have a link to it anywhere?

hi Miguel,
edited to fix the awful state of things after replying from Outlook for Android

I had an idea that may make your goals for the previews and releases clear since you said the Winrt platform is what you're using to develop WINUI.

take this article, which calls out a bunch if IDL writing and manually copying if files and modify it so it matches the state you're working toward in the tools

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

If not here, perhaps we can discuss that somewhere else.

by the way you have me convinced on the XAML designer, especially with tools on existence like XAML studio. (if only it was also able to load some code behind so it could successfully load XAML that makes use of IValueConverter...

As mentioned in my previous post, the C++17 standard compliance of C++/WinRT in itself is in most cases no incentive to migrate a C++/CX code base to C++/WinRT because you're forced to compile with Microsoft's Visual C++ compiler anyway. If you could switch out the compiler that would change entirely.

But Visual Studio does not support switching out the compiler for Windows Runtime components. It is a mystery to me why this is not supported, especially because it is supported for desktop apps as outlined in this blog post. Clang support should really be expanded for Windows Runtime components.

We're using Clang to compile our code base for Android and iOS. Being able to use Clang to compile our code base for Windows would actually be a very very good reason for migrating away from C++/CX. The Visual Studio feature request for that already exists but nothing has been done so far by the Visual Studio team.

You have C++ standard compliance, you have Clang support in Visual Studio for desktop apps. So, please do the final step and provide a real reason for migrating away from C++/CX by providing Clang support for Windows Runtime components.

The standards compliance is useful for consumers - as you mention producers are stuck to MSVC. There is a way to "force" clang-cl (that's effectively what the LLVM toolset does already) by setting the property CLToolExe to a path to clang-cl in the .vcxproj file. I'm not sure how well that works in UWP projects, but it's worth a try.

Once XAML and C++/WinRT producer tooling is unlocked in desktop projects, it's also going to be less of an issue for me.

@ackh I got an UWP project to build under Clang 11:

Here's what I did:

• Unload the project, and add the following directive as the first directive under <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• Replace <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> by <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Replace <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> by <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Right below this, add <ModuleOutputFile />
• Reload the project
• Build

It has a couple pitfalls however:

• Some warnings regarding unused arguments prop up: you could probably fix those by changing/removing the unused arguments.
• For some reason Clang emits a 64-bits object file in 32 bits, might just need to add -m32 to the CLI tho.
• Since Clang doesn't fully implement coroutines yet, you won't be able to use them.
• VS does a full single-threaded rebuild each time you run the app rather than incremental and/or parallel.

I would suggest opening an issue on https://github.com/microsoft/ProjectReunion to get attention on this.

@sylveon Thanks a lot for posting these instructions. I'll give this a try at some point but still hope that Visual Studio will support this out of the box at some point.

When evaluating the remarks by posters above, the first thing I do is look at their repo. Is the repo representative of someone that's doing real work? This is what I ask myself. Suggest Microsoft does the same when evaluating the validity of comments given.

Coming from the UWP side of things, all I need is a capability that allows my UWP App to run fully unrestricted with tooling that allows for linking against conventional Win32 libs. I, and the rest of the posters above would be golden if they embraced UWP as it stands today with such a capability. I could develop all manner desktop applications then. So while WinUI spins on becoming real, we can have something that delivers on past promises today since most of the essentials (and then some) are in UWP now. I agree with @pjmlp about the pain points associated with C++/WinRT, however I'm mostly ok with where C++/WinRT has landed conceptually (language extensions that break old code are always bad) with the exception of how the developer experience is integrated as compared to a C# UWP XAML workflow. C++/WinRT UI development is painful and very very unproductive. The mindset of C++ devs is too accepting of poor productivity tooling, I should know I was a late convert to C#.

Lets not gatekeep feedback.

Worth also remembering that GitHub isn't the only VCS provider out there.

And many developers will be using a private repo for their day job.

If you're a serious C# / C++/WinRT / XAML / Microsoft dev, Github is the main event. Not posting on Github is already a partial disqualifier because you're not really contributing the the community in an accessible way. I have private repos in a few places. I post on Github because that's what has the needed visibility with respect to the topic at hand.

Very, very happy to see the ability to create straight-forward desktop applications using WinUI. Sad to hear that it only happened after all these studies and interviews. A few things though.

1. A bit concerned to see references to "apps" and "packages" via that second project that is also set up as the startup project by default. I have no plans to write for devices and web. So I hope Visual Studio won't force me to.

2. I just installed the Project Reunion 0.5 Nuget package from VS 2019, created a new WinUI Desktop project and.. it won't compile. This is the first time I have created a project from a template, tried to compile it as-is and ran into a compilation error. After 10 minutes troubleshooting, I couldn't figure it out. Yeah, its not the 737 Max or an exploding Samsung phone. But still.. concerning.

3. Rather than more documentation, I would love to see a bunch of short videos that show hands-on development work. That is, take a bunch of legacy Desktop applications -- MFC, VB6, WPF, whatever -- and convert them to a WinUI application. That will teach Microsoft's own people a bit more about.. whatever it is they feel they might have been doing really well so far.

Why so much harassment in a dead thread?

"I don't care about other platforms so I hope they don't mention platforms I don't care about." Ok, good for you! I don't care about Android Instant Apps but I'm prompted about it on every new Android project. It's the way the world works.

"That will teach Microsoft's own people a bit more about.. whatever it is they think they might have been doing really well so far." How are you not overwhelmed with embarrassment before clicking the comment button?

It's the way the world works.

True. But the project template did not work.. as-is. The error came from that second "package-related" project. So I couldn't run the desktop project above it. Yeah, I can eventually figure it out. But I was very surprised to see an issue at this basic level.

How are you not overwhelmed with embarrassment before clicking the comment button?

Teaching others by preparing and presenting through video lends insight in a way is what I felt was truly needed here. Yeah, my tone was a bit sarcastic but I am not embarrassed by it. Its also how the world works. Have a good night.

Closing the stale thread. Same discussion is happening elsewhere.