microsoft-ui-xaml 🚀 - WinUI 3.0 Developer Experience and Tooling - Input Needed

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...

mdtauk on 12 Jul 2019

👍16

My thoughts are as follows:

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.
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.
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.)
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!

wjk on 13 Jul 2019

👍15

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 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.
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?
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.

vitorgrs on 13 Jul 2019

👍10

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.
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.
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.

huoyaoyuan on 13 Jul 2019

👍4

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!

wjk on 14 Jul 2019

👍1

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.

maxkatz6 on 14 Jul 2019

👍20 ❤6 🚀1

Why no F# support?

TonyHenrique on 17 Jul 2019

👍4

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

kmgallahan on 17 Jul 2019

👍1

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.

Guruumeditation on 17 Jul 2019

👍2

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.

thomasclaudiushuber on 17 Jul 2019

add winui 3.0 templates to windows template studio.

touseefbsb on 17 Jul 2019

👍2

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:

the App Installer feature does not offer the same experience on older windows versions
MSIX requires a valid signed package (internal or public). Clickonce supports self-signed packages.
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.

tbolon on 17 Jul 2019

👍1

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?

mdtauk on 17 Jul 2019

👍2

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.

huoyaoyuan on 17 Jul 2019

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

shaggygi on 17 Jul 2019

👍2

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.

mdtauk on 17 Jul 2019

👍3

@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 on 17 Jul 2019

👍2

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

shaggygi on 17 Jul 2019

@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.

Felix-Dev on 17 Jul 2019

👍2

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.

ghost on 17 Jul 2019

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: https://github.com/MicrosoftDocs/windows-uwp/issues/1781#issuecomment-511173811

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.

sylveon on 18 Jul 2019

👍6 👀1

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.

RyoukoKonpaku on 19 Jul 2019

👍3

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.

mdtauk on 19 Jul 2019

👍2 ❤1

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:

Don't have to change code back and forth.
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.
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.

Nirmal4G on 19 Jul 2019

👍2

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.

MarkIngramUK on 19 Jul 2019

👎1

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:
xml <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.

sylveon on 21 Jul 2019

Related stuff on Windows Desktop: .NET Community Standup - July 25th, 2019 if interested.

shaggygi on 25 Jul 2019

👍1

LONG time WinForms, WPF developer here with some UWP experience. Here's my 2 cents:

Migration

A tool to migrate existing UWP apps to WinUI is a must.
A tool to convert WinForms or WPF controls to WinUI controls in an existing app would be beyond awesome. By convert the controls, I mean change the references in the container to the individual controls.
A tool to migrate Xamarin Forms to WinUI to allow back-porting a mobile app to Windows.

Tooling

Current XAML Editor is awful! It needs to use the normal text editor canvas and provide for Roslyn features to be applied to the XAML object model for better intellisense and refactorings.
Until Visual Studio is 64 bit, the XAML Editor needs to be a stand-alone 64-bit app behind the scenes. I'm constantly having to restart VS 2017 and VS 2019 to stop out-of-memory error when working with a lot of XAML.

Templates

We need these project templates
- NavigationView WinUI
- NavigationView WPF
- Ribbon WinUI
- Ribbon WPF
- Ribbon WinForms
We need these page/window templates
- Media Controller Page
- Browser Page
- Dialog Window
- Borderless Window
- Floating Window
We need control templates
- Encapsulated data grid view
- Encapsulated child data view

These last two would work together to create easy Master-Detail windows.

sharpninja on 29 Jul 2019

👍2

all of these templates and pages etc are already being done in Windows Template Studio project, why not follow the same route instead of recreating all of it ?

touseefbsb on 29 Jul 2019

👍3

SDK Style project file
One of the most important bit I'd like to see - as many others have also mentioned - is the support for the new SDK Style project file format for both UWP and "Desktop XAML" apps.

Migration between UWP and Desktop XAML app models
If we start to build a "Desktop XAML" app, how far will it be from a UWP app? Will it be trivial to turn it into a UWP app later on if we realize that we stayed within the constraints of the UWP sandbox? Or if we started to build a UWP app and realize we need more, is it going to be easy to turn it into a "Desktop XAML" app?

petroemil on 29 Jul 2019

👍8

I'm with Template Studio support.

Nirmal4G on 29 Jul 2019

I'm with Template Studio support.

Does Template Studio support XAML C++ projects?

What Template Studio is doing, should be part of the WinUI SDK IMO

mdtauk on 30 Jul 2019

👍2

What Template Studio is doing, should be part of the WinUI SDK IMO

Should be a part Visual Studio IDE IMO! 😎

Nirmal4G on 30 Jul 2019

guys the point is windows template studio is doing an all in one stuff for UWP project creation so keeping that in mind if something is missing like xaml c++ support, we should considering adding that to windows template studio, I think it will be faster and more efficient if all new innovations in uwp projects remain in one project.

touseefbsb on 30 Jul 2019

Let there be some method to use the lower layer of WinUI 3's stack directly without XAML or even MVVM. This is especially useful for existing big-iron C++ software which are already have some sort of MV-whatever architecture in their codebase. They just want something better than HWND + GDI.

And, please make people think that WinUI 3 is not a toy, it can really support serious softwares.

be5invis on 3 Aug 2019

👍3 ❤1

@be5invis I agree completely. The only solution right now is XamlDirect, but that’s more targeted at middleware developers.

MarkIngramUK on 3 Aug 2019

You can manually build content with Xaml Islands already. Just get a DesktopWindowXamlSource working and attached to a window, then create and arrange/layout controls in code.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file-picker-cpp-L46

sylveon on 3 Aug 2019

👍2

@MarkIngramUK They may need something more “complete”, like replacing CreateWindow with WinUI functions.

be5invis on 4 Aug 2019

For design sake, I would really like the future WinUI WPF templates to have support for expanding a page's contents into the titlebar like that of current UWP apps. Right now, with the existing XAML islands solution, we're merely hosting controls inside a WPF/WinForms Window rather than a modern view.

duke7553 on 20 Aug 2019

👍1

@LucasHaines The list of the languages we are planning to support with WinUI 3.0: C#, C++/WinRT, Visual Basic. We are exploring support of F#.

This shows you are doing it wrong, not just for F# but for all .Net languages. You are starting by thinking about templates and .xaml files, which is like buildling a house and putting carpets and curtains in place without having finished the structure.

You should be able to install WinUI into any .Net Standard 2.0/.Net Core 3.0/.Net 5 project as a Nuget package. Then you have access to all the classes defined inside. You can then reference such projects from a WinUI project (which could be C#-only). This allows WinUI views to be created in any .Net language. See how Xamarin.Forms does it.

charlesroddie on 22 Aug 2019

The classes are already available for use in F# (since they are Windows Runtime components, which are usable by all .NET languages)

You'll be able to manually create a layout. You could even do it via Python using Py/WinRT for all WinUI cares.

sylveon on 23 Aug 2019

@sylveon What classes specifically? I'd be interested...

duke7553 on 23 Aug 2019

All of them. The public API of WinUI is only Windows Runtime components.

sylveon on 23 Aug 2019

@LucasHaines The list of the languages we are planning to support with WinUI 3.0: C#, C++/WinRT, Visual Basic. We are exploring support of F#.

This shows you are doing it wrong, not just for F# but for all .Net languages. You are starting by thinking about templates and .xaml files, which is like buildling a house and putting carpets and curtains in place without having finished the structure.

You should be able to install WinUI into any .Net Standard 2.0/.Net Core 3.0/.Net 5 project as a Nuget package. Then you have access to all the classes defined inside. You can then reference such projects from a WinUI project (which could be C#-only). This allows WinUI views to be created in any .Net language. See how Xamarin.Forms does it.

This topic/question is about tooling. Yes the libraries can be directly referenced from any language capable of consuming them but there's a blurring of definitions between tooling and language support.
Taking Xamarin.Forms as your example. That only provides tooling for C# and to a lesser extent F#. It's possible to build apps with VB.Net and Xamarin.Forms but it's not _officially supported_ as there are no tools and only limited documentation for doing so.

Also, as WinUI is Windows specific it can't be referenced in just any .Net Standard 2.0/.Net Core 3.0/.Net 5 project.
There's also a need for project/compiler/packaging level support for some scenarios too.

mrlacey on 23 Aug 2019

👍1

Great work team on v2.2 release. Any chance we can get a brief update on v3.0 status?

shaggygi on 4 Sep 2019

I see this mentioned several times but no clear direction one way or the other. Since WinUI 3.0 will have all controls now the namespace requirement to reference WinUI library controls MUST be removed. This clutters up XAML a lot, greatly hinders migration, and breaks simple compatibility with things like UNO platform and Avalonia.

Please remove the need for xmlns:mux="using:Microsoft.UI.Xaml.Controls" from XAML. I understand code behind still needs to change. There could also be a configuration for this some place in the project.

robloo on 10 Sep 2019

👍3 🚀1

Please remove the need for xmlns:mux="using:Microsoft.UI.Xaml.Controls" from XAML.

It won't be required in the XAML _markup_, but changing namespaces in code-behind would still be required.

jevansaks on 10 Sep 2019

If you want to use the Windows controls (if they are not removed from the OS) - You should have to declare the namespace in XAML

mdtauk on 10 Sep 2019

If you want to use the Windows controls (if they are not removed from the OS) - You should have to declare the namespace in XAML

With WinUI 3.0 that isn't a scenario -- you can't mix and match OS controls with WinUI 3.0 controls. That only works with WinUI 2.x right now because those controls are add-ons to the OS (and we have a lot of awkward cases where we shipped the type in both places like NavigationView and TreeView causing ambiguity).

jevansaks on 10 Sep 2019

If you want to use the Windows controls (if they are not removed from the OS) - You should have to declare the namespace in XAML

With WinUI 3.0 that isn't a scenario -- you can't mix and match OS controls with WinUI 3.0 controls. That only works with WinUI 2.x right now because those controls are add-ons to the OS (and we have a lot of awkward cases where we shipped the type in both places like NavigationView and TreeView causing ambiguity).

Good to hear. Will make it easier to deprecate that from the OS. I hope the Settings App, the Shell, and other parts of the OS will move to WinUI 3.0 too.

And lets hope for ports of the Administrator Tools, Wordpad, etc over to XAML reusing the same code as much as possible too!

mdtauk on 10 Sep 2019

@jevansaks Ok, understood, thanks for the feedback!

@mdtauk There will be no need to distinguish between 'OS' legacy controls and the new 'WinUI 3.0' platform controls in XAML. Everything is moving to WinUI 3.0 and the OS controls are getting no more feature updates as you know. After WinUI 3.0 if a developer still wants to target the legacy controls they should develop with older SDKs and Visual Studio versions. Maintaining the ability to reference two Microsoft/Windows UI control libraries from XAML would just be a hindrance for the reasons earlier stated. Besides, with the decoupling of WinUI development can finally switch to a sustainable path of 'allowing' changes like this -- which isn't even a breaking.

Edit: Forgot to refresh before replying, most of this is redundant now.

robloo on 10 Sep 2019

@robloo I am glad this will truely replace the previous versions of UWP Xaml. I also hope the OS can move to it for the Inbox Apps and Shell.

I also hope there will be plenty of developer videos detailing the process of moving over to WinUI 3.0 - and how to work with WinUI 3.0 with the same Lifecycle as Win32 apps. No more rehydrating, better ways to save page state and navigation, etc.

It could be helpful (depending on which apps plan to move to WinUI 3.0) to provide examples of say taking Wordpad and moving code over to a new UI built in WinUI - as well as taking an inbox app like Groove Music, and moving that over to WinUI 3.0

mdtauk on 10 Sep 2019

For WinUI 3, there needs to be some consistency in regards to the placement of app functions in the Design Language.

In this regard, App Settings.

Where do I find the App settings? Do I click the gear in the top right corner? Bottom left corner? Do I click the Profile avatar in the top right and hit settings? Do I click the top left? Bottom left? Do I go to Edit > Preferences?

shaheedmalik on 12 Sep 2019

👍2

Really depends on if you use NavigationView...

From: shaheedmalik notifications@github.com
Sent: Thursday, September 12, 2019 3:48:12 PM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Comment comment@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

For WinUI 3, there needs to be some consistency in regards to the placement of app functions in the Design Language.

In this regard, App Settings.

Where do I find the App settings? Do I click the gear in the top right corner? Bottom left corner? Do I click the Profile avatar in the top right and hit settings? Do I click the top left? Bottom left? Do I go to Edit > Preferences?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ.

sharpninja on 12 Sep 2019

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

It should not take significant efforts and undocumented project configuration attributes to make WinUI/XAML Islands work with C++/WinRT in Visual Studio.

sylveon on 3 Oct 2019

👍1

Can't stress this enough, but the most important thing to me is that WinUI renders to more than just Windows.

As soon as I saw the Surface Duo I wondered what the cross-platform development story is going to be now that Microsoft is releasing an Android powered device. Xamarin.Forms doesn't cut it for a number of obvious reasons. It's time Microsoft fully embraces a cross-platform toolkit (like the UNO platform but finished and stable) which we all know has been requested in various forms for years. I'm hoping Microsoft has a few plans left unsaid for developers here.

Satya stated "We didn't want to just build experience and one device but that span all the devices in our lives." If you want developers to come along for this ride as Panos hopes, this is the best way to do it. Otherwise, you are asking developers to write two separate UIs to span the 'experience' between Surface Duo and the rest of the family. I don't think that's a fair request to developers within one 'family' of devices.

robloo on 3 Oct 2019

🚀3 ❤2

~~Renders differently on each platform aka "native look and feel". No to Fluent design.~~

I don't get this. A lot of the hype around Fluent design is consistency within Windows, but by introducing a fluent-designed app on other platforms, you do the complete contrary by breaking the existing consistency brought by Material Design 2 and Human Interface on their respective platforms. Please don't, the last thing I want Fluent Design to do is causing more inconsistency not less.

EDIT: original comment removed

sylveon on 3 Oct 2019

Satya stated "We didn't want to just build experience and one device but that span all the devices in our lives." If you want developers to come along for this ride as Panos hopes, this is the best way to do it. Otherwise, you are asking developers to write two separate UIs to span the 'experience' between Surface Duo and the rest of the family. I don't think that's a fair request to developers within one 'family' of devices.

This is EXACTLY why I was dejected that the Duo was Android.

shaheedmalik on 6 Oct 2019

👍2

The templates need to be open sourced to remove any problem areas that arise in them.

shaheedmalik on 6 Oct 2019

👍1

When I will use WinUI with WPF, and when I will create new control with code like:
c# public class MyControl : UserControl { ... }
It will use WinUI.UserControl or WPF.UserControl?
Will we have need to choose and how to deal with it?

maxkatz6 on 15 Oct 2019

👍1

And interesting, if XAML tooling are going to be unified, will we have ability to create some kind of shared xaml files?
Something like:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Should it be some kind of shared dialect with special root namespace? (like Shared projects in Visual Studio). It could look like conditional xaml.

maxkatz6 on 15 Oct 2019

It will use WinUI.UserControl or WPF.UserControl?
Will we have need to choose and how to deal with it?

This should happen automatically in the XAML where you define

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

That tells the compiler it's UWP.

public class MyControl : UserControl { ... }

This is actually incorrect. You should be declaring like this

public partial class MyControl { }

No inheritance is necessary because it's handled by the .g.cs file which specifies the inheritance and also the framework being used.

sharpninja on 15 Oct 2019

About templates, I'd be happier if there was more than a Hello World template. What I mean is that Microsoft should back up some peripheral recognized frameworks required to work with client apps

@weitzhandler I'd love to see this too!!

SDK style projects for C# and Cpp/WinRT projects should be a must have as well

stevenbrix on 23 Oct 2019

I think there should be templates for all the common Win32 and Inbox app patterns. A short list off the top of my head:

Ribbon
Main Menu
Tabbed Document interface
Navigation View
Command/Toolbar
Top Navigation View
Hub/Gallery (I know this is slightly deprecated)
Treeview/MasterDetails (File explorer, RegEdit, Administration App)

But there should also be item templates for common dialogs, pages, settings pages, etc.

mdtauk on 23 Oct 2019

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

Work with the C++ extension for VSCode/Visual Studio. I want to see VS Code as a supported editor as well that provides a similar experience to Visual Studio. WinUI is supposed to be OSS and so is VS Code, so I think this is doable.

WSLUser on 24 Oct 2019

Tools like Template10 and Windows Template Studio are signs of lacking basic functionality. With WinUI3 there should be functionality in place for what these tools do. I am betting that a lot of developers are doing this basic scaffolding over and over... it should be part of the framework. No extra tools should be needed. Maybe you should even have to turn off the MVVM scaffolding for those rare cases when you would like to be without.

After working some with ASPNET Core, I am missing dependency injection. This feature is there natively in ASPNET Core. It just works, without you doing anything extra. And you can add or modify services so easily if you want to. But for UWP today, then you need to build this yourself or use something like WTS to get started, but it still feels like it is glued on afterwards. WinUI3 with proper native dependency injection would be so helpful.

xiler8 on 25 Oct 2019

I don’t think that the presence of Template systems shows a lack of basic functionality, I think it highlights the quality of the supporting communities that would put together these template systems.

sharpninja on 25 Oct 2019

Tools like Template10 and Windows Template Studio are signs of lacking basic functionality.

I see things like this as an extension to basic functionality. Of course, things like this could be brought in house but it's then more for the core team to maintain and support. As the core team does more it tends to mean they are spread more thinly and so everything takes longer. If Msft feel they have budget to bring things like this into the main team I'd love to have a talk with someone about it ;)

mrlacey on 25 Oct 2019

Just a few thoughts about simplified styling and control templating, like make it easier to add custom behavior for built-in styles and controls. Perfect example here is Button styling, when we need to override the entire control template to change the hover color or use border radius. Setting some of them directly, like in css, will prevent creating kilometers of XAML code

AntiPasha on 3 Nov 2019

@AntiPasha Have you heard of Ligthweight styling? With it you can easily change the hover color without having to re-create the entire style:

Changing the hover color for a button then would just be:

Felix-Dev on 3 Nov 2019

👍2

And interesting, if XAML tooling are going to be unified, will we have ability to create some kind of shared xaml files?
Something like:
<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>
Should it be some kind of shared dialect with special root namespace? (like Shared projects in Visual Studio). It could look like conditional xaml.

@Tirraon this is a really interesting example, but I think when we talk about unifying tooling, it's better to start in the mindset that the the platforms are going to exist as they do today, and we aren't trying to create another Xaml Standard equivalent.

We can use the default namespace to differentiate which "top-level" platform the xaml file belongs to, so for example, we could have the following default namespaces for each XAML platform (these are mostly hypothetical, so take them with a grain of salt 😄 ):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
avalonia: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

So to intermix WinUI with WPF using Xaml Islands, you have markup that looks like this:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

What do you think?

stevenbrix on 5 Nov 2019

@stevenbrix
In your example for UWP it will render both buttons, isn't it?
I mean, for case, when xmlns=".../xaml/presentation" is top level namespace and UserControl wutg StackPanel are available in both uwp and wpf, then wouldn't second Button be available also in both platforms?

when we talk about unifying tooling, it's better to start in the mindset that the the platforms are going to exist as they do today

Yeah, I am totally agree with it.

maxkatz6 on 7 Nov 2019

In your example for UWP it will render both buttons, isn't it?
I mean, for case, when xmlns=".../xaml/presentation" is top level namespace and UserControl wutg StackPanel are available in both uwp and wpf, then wouldn't second Button be available also in both platforms?

@Tirraon, the example I gave is purely for the WPF application that uses Xaml Islands to incrementally modernize their application. It isn't intended for a "standard" markup that is used between WPF and WinUI applications, does that make sense?

Currently, app authors wanting to use Xaml Islands have to create user controls for every island. They then reference the type via a string in their WPF markup, rather than naturally embedding WinUI elements in the WPF markup.

I'm on my phone right now, but I can get a more concrete before and after of what I'm proposing once I'm near my PC.

stevenbrix on 7 Nov 2019

@stevenbrix
Oh, now I got you, thanks.

maxkatz6 on 7 Nov 2019

@stevenbrix
Oh, now I got you, thanks.

@Tirraon great! Glad we're on the same page ☺️

Sorry if my idea seemed to come out of left field, we've been in early discussions of how we could potentially unify tooling, with the goal of improving the Xaml Island scenario. Do you think there's value in something like that?

FWIW, I definitely think there's merit in something like what you were proposing. But I'm trying to focus on something that we can get done in the WinUI3/.NET5 time frame.

stevenbrix on 7 Nov 2019

Figure out how to render WinUI Xaml to some pipeline that translates the output to a native canvas and receive input from a native message system. Like WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

Implementing all of the adapters isn't necessary at Launch, just the ones that are required to support Windows 10.

From: Steven Kirbach notifications@github.com
Sent: Thursday, November 7, 2019 9:13:46 AM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Comment comment@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

@stevenbrixhttps://github.com/stevenbrix
Oh, now I got you, thanks.

@Tirraonhttps://github.com/Tirraon great! Glad we're on the same page ☺️

Sorry if my idea seemed to come out of left field, we've been in early discussions of how we could potentially unify tooling, with the goal of improving the Xaml Island scenario. Do you think there's value in something like that?

FWIW, I definitely think there's merit in something like what you were proposing. But I'm trying to focus on something that we can get done in the WinUI3/.NET5 time frame.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ.

sharpninja on 7 Nov 2019

Yes please, the XAML Island scenario is horrible at the moment

sylveon on 7 Nov 2019

👍1

@sharpninja
You should take a look at Uno
https://platform.uno/
Also it's going to support WinUI 3.0 for every platform
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
I am not really experienced with Xaml Islands and work usually with plain UWP. But I definitely need to look at it closer.
My proposal wasn't related to Xaml Islands itself, but more related for WinUI in general, since it will work on more than one platform.

maxkatz6 on 7 Nov 2019

My proposal wasn't related to Xaml Islands itself, but more related for WinUI in general, since it will work on more than one platform.

@Tirraon, yup I totally get it, and absolutely love where your head is at 🙌

I've briefly spoken with @jeromelaban and company about exactly what you're proposing, and there is definitely interest. There's no concrete plan or commitments yet, as we are still in the very early stages of discussions. This sort of input is great, and helps us better understand the value it brings to our customers 😄

stevenbrix on 7 Nov 2019

👍1

By the XAML island scenario I mean the C++ one. See my previous messages in this thread for the list of issues I've faced.

sylveon on 7 Nov 2019

Yes please, the XAML Island scenario is horrible at the moment

By the XAML island scenario I mean the C++ one. See my previous messages in this thread for the list of issues I've faced.

@sylveon I see your comments (links below), and yeah that sounds pretty terrible. Sorry you are experiencing that, I'm confident we'll make it better.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-513505038

A lot of the pain you're going through sounds project system related, and I know that is something that is on many people's radars (although I'm fairly detached). Have you seen this video that a few of our team members did on XAML tooling? That link should start the YouTube video at the point where @michael-hawker and @marb2000 starts going into the new Xaml Island experience. We definitely care about C++, but I don't know if we've only addressed the .NET experience thus far, or if there have been improvements to C++ as well. They could probably comment more on that.

There are a lot of things that will go into making the Xaml Island's experience easy and natural to use. The aspect that I'm referring to is that currently, the way you include an Island of UWP content in WPF is like this (from the video above):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

I think we can do better than that, and provide something like this:

  <Grid>
   <uwp:SamplePage />
  </Grid>

stevenbrix on 7 Nov 2019

@stevenbrix

I've briefly spoken with @jeromelaban and company about exactly what you're proposing, and there is definitely interest. There's no concrete plan or commitments yet, as we are still in the very early stages of discussions. This sort of input is great, and helps us better understand the value it brings to our customers

There is so, so much interest! (This conversation pops up everywhere) If WinUI post 3.0 shifted to cross-platform implementations you would have a lot of developer support. Just look at the discussion on #1461. In the short term using Uno Platform tech to convert XAML/C# into HTML/WASM to get UWP apps running on all platforms would be amazing. Longer term I'm concerned about the performance impact of running in Electron or a Browser and there is room for a more efficient architecture.

Bottom line, I know everyone is busy on WinUI 3.0 at the moment. But when that's finishing up it would be great if we connected @jeromelaban, @marb2000, @jevansaks and others to figure out the best way to make UWP render everywhere. That would also be a very interesting community discussion for a future call.

robloo on 7 Nov 2019

🚀1

WinUi is the only sane path that leads to both Neo and Duo surviving

From: robloo notifications@github.com
Sent: Thursday, November 7, 2019 12:00:07 PM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Mention mention@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

@stevenbrixhttps://github.com/stevenbrix

I've briefly spoken with @jeromelabanhttps://github.com/jeromelaban and company about exactly what you're proposing, and there is definitely interest. There's no concrete plan or commitments yet, as we are still in the very early stages of discussions. This sort of input is great, and helps us better understand the value it brings to our customers

There is so, so much interest! (This conversation pops up everywhere) If WinUI post 3.0 shifted to cross-platform implementations you would have a lot of developer support. Just look at the discussion on #1461https://github.com/microsoft/microsoft-ui-xaml/issues/1461. In the short term using Uno Platform tech to convert XAML/C# into HTML/WASM to get UWP apps running on all platforms would be amazing. Longer term I'm concerned about the performance impact of running in Electron or a Browser and there is room for a more efficient architecture.

Bottom line, I know everyone is busy on WinUI 3.0 at the moment. But when that's finishing up it would be great if we connected @jeromelabanhttps://github.com/jeromelaban, @marb2000https://github.com/marb2000, @jevansakshttps://github.com/jevansaks and others to figure out the best way to make UWP render everywhere. That would also be a very interesting community discussion for a future call.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ.

sharpninja on 7 Nov 2019

🚀2 ❤1 👍1

WinUi is the only sane path that leads to both Neo and Duo surviving

I tend to agree, but getting the same UI from a Windows app, running on Android and the Surface Duo. With minimal intervention from the developer - that is the holy grail.

If WinUI has any chance of being a primary development platform, and giving Windows a chance against becoming just a receptacle of other platform's apps in the long term. (Not always a bad thing, when it comes to big established apps, but for LoB and the next big apps...)

mdtauk on 7 Nov 2019

I'm creating my own Application oriented language and want to support using WinUI with XAML and my language for code-behind. It would be good if the tooling offered the ability for a language to provide code generation for the XAML. What would be even better is if the XAML code-generator built IL as a partial class that could be completed using any language. That would mean the the code generator would output compilable IL assembly.

sharpninja on 15 Nov 2019

I'm creating my own Application oriented language and want to support using WinUI with XAML and my language for code-behind. It would be good if the tooling offered the ability for a language to provide code generation for the XAML. What would be even better is if the XAML code-generator built IL as a partial class that could be completed using any language. That would mean the the code generator would output compilable IL assembly.

There is XAML Direct, but it is supported by C# and C++ at the moment.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

mdtauk on 15 Nov 2019

That's not what I mean. I mean that the output of the code generation tool be IL, not C# or C++. That way my compiler can transform the XAML to IL and then inherit that class.

sharpninja on 15 Nov 2019

@sharpninja It would also be beneficial, if it can also generate LLVM Bytecode instead of just C++ code.

That way we can combine it with MIDL and XLang to generate COM library and WinMD files to use in all XLang supported scenarios.

Nirmal4G on 16 Nov 2019

With my C++ hat on, what I would like to see regarding WinUI tooling for C++, would be for Microsoft finally catch up with what C++ Builder has been doing since the mid-90's.

Provide actual RAD tooling for C++ based development.

C++/CLI failed short of it, although with forms there were some workarounds.

C++/CX seemed like it would be it, still it required a bit more effort than what C++ Builder is capable of.

Now C++/WinRT might be standard C++17, but the overall experience for desktop developers feels like a downgrade, with the increase in boilerplate that one has to manually write, additional care how COM types go over the ABI boundary and lack of designer support.

So I am still using C++/CX for the time being, as I don't feel to deal with all the boilerplate required by MIDL compiler, and COM ABI support.

On the other side, with my .NET hat on, I would like to see C++ only libraries like DirectX be finally exposed as WinUI components, some Blend love, and remembering that F# supposedly is also a .NET language from Microsoft.

pjmlp on 27 Jan 2020

👍3 ❤2 🚀1

I've had a considerable amount of struggle trying to switch over to WinUI. There are a number of both 1st and 3rd party libraries that aren't using WinUI at the moment and dependencies on them become problematic. For example, the Behaviors SDK.

MikeKenyon on 17 Feb 2020

This is an idea I had while talking about StatusBar in the UWP Community Discord ..

In Visual Studio, have the toolbox include entries for WPF controls that are missing from UWP and when those entries are selected, show a popup explaining how to simulate the traditional control.

This idea comes from a desire to ease the transition for people coming from WPF (or other frameworks) where they expect to see certain controls, and not finding those controls can find it to be a jarring experience. How does one know that CommandBar can be used like StatusBar? I think we need to make it as simple as possible for people to move onto WinUI. This might serve to fill in some gaps without having to actually develop all the missing controls.

EDIT:
And for completeness, here is something else I'd said about Status Bar .. just showing how someone might approach UWP (or WinUI) if they aren't familiar with it ..

Re: StatusBar - I was thinking from the perspective of users of traditional frameworks trying UWP - and seeing that it doesn't have StatusBar - still a staple in many apps. Yep, CommandBar might even be better. But people don't know what a CommandBar is or might guess that it's something else. Someone above even suggested that I add a Grid, put it at the bottom, make it one row high and add various controls to display stuff. So it seems even existing Xaml designers don't know about CommandBar. Anyway, maybe you're right, maybe CommandBar is better, but Paul Thurrot didn't use it in his UWP notepad app, he used a grid. So it seems the CommandBar isn't being communicated as the replacement for StatusBar. Casual (or new) developers are still looking for StatusBar and not finding it. I know Paul Thurrot isn't a developer, but you get my point.

Gavin-Williams on 19 Feb 2020

👍3

It would be great if snippets were inject to the xaml with a normal use case, too.

From: Gavin-Williams notifications@github.com
Sent: Tuesday, February 18, 2020 7:05:39 PM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Mention mention@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

This is an idea I had while talking about StatusBar in the UWP Community Discord ..

In Visual Studio, have the toolbox include entries for WPF controls that are missing from UWP and when those entries are selected, show a popup explaining how to simulate the traditional control.

This idea comes from a desire to ease the transition for people coming from WPF (or other frameworks) where they expect to see certain controls, and not finding those controls can find it to be a jarring experience. How does one know that CommandBar can be used like StatusBar? I think we need to make it as simple as possible for people to move onto WinUI. This might serve to fill in some gaps without having to actually develop all the missing controls.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ.

sharpninja on 19 Feb 2020

The developer story should include a sort of comparison list.

Concepts that are intrinsic to Win32 apps, so Status Bars, Toolbars, Menus, Grippers, Tabs, etc In one list, and the WinUI equivalents on the other.

The page itself including code samples from both, to show how an existing App's UI could be moved over to WinUI.

mdtauk on 19 Feb 2020

👍6

Open Question(s)
Would it be beneficial If we provided a migration tool that automated steps 1-3?

Yes. I support 1 "legacy" Windows Forms app (legacy means no budget to re-write) and 2 or 3 legacy WPF apps. The WinForms app may be stranded, but a tool to help port the WPF apps quickly to WinUI 3 would be a great!

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

We currently use ClickOnce to publish apps to our users' desktops. Some model of automated updates would still be desired.

JeffSchwandt on 17 Mar 2020

@JeffSchwandt

Those steps were in regards to converting WinUI projects using earlier versions (1-2) to version 3.

Converting a WPF app to a WinUI one isn't particularly feasible in an automated fashion (without an enormous amount of effort, but even then it would be extremely error prone).

kmgallahan on 17 Mar 2020

I hope this is the right thread to post this request.

Rust is in the desperate need of a proper UI framework right now. It would be nice if WinUI could support Rust in the future with a native SDK and some tooling.

Alovchin91 on 20 Mar 2020

👍1

I hope this is the right thread to post this request.

Rust is in the desperate need of a proper UI framework right now. It would be nice if WinUI could support Rust in the future with a native SDK and some tooling.

Good news, Rust/WinRT is under development which will enable rust apps to use WinRT APIs like WinUI! Take a look at https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

jevansaks on 20 Mar 2020

@jevansaks Hey, thanks for the response! Yeah, I know Kenny works on Rust/WinRT, but I wonder if WinRT is the only API layer that WinUI will support? I’m not sure how this would fit with the fact that WinRT API usage from desktop apps became available only in Windows 10 1903, while WinUI aims to support older versions of Windows 10.

Alovchin91 on 20 Mar 2020

Rust/WinRT (like C++/WinRT) should work all the way down to Windows 7. WinRT itself has always worked on desktop/win32 apps. It is only certain APIs that had store/uwp/packaging requirements (not WinRT as a whole). As long as WinUI doesn't have those requirements you'll be able to use WinUI from desktop apps via both C++/WinRT and Rust/WinRT on any supported platform.

kennykerr on 20 Mar 2020

👍2

WinUI Desktop apps should support Live Tiles, and Tile Updating - with good simple samples and SDK tooling to create Tiles easier than UWP apps today.

mdtauk on 20 Mar 2020

I’m not sure how this would fit with the fact that WinRT API usage from desktop apps became available only in Windows 10 1903

WinUI Desktop is being designed for WinUI 3.0 right now, and that should enable plain Win32 apps to use WinUI downlevel (the current plan is down to 1803).

jevansaks on 20 Mar 2020

Windows UI should support at least the major MVVM frameworks- MVVM Light, Prism, and Caliburn. Unfortunately, your documented problem with changes to INotifyPropertyChanged and INotifyCollectionChanged breaking ObservableCollection certainly breaks MVVM Light, and probably the other two frameworks as well. Thought you should know.

terrycox on 25 Mar 2020

👍4

Unfortunately, your documented problem with changes to INotifyPropertyChanged and INotifyCollectionChanged breaking ObservableCollection certainly breaks MVVM Light, and probably the other two frameworks as well. Thought you should know.

Thanks @terrycox! We are aware and this will be addressed by WinUI 3.0 RTM, and ideally in a preview build before then ;)

stevenbrix on 25 Mar 2020

👍4

@terrycox Windows UI should support at least the major MVVM frameworks- MVVM Light, Prism, and Caliburn. ... your documented problem

Yes it should fix documented problems, but there is no need for a .Net UI library, including WinUI, to support an MVVM framework. It only needs to support objects that represent UI elements. A .Net MVVM or reactive framework is a way to generate and alter .Net objects representing UI based on objects representing data. Neither needs to know about the other. Any framework can be combined with any UI library.

charlesroddie on 25 Mar 2020

but there is no need for a .Net UI library, including WinUI, to support an MVVM framework.

But things like events and interfaces that UIElements are aware of are necessary and that's what got broken.

From: Charles Roddie notifications@github.com
Sent: Wednesday, March 25, 2020 2:28:46 PM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Mention mention@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

@terrycoxhttps://github.com/terrycox Windows UI should support at least the major MVVM frameworks- MVVM Light, Prism, and Caliburn. ... your documented problem

Yes it should fix documented problems, but there is no need for a .Net UI library, including WinUI, to support an MVVM framework. It only needs to support objects that represent UI elements. A .Net MVVM or reactive framework is a way to generate and alter .Net objects representing UI based on objects representing data. Neither needs to know about the other. Any framework can be combined with any UI library.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ.

sharpninja on 25 Mar 2020

Dotnet cli tooling should be used together with a. Net core sdk.
Commands such as dotnet new and dotnet build should be enough, no Hard dependency of installing Visual Studio. Please, fully join the .Net Core Era!

JensNordenbro on 21 Apr 2020

👍3 🎉1

It will be good if the xaml designer is fast. The current XAML designer is slow and always throws some error saying some exception occured and it wont work. Please correct that and provide robust designer.
currently uwp desn't have any APIs that can detect the lock screen. It will be good if we are provided with APIs that can detect lockscreen and give boolean as return values. We should be also able to display some animation and badges after locking or unlocking.
-Existing lockscreen API
My issue explained

rahulkps23 on 27 Apr 2020

👍1

Along the lines of @JensNordenbro's comment, any chance that this will work with just Vs Code?

Neurrone on 13 May 2020

👍1

I'd like to see an application template that creates a .NET 5 application with WinUI 3.0 UI that references a .NET 5 store host application. This would allow for fewer redundant installations of .NET 5.0

lmcdougald on 18 May 2020

👍3 🚀1

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

mqudsi on 29 May 2020

I just tried the new May 2020 templates for WinUI 3 Preview 1 for Desktop as I like this idea.

But I have one question. With WinUI to be the native UI platform on Windows, I am surprised over the lack of communication to have it actually be part of Windows 10 as well?

My resulting Hello World app was around 120 MB large. Sure, space is cheap, but I had no dependencies on my own here. Of this, WinUI consumed a considerable amount of space, about as much as the included .NET 5 itself. That's for the x64 build alone. Include x86 in a multi-platform package and double that size. Add on a few other dependencies and we might easily be looking at a 300 MB app to package for distribution.

Why is WinUI 3 not simply part of the Windows edition of .NET 5? Is it part of the .NET Core modularization effort? But if not, where is the place for it? Truly insidy every app's folder? As the official Windows 10 user interface...?

Or will it be part of Windows 10 in the future? If WinUI was treated more like a systems library and .NET 5 will start to ship with Windows later, we'd be looking at comparatively tiny apps instead. But hopefully this is exactly the story for Windows 10X at least, and maybe also Windows 10 non-X later on? Excluding these two libraries as well as the Windows 10 SDK C#/WinRT bridge DLL, the app size plummets to 1-5 MB.

jonasnordlund on 4 Jun 2020

@ryandemopoulos has said on Discord that WinUI will be delivered as a framework package, so apps using the Store or MSIX for distribution will not have to carry their own version of WinUI, as they will all share the same copy of it.

Making WinUI part of Windows itself would defeat the point of WinUI being decoupled from the OS.

sylveon on 4 Jun 2020

👍2

"Reliably available and not in the size of the app" is the concern. I'd hope .NET 5 is distributed similarly.

lmcdougald on 5 Jun 2020

@lmcdougald I invite you to open an issue at .NET Core Installer and request .NET 5 use Framework Packaging for servicing as well.

marb2000 on 5 Jun 2020

@jonasnordlund there is another discussion #2500 where we are talking about the WinRT Runtime deployment. Perhaps you find some answer there. :)

marb2000 on 5 Jun 2020

@marb2000 I've opened an issue, but I'm honestly baffled. Is this not seen as essential for any app that would deliver Windows 10X?

lmcdougald on 5 Jun 2020

Here's a compilation of several features, some of which are not directly WinUI, but their lack directly impact the experience of any .NET client development - UWP clients included, and especially LoB app clients.

First and foremost top-priority to me, is for you to nurture the Uno Platform. To me, it is what makes UWP relevant, I'd have compromised on XF or another technology if Uno wasn't around. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
Abstract client-side identity management API to be used from ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
Full data-annotations support, validations and UI titles, string lengths, required-attributes, read-only fields, watermarks etc. etc. etc. (https://bit.ly/3gcMJ3a)
Improve OData so that it becomes a proper alternative to what RIA services used to be. For instance: support attribute generation, interface implementations, generic types, XML docs (https://github.com/OData/odata.net/issues/1746)
Bring in all missing features from WPF
x:Bind should also have all features Binding has, such as scopes or nested bindings (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
Hot restart (https://github.com/microsoft/ProjectReunion/issues/44)
More than simple Hello World templates. Like such that accommodate for user-login, MVVM, routing, x-plat projects (such as Uno-Platform), etc. In other words please give more power to WTS.
XAML WYSIWYG-editor layout features like in WinForms, such as docking, spacing etc. - this seems to be completed! ❤

weitzhandler on 5 Jun 2020

🚀3 😕2

Thanks for your compilation @weitzhandler, very convenient.

WinUI team has a great relationship with Uno product team (non-Microsoft), Xamarin Forms/MAUI team, and React Native. We actively collaborate with them and we wish them a successful future.

About the missing WPF features, can you list your top ones, please? Closing the gap between WPF and WinUI is one of our goals. It will take several releases, though.

Apropos of more complex templates. The Window Template Studio has this mission.

marb2000 on 5 Jun 2020

❤1

I made an issue to try to gather areas where WinUI is lacking compared to WPF #719 @weitzhandler @marb2000

mdtauk on 5 Jun 2020

❤5 🎉1

Apropos of more complex templates. The Window Template Studio has this mission.

@marb2000 could we bring Window Template Studio into our VSIX? Or perhaps vice-versa? Just use Window Template Studio as the vehicle for shipping all WinUI3 (and Project Reunion) templates moving forward?

stevenbrix on 5 Jun 2020

🚀3

Apropos of more complex templates. The Window Template Studio has this mission.

@marb2000 could we bring Window Template Studio into our VSIX? Or perhaps vice-versa? Just use Window Template Studio as the vehicle for shipping all WinUI3 (and Project Reunion) templates moving forward?

👀 @crutkas @sibille

mrlacey on 5 Jun 2020

❤3

I suggest spending some time with C++ Builder (VCL/FMX) and Qt Creator/Design studio, to learn what is possible with C++ and modern tooling.

Ideally WinUI would offer similar tooling to these products do already today for cross platform GUIs written in C++.

What I care about is the .NET development experience and having a similar experience for the use cases I am forced to use C++, that for whatever reason aren't made available to us.

C++ Builder and QtCreator achieve such experience, and it would be welcomed if .NET developers could feel at home when faced with having to spend a couple of days writing C++/WinRT code.

pjmlp on 6 Jun 2020

Why make this about .NET developers? The C++ XAML experience is just bad, doesn't matter if you're a C++ or .NET developer.

sylveon on 6 Jun 2020

I believe that it will be great if they open road to enable the same XAML run on Desktop, Web (Edge), Mobile and IoT.

TonyHenrique on 6 Jun 2020

When will we be able to use WinUI 3 in a c++ project with no C#, Xaml or a designer?
also is there any news on the date of the open sourcing of WinUI 3's c++ core?

Edit: I guess I got an answer for my first question, it looks like there is a c++ WinUI 3 project template in WinUI 3.0 Preview 1:

After installing the .vsix extension you can create a new WinUI 3.0 project by searching for "WinUI" and selecting one of the available C# or C++ templates.

wis on 7 Jun 2020

The use case I would love for WinUI to improve on, is that of making small GUI based tools for frontline IT support staff which are often written in PowerShell. It would be great to be able to make these kinds of tools in Visual Studio Code. Even a C# based VSCode development option would be a great step. Full blown Visual Studio feels rather heavy and complex for this case.

Currently enterprise environments are using tools like these instead:

https://poshgui.com/ (web based XAML wizard)
Sapien PowerShell Studio 2020 (proprietary)
Admin Script Editor (ASE) (a now abandoned project)

Other commonly used "use Visual Studio for the XAML" patterns are described here:

carwyn on 14 Jun 2020

My question is in the context of @mqudsi question he asked in May, but nobody responded.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

Since this is a desktop application we cannot use ICoreWindowInterop and I have tried randomized swags such as new HandleRef(this, ThisPtr) where 'this' is of type Microsoft.UI.Xaml.Window but keep seeing the errno for Invalid Window Handle. Once I do finally obtain that hwnd, I can attempt to use more COM to change the window style and share with others so they don't feel the pain that I do right now :).

jtbrower on 3 Jul 2020

For anyone interested, this is the quick approach I used to grab the hWnd for the main window so that I could make it borderless. The complete solution for WPF equivelent of WindowStyle = None is over here.

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

At this time there does not seem to be an easy to find / documented way to obtain the hWnd when your WinUI is in a desktop process so that's why I turned to the approach I used. Seems to work well enough.

jtbrower on 3 Jul 2020

I think maybe UWP and Universal Windows as terms should go away. The terms carry some unfortunate baggage which leads devs to shy away.

Perhaps we could replace the template WinUI (Universal Windows) with WinUI (Win64)? Then have the option of Desktop or Store?

VagueGit on 21 Aug 2020

Win64 is confusing - it would imply that the Win32 API only supports 32-bits, and that conversely UWP only supports 64 bits, both of which are false.

The Win32 name on its own already confuses a ton of beginners, we don't need Win64 to make matters worse.

sylveon on 21 Aug 2020

👍1

@VagueGit something I have learned is that picking the right name and crafting the story is one of the more complicated things. Better than replace a name, we (Microsoft) should deliver the right product (and story) to help you succeed. UWP is a well-known terminology as Win32, so we should continue to use them.

This is our approach (very simplified):

WinUI can be used in two "types" of apps that target different devices:

Your app targets a lot of devices with a lot of inputs and form-factors. Then use UWP. UWP was created for that; hence you have to meet requirements like packaging model, store, application model, security container, etc.

Your app only targets Desktop and requires full access to the OS. Use Win32 or Desktop (which is how Visual Studio calls WPF, WinForms, MFC, apps).

WinUI in UWP apps and WinUI in Desktop apps (or UWP WinUI app or Desktop WinUI app) fit better with the goal of the project template.

marb2000 on 21 Aug 2020

@marb2000 Naming things is hard, agreed. But some names are unfortunately toxic and should be left behind. That's why from time to time products are rebranded. UWP is one, but that's only my view ... and everyone I talk to. But there you go.

We have a UWP app that we want to migrate to WinUI. We don't use the Win32 api, we only target the desktop and we don't want to use the store. How does that fit?

VagueGit on 21 Aug 2020

@marb2000 Naming things is hard, agreed. But some names are unfortunately toxic and should be left behind. That's why from time to time products are rebranded. UWP is one, but that's only my view ... and everyone I talk to. But there you go.

We have a UWP app that we want to migrate to WinUI. We don't use the Win32 api, we only target the desktop and we don't want to use the store. How does that fit?

Who is the app for, exactly?

As a consumer who goes out of his way to use UWP apps, if the app isn't in the store, I'm probably not going to touch it, let alone see it.

shaheedmalik on 21 Aug 2020

Don't worry @shaheedmalik we won't be asking you to touch it :-). We write business apps. Win32 and UWP. We have a UWP app which has been in the store for a few years but not visible in the store. We have an established business customer base going back 30 years. They are happy with our UWP app but unhappy with the store experience so we are moving it out of the store.

So we know there is a market for Win64 business apps and we believe we are among the few business devs who have delivered Win64 apps that business customers will pay for. I know there are a few devs on this thread who go down the Universal Windows/multi-platform route, but they are quite rare. Most business devs in my experience target a specific form factor.

So speaking from the perspective of a dev company that has invested heavily in UWP and made a business success of UWP, maybe templates for WinUI (Desktop) and WinUI (Store)? You only need to follow the tech media to get an idea of how poorly UWP is seen as a dev platform.

VagueGit on 21 Aug 2020

@VagueGit
"We have a UWP app that we want to migrate to WinUI. We don't use the Win32 api, we only target the desktop and we don't want to use the store. How does that fit?"

So do you want to migrate a UWP to WinUI 3 and deploy outside of the Store? A naïve question: did you try the MSIX's sideload? Any reason besides the Store that stops you use UWP?

@VagueGit
"So we know there is a market for Win64 business apps."

One question, Win64 stands for a lot of things. e.g. apps compile for x64. What does Win64 mean for you?

marb2000 on 21 Aug 2020

@marb2000 UWP has poor support for business reporting. We think that rebranding might help kickstart the development of third party tools like report writers. We've had a play with side-loading but it was not feasible for us until 20H1 as sideloading was not enabled by default.

We think Win64 is the way forward on Windows. Micro$ has in the past attempted to pitch Win32 as legacy without success and is now winding back on that position. But ultimately Win32 has to go away, in our judgement (I say that after 30 years of Win32 development myself). We've managed to overcome most of the limitations of UWP to deliver a business app that companies will buy. We're concerned that another iteration of UWP will have limited traction without rebranding.

VagueGit on 21 Aug 2020

As the confusion from @marb2000 shows, the term Win64 is already (poorly) used. I've also pointed that out earlier.

I agree that a rebranding might be needed, but Win64 is a terrible way of doing it. Until there is something official, you should use the term UWP to be understood by everyone.

sylveon on 21 Aug 2020

@sylveon UWP is understood by everyone to be a failure. We like it but few others do. That's why rebranding is important. What do you think of WinUI (Deskop) or WinUI (Store) as project templates?

VagueGit on 21 Aug 2020

👎1

WinUI (Store) is not good because you can also ship Win32 apps in the store, or ship UWP apps outside of the store. WinUI (Desktop) is good however.

sylveon on 21 Aug 2020

👍4

@sylveon WinUI (Store) doesn't preclude other projects that target the store. It just means you want to start with the set of capabilities that enable release through the store.

VagueGit on 21 Aug 2020

It's bad enough to confuse beginners.

sylveon on 21 Aug 2020

This isn’t meant to be directed at any particular person in this thread, but rather my own opinion as a desktop application developer/company owner.

I’m never caught up in what something is named. I only care what features it has and how well it is supported.

I would argue that there are also a lot of developers (me included) that become excited when we here terms like MAUI, but are immediately let down when we realize it’s still the same code base. The rebranding suggests “hey look, we are building this brand new thing that starts from a code base that’s entirely different than the one that’s blocked you from xyz”. What I LOVE to see is a huge list of features that changed which offset struggles that I or anyone else had.

Platforms develop over time just like any product or brand does. I find comfort in brands and names that have been around for decades because it automatically implies LTS. Although I do realize that name changes are sometimes a necessity, they also remind developers of abandonment (Silverlight). There are a lot of automobile models in existence that had years where they were plagued with problems but ended up becoming love and respected brands. There is a lot to be said with familiarity, even if you don’t like the prior experiences, because you know what to expect. As long as problems are resolved, that’s really what counts.

I think there are at least two audiences that need to be considered; developers and end product users. As a developer/business owner, if I have a customer that needs an application, and they have been soured by underlying technology names, it’s my job to instill confidence in them that the product represented by the name has matured and what concerned them in the past has been updated. On the other hand, if I say “look there is this new great thing called WinUI or MAUI” and they already own WPF or UWP or Xamarin products that we developed for them, a foreseeable response from them is “oh great, now our apps are written in 2,3 or 4 different technologies”. This is where I then have to sell them. Considering all customers are different, I’m going to encounter pushback whether you leave the name as is, or change it.

What’s important in the end (to me) is that we have the tools we need to write appealing, feature rich applications that have LTS. I get pumped when I see a product hit deadlines and I get to read the new feature and issue resolution list when the product is released. I have loved this about NetCore/Net5 (name change LOL) since 2016. (BTW, trying to tell my customers that .Net5 is what we plan to target a year after I convinced them to move to NetCore isn’t easy either!)

Right now I just want to fast forward to a point when I can write a desktop application with XAML dialect and obtain the same rendering performance that UWP/WinUI offers (without the UWP sandbox). For that reason and due to the dropped September preview, I’m going to start test driving Avalonia. I love the WPF similarities while hearing about the rendering performance via SkiaSharp.

It’s going to be exciting in a couple years when the options for UI development have stabilized. They can name project templates whatever they want, it won’t change my opinion of the lack of features.

I do appreciate you all.

jtbrower on 21 Aug 2020

😄1 👍1

I get what jtbrower says in his email. His company like ours is one of the few which went successfully down the xaml path. We don't need to be convinced of the benefits.

But good as it might be, xaml was a disaster for Micro$. Developers overwhelmingly either stayed with WinForms, or jumped ship entirely to web development. Since UWP the exodus of developers worsened.

For xaml technologies to be sustainable, Micro$ must win those millions of devs who they have failed to onboard. To those devs, to tools vendors and to the tech media, UWP is a dead end. Another iteration of UWP won't win them over.

VagueGit on 22 Aug 2020

👎1

@VagueGit but developers are keen enough to know a renamed product as the same. They know MAUI as a renamed Xamarin Forms. In fact they seem to go so far to say that MAUI was a stolen name. I don't think you can motivate a typical developer with a name change. We all want features don't we? Wouldn't you rather see UWP allow multiple Windows, or allow full trust? If they did both, we could all target UWP and maybe keep the sandbox for store apps. I'm just dreaming out loud what would really get me pumped up excited! Features!!

jtbrower on 22 Aug 2020

Absolutely agree with you jtbrower. I also appreciate your helping me and I hope others critique their ideas. But how to flag to devs and tools vendors that there are two different UWPs, Store and Desktop?

So by all means those who want to continue along the UWP path can start with the UWP Store template, but those who want 64bit desktop, not sandboxed and full trust ... well that isn't UWP is it?

UWP is seen in the market as crippled. All but us die-hards gave up on UWP when Micro$ itself pulled back from building their own apps in UWP.

The dev market doesn't watch for developments in UWP. 64bit desktop, not sandboxed and full trust, is much more than a name change; it is a different paradigm. But if it is still called UWP it will go unnoticed by those who have written off UWP.

VagueGit on 22 Aug 2020

👍2

@VagueGit I'm glad that you have found success with UWP. Naming is hard, and the fact that we call it the "Universal Windows Platform" and it's not really tenable by the vast majority of Windows developers makes it, well, not very "universal". An accurate summary of Project Reunion is to fix this and make every aspect of UWP truly accessible by all Windows developers.

I agree that UWP has a bad name, if you type the phrase "UWP is" into a search engine, the first auto-suggestion Bing or Google will give you is "UWP is dead". However, I do think @marb2000 is right that we should continue to use the name, despite the baggage that it carries.

With that being said...

Today, many aspects of the Desktop projects will be able to use different parts of what we used to define as "UWP":

The UI stack (aka WinUI3)
MSIX Packaging
MRT Resources

Once CoreApplication is lifted, then the only difference between UWP and Desktop will truly be the sandbox model that you choose for your application and which devices you're able to target.

We've discussed making modifications to the project templates and having a wizard like experience that more accurately describes this.

@JeanRoca is the PM driving this and may have more information he can share

stevenbrix on 27 Aug 2020

😄1 👍1

I like the idea of WinUI Desktop template. More appropriate than Win32 and forward looking. It's the template we would start with whereas Win32 suggested a 32bit constraint. WinUI Desktop will hopefully get some traction in the media and among devs.

VagueGit on 27 Aug 2020

👍1

When a UWP app is released outside the store the package is .appinstaller. If we upgrade that app to Win UI Desktop, the installer package changes from appinstaller to msix.

Assuming we keep the details within the app package the same and bump the version appropriately, will Windows recognise this is a new version of the same app and preserve local data, or will it install it as a different app?

VagueGit on 27 Aug 2020

👍1

From my understanding, WinUI 3.0 will never be consumed from .NET Framework <= 4.8. So if we're talking about WinUI, we're either talking about .NET Native or .NET 3.1/5+ (or another set of bindings).

Any suggestions as to how to advance/ask further about framework packaging for .NET 5 (or I guess 6 at this point)? I opened an issue and got no response. Bundling .NET 5 in-app is a nonstarter.

lmcdougald on 27 Aug 2020

👍1

@stevenbrix

Once CoreApplication is lifted, then the only difference between UWP and Desktop will truly be the sandbox model that you choose for your application and which devices you're able to target.

Unfortunately another big difference is .NET developers being forced to drop to C++ for APIs like DirectX, whose team clearly refuses to make them UWP compatible in spite of being COM based.

And in the process drop back to the productivity days of manually writing MIDL with a nice notepad like experience, and copying files around, apparently Windows team cannot let go of ATL like dev experience, instead of providing a NET like experience for C++ workflows. C++/CX was getting too closed to C++ Builder, so it had to be killed in name of ISO stuff, that with luck we might get them in C++23 and in 2025 in VS.

I doubt anyone will care about UWP by then, unless a proper development experience is set in place to clear all these wrongdoings.

Also throwing us are GitHub issues regarding which team to give feedback to is a very quick way to lose interest. I just happen to care too much apparently.

pjmlp on 27 Aug 2020

❤1 👍1

The DirectX APIs cannot be modified for WinRT compatibility because it would be a significant API break for existing consumers, and that just cannot happen.

There are multiple managed wrappers available for DirectX, like TerraFX which is a raw 1:1 binding or Vortice which is a more C#-style API wrapper.

As for CX, it had to go away. Compiler-specific language extensions are bad and frowned upon. It significantly hampers code portability, often lags behind in terms of C++ standard support, and requires full vertical integration from existing libraries. The alternative, WRL, was very difficult to use and overly verbose. So, it's not surprising that a lot of people (including the DX division) did not want to write WinRT APIs.

C++/WinRT is a much better solution, it's unfortunate that it had to bring back IDL (but a necessary evil currently). The C++ team has been doing a much better job at standards support than before, so it wouldn't be surprising if we actually get metaclasses before C++23 is finalized, which should improve the developer UX radically.

sylveon on 27 Aug 2020

❤1

@sylveon

Don't be surprised that the Windows development community ignores whatever comes out of Redmond with such justification for productivity drop.

pjmlp on 27 Aug 2020

The same was happening with CX... it was largely unused because C++ developers don't like proprietary language extensions.

sylveon on 27 Aug 2020

Assuming we keep the details within the app package the same and bump the version appropriately, will Windows recognize this is a new version of the same app and preserve local data, or will it install it as a different app?

@VagueGit, this is a great question. At the end of the day, the tech for installing UWP and Desktop apps is the same. I feel like the answer is yes? I think as of more recent SDKs, even UWP apps have the .msix extension (I could be wrong, so don't quote me). I'm sure you could try this out locally and find out? @adambraden for fyi.

Any suggestions as to how to advance/ask further about framework packaging for .NET 5 (or I guess 6 at this point)? I opened an issue and got no response. Bundling .NET 5 in-app is a nonstarter.

@lmcdougald I think I know which issue you are referring to (but I can't find it). There will be one, but I imagine it will be in the .net6 timeframe. Everyone is aware this is something that needs to be done.

And in the process drop back to the productivity days of manually writing MIDL with a nice notepad like experience, and copying files around, apparently Windows team cannot let go of ATL like dev experience, instead of providing a NET like experience for C++ workflows. C++/CX was getting too closed to C++ Builder, so it had to be killed in name of ISO stuff, that with luck we might get them in C++23 and in 2025 in VS.

Also throwing us are GitHub issues regarding which team to give feedback to is a very quick way to lose interest. I just happen to care too much apparently.

@pjmlp I appreciate your honesty and passion. I couldn't agree more that the current C++ experience is subpar. We've done quite a few things to make the C++ experience more like .NET, but as @sylveon mentioned, they come at a cost. We eventually decided that if we want to spend engineering effort on making C++ great, we should pour that into pushing the C++ standard. It is unfortunate that meta classes are a ways out, and we are discussing ways to improve the experience in the interim, because I agree with you that we can't wait that long.

stevenbrix on 27 Aug 2020

👍1

Thank you for the response – I’m content with “everyone is aware this is something that needs to be done” and I’ll live with an inflated binary for a year or so.

lmcdougald on 27 Aug 2020

@stevenbrix and @VagueGit - you should still be able to use an appinstaller file for your msix packages. the appinstaller file is nothing more than a json file providing the uri to your packages. Since you mentioned enterprise scenarios, you could customize the appinstaller uri's appropriately for internal locations, or make them different for external access as well - all dpeendent upon your CDN. Regarding versioning - yes for packaged apps if the Package Identity is the same, then installing a new version will have access to the existing appdata.

AdamBraden on 27 Aug 2020

❤1

@stevenbrix @VagueGit I will reply with the information I currently have on the wizard like experience. I am still very new in this role so feel free to take everything I say with a grain of salt. With that being said, my team is currently driving the efforts in Windows Template Studio. This application currently lets you create a new WPF or UWP app from existing templates in our wizard with the pages and frameworks you desire.

The goal and current plan for this application in the future is to unify and improve the development experience for all users. We are currently developing templates for desktop apps with WinUI 3. You can find the tracking issue here. We are also discussing doing the same for UWP so that our users can easily migrate their projects when the time comes. We still don't know exactly how this will work out, but our goal will be to unify and simplify the experience as much as possible. Hope that helps!

JeanRoca on 29 Aug 2020

👍2

The same was happening with CX... it was largely unused because C++ developers don't like proprietary language extensions.

They love them on clang, GCC, Intel. xlCC, PGI, CUDA, C++ Builder and the plethora from embedded platforms.

Obviously CX was killed due to politics that cannot accept a C++ RAD environment coming from Microsoft, and rather have us all doing MDIL/ATL with a notepad like experience instead.

pjmlp on 30 Aug 2020

I avoid them at all costs no matter the compiler. Especially when said proprietary extension is a completely different language on its own.

sylveon on 30 Aug 2020

I avoid them at all costs no matter the compiler. Especially when said proprietary extension is a completely different language on its own.

Then why coding against a proprietary UI like WinUI, just use open standards like X Windows instead.

pjmlp on 30 Aug 2020

... as if that's usable on Windows. I avoid compiler extensions because I want to multitarget compilers (Clang and MSVC) for standards compliance validation and want to use newer C++ standards.

My code uses C++20. Many language extensions lack C++17 support or got it very late. This situation will repeat with C++20 (or worsen since C++20 has a lot more new stuff than 17 did). For example, you cannot mix C++20 (/std:c++latest) and CX (/ZW), you'll get a compiler error saying the two switches are incompatible.

It took until this year for NVCC to support device-side C++17. Not a good look.

I don't want to put myself in a corner where the language extension I use is not usable with a newer standard but I also need a new standard feature.

For the reasons above, I avoid them. If we regress the WinUI C++ developer experience to a language extension, I'll move to an alternative GUI framework.

sylveon on 30 Aug 2020

@sylveon You perfectly portable C++20 for WinUI is completely useless outside Windows, go have fun with Qt without extensions as well.

Because nothing else worth using is left for C++ desktop users.

Thanks for confirming that senseless politics are what killed CX.

pjmlp on 30 Aug 2020

Suggestion to be friendly to each other. I cannot comment on the technical c++ arguments and won't judge who is right.
The point is that phrases like go have fun with X are not setting a friendly and collaborative ambience here. @stevenbrix and others please step in if needed.

hansmbakker on 30 Aug 2020

👍2

Thanks @hansmbakker ☺️

@pjmm and @sylveon I appreciate the passionate and honest conversation, it's great to have customers like you that care.

Both points are extremely valid, and I think the world is big enough for both you to be right.

@pjmlp we are not satisfied with the current experience for c++, and do recognize that we need to do something before c++ metaclasses. We've had some discussions about idl-free c++/winrt, and @kennykerr and @Scottj1s did a Build talk about it. Most of the problems we had were related to integration with WinUI, as our compiler requires metadata. We want to revisit this workflow to see if we can have a cohesive story that will improve the overall developer experience. Instead of bringing back C++/Cx, Would an idl-free version of c++/winrt interest you?

Just to set expectations, I wouldn't expect to see much progress here in 2020.

stevenbrix on 30 Aug 2020

I'd be very much interested in an IDL free C++/WinRT.

The IDE experience isn't the best either. For example we can't create an event callback from the XAML editor like we can with C# (the create new callback drop-down does nothing). Navigate to definition from the XAML editor also doesn't works.

Other problems with it are the various XAML compiler bugs I filled in this repo, which makes me require workarounds that are not required in other supported languages.

sylveon on 30 Aug 2020

@stevenbrix , I'd like to add my voice to IDL-free C++/WinRT (and certainly don't want to see a return to C++/CX). We write cross-platform software, and we compile with both MSVC and LLVM (including on Windows), so standards compliant C++ is very important to us.

MarkIngramUK on 30 Aug 2020

❤1

@stevenbrix ,

@pjmlp we are not satisfied with the current experience for c++, and do recognize that we need to do something before c++ metaclasses. We've had some discussions about idl-free c++/winrt, and @kennykerr and @Scottj1s did a Build talk about it. Most of the problems we had were related to integration with WinUI, as our compiler requires metadata. We want to revisit this workflow to see if we can have a cohesive story that will improve the overall developer experience. Instead of bringing back C++/Cx, Would an idl-free version of c++/winrt interest you?

Just to set expectations, I wouldn't expect to see much progress here in 2020.

Which just goes to show how bad this whole idea with C++/WinRT was to start with, ramping it down on us without any consideration for our productivity drop.

To put this in perspective, long time developer whose Windows developer experience goes all the way back to Windows 3.0, and nowadays C++ is mostly relevant to be used alongside .NET based applications, never on its own alone.

Borland tools were my bread and butter until for various reasons known to old time Windows developers, the path forward ended being to migrate into Microsoft compilers.

Visual C++ was never _Visual_ as C++ Builder, not even with C++/CLI, given its lack of integration with Forms and AOT compilation.

C++/CX seemed that Microsoft had finally gotten it, we would 25 years later be given the same productivity workflows as using Delphi/C++ Builder alongside each other.

Instead what we have gotten as a political move to kill C++/CX without any regard for our productivy drop hand waving the responsibility for the missing features to ISO C++ and WG 21, as if everything that Visual C++ team is taking away from us will be accepted by WG 21.

And even if the necessary features will eventually be adopted by ISO C++, will it be 2023, 2026,....? And then there is the whole point of when will those features actually be made available to Windows developers, just look at modules support. We are taking about endless years to reach parity with what C++/CX has been offering us since Windows 8 has been released in 2012.

So given that by 2020 we won't see any improvements, we are already talking about 9 years here, so excuse me if I tend to be bit angered by how all of this has been managed, on top of the other issues that we have to deal with UWP failure, Reunion, .NET eco-system reboot, while we get asked to code like it was 2000 with bare bones MIDL notepad experience and endless template soup like ATL.

So yes, either an IDL free C++/WinRT version, or at very least an IDL experience with full Intellisense/Intelicode support and not having to manually copy files around. However that won't take away the ATL like experience from the C++ code itself.

From .NET/C++ development point of view, I don't care about time travel into the past of Microsoft frameworks, rather how it could look like if the C++ RAD point of view was taken more seriously, unfortunately with the way the C++/WinRT story has been managed, and everything else that is now going with backpedaling from UWP, I wonder where "developers, developers, developers" has gone to.

So sorry if it still feels a bit ranty, but that is how I feel about my productivity drop when I need to step out of .NET into C++, in name of some ISO purity that most C++ compilers don't do anyway.

pjmlp on 31 Aug 2020

👎2

C++ is very much still relevant standalone. A lot of applications are written in raw C++ without any managed code running. In fact, the entire UWP runtime and XAML/WinUI framework is native C++. An UWP app written in C++ has (thankfully) no managed language involved.

I'd argue that if you feel the need to drop to C++ in .NET, you should ask yourself why and try to address those issues directly within .NET. Performance? Use the span types, stackalloc, and vector intrinsics. DirectX, native APIs, or COM? Use a binding like TerraFX. Interacting with a C++ only lib? Reimplement what you need from it in .NET.

.NET is better off without C++, and C++ is better off without .NET.

I don't think the templating in cppwinrt is that bad. What annoys me the most is the need for code gen and the horrible compile time it produces.

sylveon on 31 Aug 2020

👍4

@sylveon Easy, because of the APIs that the Windows team refuses to make available as UWP and no third party bindings don't count, not everyone is blessed with a legal department that lets anything go, without considerations of license and future support issues.

Borland (now Embarcadero), and The Qt Company have shown how to do it, it is up to Microsoft to decide how relevant they want to keep the platform.

Try to see how far you will go with ISO C++ in macOS, iOS, Android, ChromeOS GUIs.

Anyway, stopping here, this is pointless.

pjmlp on 31 Aug 2020

@pjmlp we have cross-platform applications with millions of lines of ISO C++ that work just fine on iOS/macOS/Windows. C++ is the only language to use when you care about performance and / or battery life. C++ extensions are no good for us as we use multiple compilers (who obviously don't implement each other's extensions).
We've used C++/CLI previously and it is such a pain. Restrictions such as class members only allowing raw C++ pointers makes it difficult to store smart pointers. Compilation time is long (single character changes requires 5 minutes of MD Merge time).
C++ includes require wrapping to change pragma managed / unmanaged
The compiler is a different version for C++/CLI compared to C++ (and I was told at build that C++/CLI compiler wouldn't support later than C++17, which is a problem when including headers from libraries that use C++20 features).
What I'm trying to say is, don't have multiple competing efforts. Stick with the standard and work with that. Microsoft are on the C++ committee, they help drive the standard forward, this should be the focus, not proprietary, locked in extensions.

MarkIngramUK on 31 Aug 2020

👍2

Could we have a xaml compiler, such as xaml.exe to compile xaml files, similar with midl.exe, cl.exe, or link.exe? It would be very useful to build auto pipeline for winui application.

Sometimes, we don't want use visual studio to do the develop, maybe using any editor we want, but keep a build pipeline separated. It seems that the winui application xaml is special part and it seems that there is no command line tool to compile it yet.

sammi on 11 Sep 2020

👀1 👍1

This is required for scenarios such as cmake: https://github.com/microsoft/ProjectReunion/issues/58

sylveon on 11 Sep 2020

Could we have a xaml compiler, such as xaml.exe to compile xaml files, similar with midl.exe, cl.exe, or link.exe? It would be very useful to build auto pipeline for winui application.

@sammi does #1433 summarize a plausible solution to what your looking for?

jtbrower on 12 Sep 2020

Could we have a xaml compiler, such as xaml.exe to compile xaml files, similar with midl.exe, cl.exe, or link.exe? It would be very useful to build auto pipeline for winui application.

@sammi does #1433 summarize a plausible solution to what your looking for?

@jtbrower, that is exactly feature I'm looking for, thanks!

sammi on 12 Sep 2020

Certainly it's a preview, and that means I shouldn't expect much, but WinUI 3 preview 2 was disappointing for me.

My biggest need is in the area of XAML designing. I was pretty taken aback by the fact that the XAML designer didn't work at all, and so far I've found no clear information as to when it will.

Yes, I agree the current XAML Designer in Visual Studio is very slow, and it breaks when one changes things in realtime that really shouldn't break it. For instance, changing Height="*" to "Auto" or a 100. (error window spits about 10 errors out -- squiggles galore, and you have to rebuild the project)

To be clear -- I don't really use the designer to design -- I just want to have an idea if my layout looks like I had envisioned it before going through the build process. If easier, if the designer was just "View only", and it updated as I tweaked the XAML (without crashing), that would be fine for me, as I don't use the GUI to change the XAML.. or very rarely. Really, what the WindowsCommunityToolkit does with XAML source that lets the user change the source and see the output in realtime is good enough for my purposes.

All that said, WinUI has a great idea -- decouple all this "Easy" stuff from the OS, and let the developer's work evolve much more quickly, and we can bundle the dependencies with the app to avoid having to have to upgrade 1Bn devices so they can run our new great stuff.

I hope Project Reunion also ends up totally separating the GUI from the app container. UWP-like UX with no sandbox/boundaries would be a great step forward.

But when can we have a XAML Designer that works again... please?

ericleigh007 on 16 Nov 2020

I think hot reload has mostly deprecated that "view-only" purpose of the XAML designer.

sylveon on 16 Nov 2020

But we're talking about WinUI tooling here. Hot reload and live visual tree don't work for WinUI either.

What I meant with the View Only designer was "I could settle for that if it was something we could put into an upcoming preview"

I could be wrong (AND please TELL me if I am), but right now, the only way to see your UI in WinUI is to build and run it.

ericleigh007 on 16 Nov 2020

But we're talking about WinUI tooling here. Hot reload and live visual tree don't work for WinUI either.

What I meant with the View Only designer was "I could settle for that if it was something we could put into an upcoming preview"

I could be wrong (AND please TELL me if I am), but right now, the only way to see your UI in WinUI is to build and run it.

Hey @ericleigh007 have you had a chance to check out our latest release WinUI 3 Preview 3? We recently added many tooling improvements such as IntelliSense, Hot Reload, Live Visual Tree and Live Property Explorer. You can check the release notes here and get the latest preview here. I am interested in your thoughts so please feel free to reach out!

JeanRoca on 18 Nov 2020

👍1

@JeanRoca Unfortunely catching up with C++/CX development experience wasn't one of those tooling improvements. Don't expect much developer love for WinUI when the proposed C++ tooling feels like going back to 2000, writing IDL files in notepad (without any editor support) and manually copying files around.

It makes me stay in .NET as much as I can, or just keep using C++/CX despite the warnings to move into C++/WinRT.

pjmlp on 18 Nov 2020

Thanks for the update; Will be trying that today, and will report back. 🤞

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

From: JeanRocanotifications@github.com
Sent: Wednesday, November 18, 2020 4:41 AM
To: microsoft/microsoft-ui-xamlmicrosoft-ui-xaml@noreply.github.com
Cc: Ericericleigh007@outlook.com; Mentionmention@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Developer Experience and Tooling - Input Needed (#1045)

But we're talking about WinUI tooling here. Hot reload and live visual tree don't work for WinUI either.

What I meant with the View Only designer was "I could settle for that if it was something we could put into an upcoming preview"

I could be wrong (AND please TELL me if I am), but right now, the only way to see your UI in WinUI is to build and run it.

Hey @ericleigh007https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwKvAkLEJfFG2SU10iZkzgSTB%2BmCZc%3D&reserved=0 have you had a chance to check out our latest release WinUI 3 Preview 3? We recently added many tooling improvements such as IntelliSense, Hot Reload, Live Visual Tree and Live Property Explorer. You can check the release notes herehttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE%3D&reserved=0 and get the latest preview herehttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fapps%2Fwinui%2Fwinui3%2F&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160092685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VF2s7jilqpksevP6Fx7mXW1QCNJN2%2BK5yWOndg3rKoc%3D&reserved=0. I am interested in your thoughts so please feel free to reach out!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment-729402012&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160092685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1S2JpfBSzsNKJBAH5%2Fgme8Bq%2FjHbzB9FySk1KnZKbk%3D&reserved=0, or unsubscribehttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160102680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0H6IpND3YX1s6oyXy%2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserved=0.

ericleigh007 on 18 Nov 2020

-There is no wysiwyg editor / method that works with winui3 c++ (desktop) right now, right ?

niclar on 18 Nov 2020

Microsoft is managing to alienate C++/CX users as well? This whole thing isn't shaping up well at all. Anyone who adopted the technology Microsoft was pushing a few years ago for UWP whether .net or c++ is in trouble now without support from Microsoft.

It seems WinUI 3 is only catering for desktop apps written in WPF -- but they are going to quickly realize that UWP doesn't have all the features of WPF and WinUI less features still. Everyone is going to be frustrated which is a bad place to start WinUI 3.

robloo on 18 Nov 2020

👍1

@robloo As someone that used to advocate UWP they lost me, it is WPF and Win32 until they sort out the mess.

C++/WinRT was a political move, and we were told just to suck it up and wait until ISO C++ eventually provide reflection and metaclasses support, for Visual Studio team to replicate the C++/CX experience.

As mentioned even editing IDL files is no different than using raw Notepad.

That we in .NET had to put up with Microsoft not making all UWP components available to us, was somehow bareable with C++/CX offering an C++/CLI like experience. Now with C++/WinRT we are back to ATL.

Then by reading the Reunion issues discussions and the update roadmap, it is clear they will take several years to correct course.

WPF and Win32 might be old, but they are here and work, without having yet another rewrite and loss of features.

pjmlp on 18 Nov 2020

👍1

-There is no wysiwyg editor / method that works with winui3 c++ (desktop) right now, right ?

The XAML designer sort of works, but it wasn't really designed for wysiwyg editing to begin with. Hot reload (which now works in preview 3) works better.

sylveon on 18 Nov 2020

live visual tree and live prop view work great in preview 3. When is designer scheduled to be available?

Also noticed the desktop (WPF) (not UWP) designer used to work in 2.4 (or something) but now my tests don't see it working again? Am I missing something with the current state of the designer?

ericleigh007 on 18 Nov 2020

Sorry I'm late to the party. @wjk nailed it with his first point.

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 really appreciate the allure of MSIX, but this certificate signing mandate is a deal breaker for me. I need a proper SCM-friendly installer wizard that I can use to create a classic Desktop Installer experience. Why not take the improvements in MSIX and create a new version of the MSI installer without the Microsoft Store and certification requirements for a more modern development experience? Perhaps this is what is meant by the "Supports non-MSIX deployment" feature listed in the current Roadmap? If so, I guess I'm stuck waiting for 3.x, unless by some miracle, that makes it into an earlier release. Looking forward to that because VS Installer Projects are tragically outdated and not at all friendly to source control. 😓

Chiramisu on 19 Nov 2020

@Chiramisu I agree with the sentiment, but I'm also confused -- what about the sideloading experience + AppInstaller isn't sufficient?

lmcdougald on 19 Nov 2020

👍1

@Chiramisu Have you tried WiX? I use it for all my MSI-based installers, and it works very, very well. There's also a Visual Studio extension, so you can have WiX projects that automate the various compilation commands.

wjk on 19 Nov 2020

👍1

@robloo As someone that used to advocate UWP they lost me, it is WPF and Win32 until they sort out the mess.

C++/WinRT was a political move, and we were told just to suck it up and wait until ISO C++ eventually provide reflection and metaclasses support, for Visual Studio team to replicate the C++/CX experience.

As mentioned even editing IDL files is no different than using raw Notepad.

That we in .NET had to put up with Microsoft not making all UWP components available to us, was somehow bareable with C++/CX offering an C++/CLI like experience. Now with C++/WinRT we are back to ATL.

Then by reading the Reunion issues discussions and the update roadmap, it is clear they will take several years to correct course.

WPF and Win32 might be old, but they are here and work, without having yet another rewrite and loss of features.

Just so I can keep up, can you clue me in one what IDL editing you're talking about with C++/WinRT? From what I've seen of the co_await and other C++ 17 syntax, the complexity seems to have risen by a large amount from C++/CX.

MS? Isn't it just possible that, unless somebody creates some really good wrappers around that, that C++/WinRT based on C++ 17 capabilities is just too complex and too different from current designs? Couldn't C++/CX be kept around along enough for some "excellent wrapper" to be created for C++ 17 to make C++/WinRT reasonably simple to use and to migrate to?

(now somebody is going to link to an article that shows just how this is done, and i'm going to feel foolish)

ericleigh007 on 20 Nov 2020

@lmcdougald I haven't tried that yet. It should be noted that my particular project is still on .NET Framework 3.5. I know, I know. I haven't been permitted to update it yet, so I'm stuck with what Installer tech will work with this ancient framework. 😖

@wjk I've looked into that in the past, but no, I haven't yet tried it. Though given the above, it seems to be the only tech that may work for my existing project, as is. Have you used this for WinForms apps based on an old framework by any chance? Unfortunately I'm a lone developer, so I have to exercise extreme prejudice with how I spend my time and don't have the liberty to go experiment with new technologies.

Kindly

Chiramisu on 20 Nov 2020

@Chiramisu Yes, WiX works with old versions of the .NET Framework, and yes, it also works with winforms apps. Since it creates raw MSI files, WiX can install anything, in any programming language. In terms of learning it, I would start with the basic tutorials. I’d also like to point out how to detect if .NET is installed, and how to run NGEN on files using WiX, since you’re using those technologies in your app. The Visual Studio extension also comes with a number of project templates, to give you the right skeleton code to add on to. (Note: Don’t use the Bootstrapper template, as that is a much more advanced topic.) Hope this helps!

wjk on 20 Nov 2020

@Chiramisu I'm so confused by what you're looking for -- it seems to me like you're looking for packaging tools for your current project and not for a WinUI 3.0 project.

It's worth noting that .NET Framework 3.5 can be packaged into an MSIX. You could build an MSIX package for your existing app with a Package Project in VS 2019, then go through a long transition somewhat seamlessly, but it's a lot of work:

WinUI 3.0 will never officially support .NET 3.5, and probably won't ever support .NET Framework at any version. I would start your modernization by aiming to upgrade to .NET 4.6 (or ideally higher, 4.8 would be ideal) without changing your existing packaging project. If that goes smoothly, I would then start transitioning functionality out into a .NET Standard shared library that you reference from your updated .NET 4.6+ app.

Once the .NET 4.6 app is stable and tested, you can swap it in as an auto update for your MSIX packaging project. After the .NET Standard step, you can create a project head that uses almost the same code from .NET Core 3.1 (or 5, but I feel like the LTS status probably means something to your organization). Again, test then switch the MSIX to using this version.

Switching to WinUI from WinForms at that point is a matter of learning WinUI and reimplementing the interface. Again, create a new project head, implement + reference the .NET Standard library, test, then switch the package to use this version.

This is how I'd go about modernization without creating wildly divergent projects at any given point. I would prioritize setting up the MSIX packaging and .NET 4.6 + .NET Standard steps, as those will gain you a huge amount more help tools and connection to the modern .NET development cycle. A switch to .NET 5 in a hurry sounds like a bad idea for your org in the short term, considering its lifecycle is 1/10th as long as .NET 3.5 has been around.

lmcdougald on 20 Nov 2020

Just so I can keep up, can you clue me in one what IDL editing you're talking about with C++/WinRT? From what I've seen of the co_await and other C++ 17 syntax, the complexity seems to have risen by a large amount from C++/CX.

MS? Isn't it just possible that, unless somebody creates some really good wrappers around that, that C++/WinRT based on C++ 17 capabilities is just too complex and too different from current designs? Couldn't C++/CX be kept around along enough for some "excellent wrapper" to be created for C++ 17 to make C++/WinRT reasonably simple to use and to migrate to?

(now somebody is going to link to an article that shows just how this is done, and i'm going to feel foolish)

Because normal C++ doesn't have the capabilities to extract the type metadata required to make a .winmd file, you have to write your WinRT classes in an .idl file, on top of .hpp and .cpp.

co_await is much less complex than writing .then([=](Foo^ thing) { }) everywhere, it's very similar to C#'s await syntax.

Here's an example (idl + hpp + cpp) from the default Runtime Component project:

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

Here's a small co_await example:

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

sylveon on 20 Nov 2020

Hi there,

We are reading your feedback and taking notes about the pain points. Please continue doing this.

@ericleigh007 XAML Designer was out because after collecting customer feedback, the top customer's pain points were about improving the developer's inner loop. Hot Reload and Live Visual Tree were on the top. In-app-toolbar is another on the top that it couldn't make the Preview 3. You are right about no being clear when the XAML Designer will be; we need to update the feature roadmap thought. Per the current engineering plan, it's out of the 3.0 RTM, so it's post-3.0.

@pjmlp I sympathize with your paint about C++/WinRT and the need to add the IDLs. C++/CX is much better in this aspect. Improving the C++/WinRT experience is another topic we need to address. Tools like Live Visual Tree and Hot Reload works on both C# and C++, but there are specific things that only affect C++ and need to be tackle separated. Per the current engineering plan, solving the IDL issue is out of the 3.0 RTM.

@robloo, We are no catering to desktop apps written in WPF. C++/WinRT is a first-citizen in the WinUI ecosystem. It's what we use to write WinUI, so we are dogfooding our proper tools and languages.

@Chiramisu Let me explain what "supports non-MSIX deployment" means. Today you need to install and run a Desktop WinUI 3 app using MSIX. This capability is about removing this need. To run a Desktop WinUI 3 app, you only need to double on a .EXE, and that's it. To install your app, you can just do an xcopy (no need to sign anything). Basically, you will be able to use other packaging and installation systems like WiX.

marb2000 on 20 Nov 2020

@marb2000 Thanks for acknowledging the issue. What I and many other Windows developers don't get is why you (as in WinDev management) decided it was a good idea to brute force C++/WinRT upon us with inferior tooling, even going back to MFC feels better, at least we aren't manually copying files around.

Right now I am focusing on ASP.NET, WFP and Win32, just keep following up on UWP stuff with the hope that Microsoft eventually realises that we are fed up with rewriting applications and being dragged over manual configurations, like in the UAP => UWP transition, .NET Framework to .NET Core, or yes C++/CX => C++/WinRT.

This is more of a feedback thing, as a vocal member of the Windows dev community that feels a bit let down with the continuous rewrites since the introduction of Windows 8.

pjmlp on 20 Nov 2020

👍1

@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).

MarkIngramUK on 20 Nov 2020

@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 on 20 Nov 2020

👍1

@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.

MarkIngramUK on 20 Nov 2020

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.

sylveon on 20 Nov 2020

@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 on 21 Nov 2020

👍1

@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.

MarkIngramUK on 21 Nov 2020

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.

sylveon on 21 Nov 2020

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 on 21 Nov 2020

@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 on 21 Nov 2020

can you edit this to fix the typo 'no catering'.. I think that's supposed to be 'now...'

ericleigh007 on 21 Nov 2020

@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.

ackh on 21 Nov 2020

👎1 👍1

@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?

ericleigh007 on 21 Nov 2020

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...

ericleigh007 on 21 Nov 2020

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.

ackh on 29 Nov 2020

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.

sylveon on 29 Nov 2020

@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 on 30 Nov 2020

@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.

ackh on 30 Nov 2020

Microsoft-ui-xaml: WinUI 3.0 Developer Experience and Tooling - Input Needed

WinUI 3.0 Developer Experience and Tooling - Input Needed

Topics Covered

WinUI in Desktop Apps

Templates

Open Question(s)

Language Support

Migration

Open Question(s)

Packaging

Most helpful comment

All 212 comments

Can anybody tell me how to collapse this?

Templates

Migration

Others

WinUI in Desktop Apps

Templates

Language Support

Packaging

Migration

Tooling

Migration

Tooling

Templates

Related issues