WinUI 3.0 Developer Experience and Tooling - Input Needed #1045
Comments
|
Probably a far off thing, but Blend needs to be overhauled and needs a design focused workflow. The XAML designer needs to be robust, and powerful. Some way to visualise the layered structure of the page/window, especially important with elevated controls. Ways to visualise UI elements outside of a page, such as an individual control/template. Display control customisations that are made for CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, all within the designer. Combined designers for XAML mixed with WinForms, WPF, MFC, and all the other Frameworks that WinUI Desktop will work with. Good ways to import and export XAML, so designers can work in Blend isolated from the main app, and then hand them to the development teams to bring into the app. Better visualisation and listing of system resources, as well as great ways to pull out those global resources that can be light styled to override the defaults, and the design surface reflects those changes in real time. Better ways to test for different DPI scaling with apps involving WinForms, MFC etc. Templates for new controls, customised theme resource dictionaries, integrate the Fluent Theme Editor, templates for supported app combinations (Win32 MFC with Xaml UI, etc) . Templates for shell integration points, like file pickers, task tray flyouts. Those are just a few thoughts... |
|
My thoughts are as follows:
If anything else comes up, I'll be sure to post it here. Thanks! |
|
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. |
|
Oh, and another thing. I would really, really appreciate it if something could be done about how vcxproj requires the use of packages.config for NuGet package references. WinUI is distributed as a NuGet package, as is C++/WinRT and other key components. I am really don't like using packages.config. PackageReference is much more efficient (and it doesn't result in a broken build if you move the vcxproj into a different directory). It actually does work when used from a vcxproj, as long as the Restore target is run at the appropriate time. (This is because the vcxproj targets indirectly import the PackageReference restore machinery for non-SDK C# projects.) I have written a set of targets that automatically run the Restore target when the set of PackageReference items has changed, as VS won't do this itself (yet). Unfortunately, the NuGet system knows nothing about this, and as such it attempts to add a packages.config file when I add a C++/WinRT file template. This causes all sorts of havoc, resulting in an exception being thrown and a broken project file. I am not certain how best to resolve this, but I would really appreciate it if it could be at least looked at before WinUI 3 is released. Thanks! |
|
It would be nice, if WinUI support new project sdk - Microsoft.NET.Sdk or MSBuild.Sdk.Extras. |
|
Why no F# support? |
|
Should Azure DevOps and Visual Studio App Center functionality be discussed here? |
|
Like @vitorgrs , I prefer native controls without namespace prefix, it add "noise" to the code. And it helps to see which are native controls, and which are 3rd party. A migration tool would be nice, of course. If it works with the big 3rd party providers (Telerik, DevExpress,...) that would already be a big thing. |
Templates
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
To me this looks great for UWP. Now I want to see the same for Win32. :)
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
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.
Usually Telerik DataGrid and Community Toolkit
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. OthersLike mentioned already in other comments, I think it's time to switch to SDK-style .csproj files. |
|
add winui 3.0 templates to windows template studio. |
WinUI in Desktop Apps
As a .net developer, this is the part I am most interested in. Templates
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.
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.
Yes Language Support
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
Compare the differences between clickonce and msix deployment:
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.
Performances, performances, performances, and support for large solutions with a lot of projects. |
|
Will the WinUI version of the Windows 10 SDK and the WinUI Xaml designer, be made open source? Will we be able to post requests for the design time workflow, and experience? Will the SDK follow a similar release cadence as WinUI's nuget releases? |
|
Some additional pain: |
|
We rely heavily on ClickOnce, so it would be nice to support for the short term. We would be willing to migrate to MSIX, but after similar features are offered. As for templates, it would be nice to have one that provides boilerplate UI and code for a NavigationView and navigation. Thx |
The most common App "shell" structure and patterns - should be available as templates so developers can get up and running quickly. Microsoft's first party apps should be exemplars in these layouts and act as best practice in terms of behaviour, consistency, and adhearing the UI design norms for Fluent Design, and WinUI. |
|
@shaggygi @mdtauk
|
|
@Felix-Dev will there eventually be WPF templates in addition to UWP? |
|
@shaggygi There might be some good news for you! See this thread: While seemingly nothing is guaranteed at this point the idea of providing templates specifically for WPF projects is apparently being explored. As noted in the linked thread, there was a non-public sneak peek session called "Windows Template Studio - WPF Edition" hosted at Build 2019. |
|
We’re using C++/WinRT. We don’t use the xaml designer or binding at the moment. But we will be creating controls at runtime and styling them possibly via UWP xaml. We will also need dialogs and modeless child Windows with xaml islands including docking/floating windows etc. |
|
I've tried writing XAML for my C++ app and boy was the experience painful. I've had to add many project properties which are undocumented and some other hacks to correctly generate everything and package it correctly. For example:
Additionally, C++/WinRT was also being a pain in the ass:
Even then, it still doesn't works unpackaged even when adding |
MigrationAutomation 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. ToolingAs 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 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 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. |
I would like to think that the WinUI 3.0 version of the Page control would do away with the need to use a prefix for those controls. I guess this would be an SDK level thing. |
|
Is it possible to not to change the namespaces when using WinUI? One fix should be, that you can exclude Is this the way, then there's no need to change namepaces, since it behaves like a .NET 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 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:
|
|
I wouldn't think it were necessary to provide a porting tool. It's a one time change, reasonably easy with Find&Replace, and the number of instances are going to be fairly low. |
|
Also encountered more issues:
|
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 ,
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! (
Again, you're conflating C++/WinRT and tooling. They're 2 separate things. C++/WinRT is a C++ wrapper around the WinRT APIs. IDL is for code generation, and yeah, I agree it's awful, it's so bad that I don't use it. |
|
I write a Windows only app and I still care about standards compliance since it allows me to use a different compiler in cases where MSVC fails. |
I have been coding for Microsoft platforms since MS-DOS 3.3, added C++ to my toolbox in 1992 with Turbo C++ 1.0, have used most of Borland, and Microsoft products in what concerns C++ development. Don't need any lecture on what C++/WinRT is about. What it definitely isn't, is a match to the C++ Builder and Qt (with Qt Designer) developer experience, that C++/CX showed the promise to eventually catch up with, 25 years later. But apparently most people here just want Visual C++ 6.0 with ATL 3.0, and the rest of us should just stick with .NET 5, WPF and Win32 desktop experience, because we are a minority not worthy of consideration, otherwise C++/WinRT would never have been pushed the way it was. Lets be honest, C++/WinRT is now almost 4 years old, and Microsoft wasn't even able to provide support even for syntax highlighting and intelisense? Something that some of us have crafted in Notepad++ (syntax highlighting), Really? It definitely shows where the priorities are, and it isn't this way that WinUI will gain adoption, too many rewrites since Windows 8. |
|
@pjmlp , again you're talking about the wrong things. C++/WinRT is just C++, so it does have syntax highlighting and it does have intellisense support. Just the same as any other C++ code you have. |
|
IDE integration could be better, like as you mentioned IDL syntax highlighting and stuff like suggesting to create a default implementation in .hpp and .cpp from the IDL (like how currently a function declared without a definition in a header prompts you with green squiggles to create one), but going back to C++/CX is a net downgrade IMO. It would require too much effort to integrate all the libraries and shared code I use with C++/CX, and force me to downgrade my project from C++20 to C++17 (which I don't want to give up, 20 gives me too many good things). C++/WinRT is also much less intrusive than C++/CX when programs just want to consume WinRT classes, not author them. Qt and C++ Builder achieve their experience in mostly standards compliant C++ (note that Qt has something similar to IDL, named Qt MOC). If these can, so can VS. It just requires more love from somebody in DevDiv. |
|
And as you mentioned previously @sylveon , we're free to build with other compilers (we currently build with MSVC and Clang/LLVM). With C++/CX or other MS extensions this would be impossible. |
|
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. |
|
can you edit this to fix the typo 'no catering'.. I think that's supposed to be 'now...'
|
|
@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. |
Out of curiosity, what was the bug reported 18 months ago? Do you have a link to it anywhere? |
|
hi Miguel, 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 |
|
As mentioned in my previous post, the C++17 standard compliance of C++/WinRT in itself is in most cases no incentive to migrate a C++/CX code base to C++/WinRT because you're forced to compile with Microsoft's Visual C++ compiler anyway. If you could switch out the compiler that would change entirely. But Visual Studio does not support switching out the compiler for Windows Runtime components. It is a mystery to me why this is not supported, especially because it is supported for desktop apps as outlined in this blog post. Clang support should really be expanded for Windows Runtime components. We're using Clang to compile our code base for Android and iOS. Being able to use Clang to compile our code base for Windows would actually be a very very good reason for migrating away from C++/CX. The Visual Studio feature request for that already exists but nothing has been done so far by the Visual Studio team. You have C++ standard compliance, you have Clang support in Visual Studio for desktop apps. So, please do the final step and provide a real reason for migrating away from C++/CX by providing Clang support for Windows Runtime components. |
|
The standards compliance is useful for consumers - as you mention producers are stuck to MSVC. There is a way to "force" clang-cl (that's effectively what the LLVM toolset does already) by setting the property Once XAML and C++/WinRT producer tooling is unlocked in desktop projects, it's also going to be less of an issue for me. |
|
@ackh I got an UWP project to build under Clang 11: Here's what I did:
<PropertyGroup>
<CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
</PropertyGroup>
It has a couple pitfalls however:
I would suggest opening an issue on https://github.com/microsoft/ProjectReunion to get attention on this. |
|
@sylveon Thanks a lot for posting these instructions. I'll give this a try at some point but still hope that Visual Studio will support this out of the box at some point. |
|
When evaluating the remarks by posters above, the first thing I do is look at their repo. Is the repo representative of someone that's doing real work? This is what I ask myself. Suggest Microsoft does the same when evaluating the validity of comments given. |
|
Coming from the UWP side of things, all I need is a capability that allows my UWP App to run fully unrestricted with tooling that allows for linking against conventional Win32 libs. I, and the rest of the posters above would be golden if they embraced UWP as it stands today with such a capability. I could develop all manner desktop applications then. So while WinUI spins on becoming real, we can have something that delivers on past promises today since most of the essentials (and then some) are in UWP now. I agree with @pjmlp about the pain points associated with C++/WinRT, however I'm mostly ok with where C++/WinRT has landed conceptually (language extensions that break old code are always bad) with the exception of how the developer experience is integrated as compared to a C# UWP XAML workflow. C++/WinRT UI development is painful and very very unproductive. The mindset of C++ devs is too accepting of poor productivity tooling, I should know I was a late convert to C#. |
|
Lets not gatekeep feedback. |
|
Worth also remembering that GitHub isn't the only VCS provider out there. |
|
And many developers will be using a private repo for their day job. |
|
If you're a serious C# / C++/WinRT / XAML / Microsoft dev, Github is the main event. Not posting on Github is already a partial disqualifier because you're not really contributing the the community in an accessible way. I have private repos in a few places. I post on Github because that's what has the needed visibility with respect to the topic at hand. |
|
Very, very happy to see the ability to create straight-forward desktop applications using WinUI. Sad to hear that it only happened after all these studies and interviews. A few things though.
|
|
Why so much harassment in a dead thread? "I don't care about other platforms so I hope they don't mention platforms I don't care about." Ok, good for you! I don't care about Android Instant Apps but I'm prompted about it on every new Android project. It's the way the world works. "That will teach Microsoft's own people a bit more about.. whatever it is they think they might have been doing really well so far." How are you not overwhelmed with embarrassment before clicking the comment button? |
True. But the project template did not work.. as-is. The error came from that second "package-related" project. So I couldn't run the desktop project above it. Yeah, I can eventually figure it out. But I was very surprised to see an issue at this basic level.
Teaching others by preparing and presenting through video lends insight in a way is what I felt was truly needed here. Yeah, my tone was a bit sarcastic but I am not embarrassed by it. Its also how the world works. Have a good night. |
|
Closing the stale thread. Same discussion is happening elsewhere. |
and others
WinUI 3.0 Developer Experience and Tooling - Input Needed
With the release of WinUI 3.0 we want to create the best developer experience we can. For that, we would love your help and feedback. This discussion topic is a focus on the Development experience and tooling for WinUI 3.0.
Topics Covered
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.
Templates
With WinUI 3.0 we are going to create new application templates for Visual Studio 2019. These templates will contain all required items for WinUI 3.0 added by default. WinUI Nuget package integrated into the references, updated code behind, and one set of controls listed in the tools pane. Today when adding the WinUI Nuget you get two sets of controls accessible form intellisense and the tools pane.
The walk through below outlines the new experience for WinUI 3.0 UWP C# Applications.
Open Question(s)
Language Support
We’ve heard your feedback (Link to discussion thread) and to be explicit here is the list of the languages we are planning to support with WinUI 3.0
We are exploring support of F# based on the direct feedback from the discussion. Thank You!
Migration
Migration (Adopting WinUI 3.0 ) and modernization is something we want to make as easy as possible. But we need your help to tell us how.
To start using WinUI 3.0 developers must…
We want to make this process as simple as possible. We plan to include extensive documentation as well. This however does not cover 3rd party components or custom controls.
Open Question(s)
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
We have several issues not specifically covered here that we will continue to expand on. If you have thoughts, concerns, or comments regarding the developer and tooling experience for WinUI, please don’t hold back. I’ve included a list below to help jump start the discussion.
The text was updated successfully, but these errors were encountered: