Proposal: Minimized UWP apps using the confirmAppClose capability should be activated when the user attempts to close them

Summary

Today, when the user user attempts to close a minimized UWP app via the Windows Shell (Taskbar, Timeline,...) which uses the confirmAppClose app capability, they won't get notified by Windows in any way if additional input is required from them to properly proceed with the close request. Instead, the user will only notice that the app is not being closed, causing confusion to them as to why their close request is not actually closing the app. In fact, if further input is required from the user, they will only notice this once they themself brought the app to the foreground again.

This behavior is described in the docs here and the following GIF illustrates this issue using the UWP App Quick Pad (Github repository here) which is a modern text editor alternative to the classic Notepad:

Rationale

Win32 apps like Notepad show a dialog upon closing the app if additional user input is required:

While this example implementation is an improvement over the current situation for UWP apps it is still not perfect! For example, some time might have passed since the user last edited the file/data and thus they don't remember any longer if the data in question is something they need to save or not. As such, it would be quite helpful to the user if the entire app window is activated so they can quickly check the data referred to and can then decide if they want to save their edits or not. In other words, if the user attempts to close an UWP app like Quick Pad via the Windows Shell as shown in our example above, they would be greeted with the following screen in return if additional user input is required:

Closing the app via the Windows Shell is a deliberate action done by the user and as such should allow the app to be activated as a response if further user input is needed to proceed with the close request.

Scope

Additional Context

@BenJKuhn Feedback Hub entry here.

Proposal: Bindings for DirectX.

Since the introduction of WinRT, later UWP, non C++ developers have suffered from lack of access to DirectX, even though they could be easily improved as Windows Runtime Components, given that they are already based on COM.

Summary

Provide the necessary metadata for Rust, C#, and JavaScript developers also to be able to integrate DirectX as Windows Runtime Components into their applications without being forced to write C++ code.

Rationale

Since XNA was put to sleep, we have been managing with community projects like Monogame, SharpDX, Vertice and many others.

They usually tend to run out of steam or fail to keep in sync why the latest DirectX improvements.

So anyone that wants to bind DirectX into their applications is eventually forced to either deal with the faults of such implementations, or having to learn C++ alongside its variants, initially C++/CX, nowadays C++/WinRT and try as much as possible to create an interoperability layer for their application.

Other DirectX related technologies like XAudio and DirectML already offer Windows Runtime Components,

There is also the Win2D project that seems to have become stale, eventually because it wasn't part of DirectX team efforts to start with.

So by having official Windows Runtime Components as part of the official APIs for DirectX, we would be assured to have up to date bindings, integrated into Visual Studio tooling, available to all Project Reunion official languages, instead of being only available to C++ developers.

Scope

Important Notes

• SharpDX (now discontinued)

Open Questions

Proposal: High priority for good error checking/error messages right from the start

Summary

Error checking and good error messages should not be treated as "polishing" that can come later. When using an API, silent crashes or naked HRESULTs should be the exception (no pun intended).

Rationale

Learning a new technology is not always easy. Learning a "new new" technology can be challenging. If silent crashes happen or all you get is a cryptic HRESULT, you never quite know whether you made a mistake or the technology has a bug. Good error checking and error messages in that technology are important for leading developers on the right path. If finding mistakes is too difficult, this even may drive people away from the technology.

Two examples from my own experience:

1. Coming from WPF, writing UWP apps felt like a step backward. One little mistake in the XAML could lead to a crash that kept me wondering what happened. Trying to figure out the reason by walking back the changes took so much time that I stopped the whole project and switched to WPF on .NET Core.
2. It's been a long time, so my memory may not be exact, but back in the Silverlight days, one important productivity boost from Silverlight 2 and 3 to maybe 4, but especially version 5 was that the error messages got so much better. In SL2 and SL3 all you got was an HRESULT.

Scope

Important Notes

Open Questions

Proposal: Hot restart

Summary

Hot reload is a feature that's been out there for a while and helps get an immediate visual of the XAML in the opened editor, but that doesn't take into account lower-level functionality.

Hot restart takes it a step further and has your app re-rendered whenever its underlying C# has changed too.

In some technologies out there this feature has been there since day #1 and is extremely useful. Would be very nice to have this in UWP.

Discussion: Use Github Projects for the roadmap

I'd suggest using Github Projects for the roadmap. It should be a perfect fit to communicate plans and progress.

Related Links

https://github.com/microsoft/ProjectReunion/projects

For people coming here who have no experience with Project Reunion, many of the threads may contain too much jargon to be very useful. Don't get me wrong - jargon has its place, as a compact way of expressing commonly-understood terms and concepts, but the key point here is "commonly-understood". In a quick scan through some initial threads, I saw many terms I didn't recognize; some I was able work out, some I found via old man google, but others are less clear: as an example, the use of the word "projection" as it appears here is unfamiliar to me, and I'm not sure that the meaning I've assigned to it is correct.

Normally, I would expect to find things that I, as a new arrival, might not understand in the FAQ, but to be honest, the FAQ is currently very, um, "sparse", and itself rather thick with unfamiliar terms. My request would be that someone put together a basic glossary of terminology and link it from the FAQ. This would certainly help me, and I'm sure would help other new arrivals as well - people who might otherwise be put off and leave.

I'd be happy to be a newbie guinea-pig and compile a short list of terms that could be usefully clarified if someone asks me to.

Proposal: Common Startup Task Support

Summary

Packaged applications have a specific StartupTask type that lets them manage tasks that run when the user logs on. Provide a type that gives the same startup task functionality across all kinds of applications, ideally modelled after the StartupTask type.

Rationale

There are many different documented ways to create and configure startup tasks for Win32 unpackaged applications. Packaged apps (UWP, Desktop Bridge) use the common StartupTask type. This disparity makes it hard to transition from Win32 to UWP or back. Windows should have a single strongly-documented API surface that lets apps create tasks that launch them at startup.

Scope

Important Notes

Use of this API will not require a Win32 app get packaged, but the app might need to carry an artifact declaring the startup tasks in a way similar to how packaged applications declare them.

Open Questions

Should a Win32 app running elevated be allowed to enable their startup task for all users, or only the current user?

Should the API enable the complicated "run elevated at startup" task described in MSDN?

Proposal: CoreApp Everywhere

Summary

Provide a variant of CoreApplication that gives Win32 apps the same common events as UWPs. Expose a set of common app/user/session lifecycle events for all kinds of apps to use under a single API surface.

Rationale

While UWP has a rich app-lifecycle model for applications under system control, Win32 has historically made it hard to detect and react to app/user/system/session power and lifecycle events. There should be a single type that collects & generates events for the lifecycle of an app. As Windows' power management functionality improves having a single type collecting these events is critical.

• Setting up Win32 notifications for user lock & unlock is challenging
• Notifications for query-end-session and end-session are hard to implement
• Power state transitions let apps reduce their footprint on the system when the user goes on battery
• Detecting whether a session is locked right now is complex
• UWP provides platform support for app single-instancing, Win32 does not (easily)
• Integration with restart manager means apps restore after both app & OS update

Scope

Important Notes

The existing CoreApplication type mixes together basic app functionality like lifecycle and window generation. Reunion's CoreApp should expose only app lifecycle events. UWP activation paths like OnActivated should be moved to another object that's clearly about UWP activation and windowing behavior.

We, the Windows Developer Platform team, are glad you could join us at Build 2020! We enjoyed engaging with you and learning from you. In case you missed it, here’s Kevin Gallo presenting the Project Reunion effort. We appreciate the feedback you've provided about this effort and we want you to know that we are listening, and we’ll continue to engage with you.

As next steps:

1. We will continue reading and responding to your questions and ideas.
2. We will be posting a summary of questions you have asked both at Build 2020 and here on the repo to the FAQ for reference.
3. We will pull in Project-Reunion-specific feedback that you’ve provided in other repos e.g. the WinUI repo, into this repo so we can deliberate on it here.
4. We are currently working on design documents to share and get feedback on for CoreApp/lifecycle (#9) and startup tasks (#10). Please leave feedback on those issues if you have any thoughts!

Keep the discussions going and the feature proposals coming in. Our team is working to respond to all your ideas, questions, and concerns.

We are glad that you could join us on this journey towards unifying the Windows app platform. Over time, we will share more on the roadmap, provide more details about our design and implementation processes, and host more Project Reunion component code so that you can contribute to it.

Stay tuned.

Apparently the long term roadmap will be to merge Win32 and UWP worlds into a common development experience.

Given the newly introduced C#/WinRT and the ONE .NET effort announced at BUILD, where does it leave .NET Native in a Project Reunion world?

If you look at the examples for WebView2, they are all terrible C++ using old COM APIs.
If they were projected as WinRT APIs, we could use C++/WinRT or (eventually) Rust/WinRT to consume them.

I'm very interested to see how WinUI 3 is used with C++/Win32, but currently in order to see the actual code I have to install a preview version of Visual Studio 2019.

Can you put the code of the template apps in this repo? Installing and uninstalling a Visual Studio can potentially break my development environment completely, it is a bit too pricy to have a peek of the code.

The WinUI team have had to drop support for HostBackdrop Acrylic due to it being tied up with the OS code.

So does Project Reunion allow for this Acrylic code to get updated in time for WinUI 3.0 release at the end of the year?

What are the requirements to be part of the "Reunion Family" or get a "Reunion Ready" badge?

What tooling or testing can I use against my component to know that I'm following Project Reunion best practices?

Is there a badge or testbed I can get in my project to indicate that my component meets the requirements?

Proposal: [UWP] Provide a user-friendly UX to request access permissions to specific file locations

Summary

Allow UWP apps to request specific file/folder access by displaying a user-consent dialog (system prompt) instead of having to display a File/FolderPicker UI or require the restricted BFSA capability.

@benstevens48 has described this in their long post (Scenarios 5-8) in issue #8 and to my understanding this is also listed as a 'Could' in the issue scope. I believe this particular file-system access painpoint of the UWP sandbox implementation deserves its own proposal instead of being just one of many suggestions put together in a massive thread. It is also not related to the core idea of issue #8 which seems to focus more on the actual UWP File APIs themselves (see 'Must' vs 'Should' vs 'Could' scope) and as such should be treated as its own actionable issue.

Rationale

Currently, if my UWP app needs access to specific files or folders of the user, I can either use the BFSA system capability or display a File/FolderPicker UI. Both cases come with severe drawbacks for the scenario where an app wants to access a select few file system locations already known in advance.

• BFSA: Asking for access to all the files and folders of a user when in reality only a handful of file system locations need to be accessed will be seriously disliked by potential users, up to a point where a user might outright stop using the app.
• File/FolderPicker UI: Using the *Picker UI, I can ask for selective file system access. However, I can
  a) not ask for access to multiple distinctly-located folders all at once and
  b) the user will have to navigate to the actual file/folder location
  There are ways to aid the user in navigating to a location without having to manually walk the entire folder tree, however, this is only mitigating this bad UX. And if my app needs access to distinctly located files & folders, I will have to show multiple *Picker UIs (one UI for each location) if I want to create an app experience which values the user privacy greatly and only obtains access to the minimum required file system locations for it to work.

To improve the process for UWP apps to get access to select file\folder locations, I thus suggest using the well-known user-consent dialog. For example, if the app tries to access a folder it currently does not have access to, the system will show the user-consent dialog asking the user if they want to give the app access to this folder. If the user consents, the app from now on will have access (until the user revokes their consent or the app is uninstalled). If the user denies the request, it won't (and the app could ask again if needed). Visually, this could look like this:

(In this case, the app asks for access to the folder where Windows Spotlight Images are saved by Windows.)

In the example image above, access is only requested to a single folder, yet we can easily imagine apps asking for access to multiple distinctly located files/folders. It should be possible for apps to also request access to specific files/folders in "bulk", in other words, the user-consent dialog will display a list of file system locations the app wants to access.

Scope

Open Questions

Assuming the user granted an app access to a specific file location: How can the user revoke this permission (without having to uninstall the app)? The Windows Settings app will presumably be the relevant system component to manage these permissions. The Windows 10 Security app could be useful to look at for inspiration: See "Controlled Folder Access" and "Exclusions" in the category "Virus & threat protection".

There is also the concept of granting access "just for this session". What this would mean here is that after closing the app, granted file system access "just for this session" will be removed for the app. In other words, when the app is launched the next time, it will have to ask for access permission to those file system locations in question again.
Is there added user (security) value by providing such an option where the user won't have to actively remove access to a specific file system location for the app?

Additional Context

Original WinUI issue by me here. View this proposal here as the most up-to-date one.

Proposal: Improved file-access APIs for UWP and AppContainer

Summary

Provide an updated version of StorageFile that fixes performance and usability issues in the current Windows.Storage.Storage* set of types. Support apps that think in terms of file paths & handles instead of StorageFile objects.

Rationale

The current Windows.Storage.Storage* types are designed to give programmatic access to regular files, shell namespace items, and other Windows entities backed by files. A single abstraction over all those spaces is interesting but comes with high costs - namely performance and impedence-mismatch with existing application code. Project Reunion should clearly explain why StorageFile is important and - where possible - provide lower-level access to the user's files.

• The BroadFileAccess capability is "scary" to customers but required even for limited UWP scenarios.
• Many libraries and helpers take file paths instead of objects (even instead of handles)
• Apps observe serious performance costs related to using StorageFile's built in functionality
• Low-level code can access the ...FromApp API variants, but higher-level code (JS, C#) interop for them is very limited.

Scope

Open Questions

Should UWPs be given access to the IShell* family of APIs?

As these APIs are not truly universal on all editions of Windows, if an app were to program against them directly the app would not work on editions like HoloLens or Xbox.

Should Reunion warn the user about apps using this capability?

Some platforms periodically remind users that "App X is using feature Y, are you OK with that?" How should Reunion make the user aware that a "low rights" application is using capabilities?

Question: Where does .NET 5 fit?

UWP has been on life support for a few years, with developers admitting that .NET Native, the UWP compiler, is on life support and will not get substantial feature upgrades. Meanwhile, .NET Core 3.1 and .NET 5 are the stated future of .NET.

While not every UWP app is a .NET app, many are. I'd like to start using .NET Core 3.1 features in apps that can run on Xbox, Windows, and Windows 10X.

I've recently read about the 2004 Hosted App release. Will expanded Win32 API access allow for a UWP .NET Core 3.1? And will Microsoft ship a host package for .NET Core 3.1 / 5 / 6, or would I be expected to ship the host package separately? If Microsoft ships it, what will the dependency management story be for version dependencies?

As .NET developer that occasionally has to deal with C++ due to C++ only APIs not exposed to WinRT, like DirectX, the C++/CX tooling was kind of alright.

While not at same level as .NET Native, C++/CX was quite close.

With the replacement via C++/WinRT, I felt that we have moved backwards to the ATL days, old style COM with lots of manual boilerplate.

UWP with C++/CX was the proof that if Microsoft is willing to put the effort, having C++ Frameworks at the same developer friendliness like Qt/QtCreator and VCL/C++ Builder was possible within Microsoft own SDKs.

C++/WinRT feels backwards to this goal, and the multiple times I have referred this productivity lost, due to manually editing IDL files without tooling support, hunting for header files, outdate samples only with the C++/CX way, being forced to do Visual Studio work by copying generated files around just feels the C++/WinRT has definitly moved into the wrong direction.

Usually the answer to these remarks tends to be that those of us not happy with this situation should just put up with the situation, hope that ISO C++23 or ISO C++26 eventually adopt the language features for static reflection and metaclasses, so that a couple of years later Visual Studio can add back to C++/WinRT the tooling support that C++/CX enjoys today.

From my point of view if you really want to cater to C++ developers to WinUI instead of having them choose cross platform toolkits like Qt and FireMonkey, modern C++ tooling is a must have.

It shouldn't have to be harde than .NET, with lots of manual steps, just because it is C++.

Although this issue is for C++, the same reasoning applies to the upcoming Rust/WinRT.

Proposal: Enable MRT for unpackaged applications

Summary

Provide a version of the MRT resource management & packaging system even for unpackaged applications. While MUI is supported, MRT is more powerful and supported directly by various "visual" tooling, and generates code for direct use by apps.

Rationale

https://docs.microsoft.com/en-us/windows/uwp/app-resources/ is a powerful system for packaged applications to deliver resources (images, XAML, html, xml, or any other data) to enable localization or customized content for form factors. Unpackaged applications would benefit from the same ability to easily use Visual Studio and other tools to build and consume resources. https://docs.microsoft.com/en-us/previous-versions/windows/apps/jj552947(v=win.10) describes the Resource Manager in depth.

Scope

Project Reunion seems like a big step in the right direction! I have a few questions:

• If Project Reunion is trying to merge UWP application with the classic WinAPI programs, will decoupling from the OS make the WinAPI programs loose some of their native functionality?
• Does the entire codebase have to be updated? Example: If I create a button control from comctl32.dll will I have a UWP button control instead? Or will I still have my classic GDI button?
• I'm assuming that the merged UWP functionality will be the APIs that only Windows desktop supports?

I hope someone understands my questions, and I'm eager to use Project Reunion when the time comes.

UWP's AppWindow V1 is still in preview after it was added to the 18362 SDK.

AppWindow V2, which was introduced at Build 2018 two years ago, has been missing ever since. The presenter in question, @rkarman, even said MS wants to enable these new windowing app scenarios "as soon as possible" yet here we are, two entire years later, and we hardly know anything new at all.

Recently, some new AppWindow APIs were spotted in Insider Preview SDKs (19569) but they got removed again. Will those APIs be added back? When will they be added back? When will they actually make it into a production-ready SDK?

AppWindow V1/V2 is a critical component for the UWP development story. Yet we are hearing nothing about it. We were told by @clarkezone that we might get to hear more about AppWindow in "the Build timeframe" but I'm not keeping my hopes up here as I don't find anything related to UWP windowing going on at Build.

Yes, there is a new Window class spec opened in WinUI but it doesn't yet cover any of the areas originally envisioned at that Build 2018 conference. And to my understanding, that new WinUI 3 Window class is just a wapper around either a CoreWindow on UWP or an HWND for Win32, As such, I believe all these UWP Windowing improvements talked about have to happen in a different component of the platform. And indeed, at Build 2019 with the introduction of WinUI 3, AppWindow was briefly mentioned to be one of the post WinUI 3.0 goals.

Still, even with that "update" on AppWindow at Build last year, we really don't know much at all about the future windowing capabilities of the UWP. A detailed windowing roadmap for UWP is deperately needed. We also need to know when and where we can actually engage with the platform teams to drive forward UWP windowing. At least for now the actual team(s) at MS owning the AppWindow/UWP windowing seem to be out of reach for us, the passionate UWP community.

Proposal: Client side authentication manager

Summary

ASP.NET Identity is a magnificent tool to manage identity and authentication in the server side, including integration with EF Core, and is mature enough.

It would be complete, if there would be a client side framework, that knows how to interact with an Identity-enabled server that offers features like:

• User authentication management, via JWT tokens, claims etc.- Integration with Thread.CurrentPrincipal.
• Integration with IHttpClientFactory, to allow generating authentication-clients.
• Module authorization (e.g. add [Authorize(Roles = RoleNames.Admin)] attribute on a ViewModel to only enable it for admins, etc.
• Have some way to get notified when a user has been logged in / out.
• User management API that can easily interact with an ASP.NET Identity server out the box.
• A way of abstraction from UI, so that it can be all handled from the ViewModel.

Rationale

Based on my understanding, Reunion is the largest .NET client-side project, and as such, although not directly a WinUI feature request, is a client-specific feature request in the .NET.

Cross posted from here.

Proposal: Specifying as default file handler with content type instead of filetype

Summary

Already asked in microsoft/microsoft-ui-xaml#2456 due to no proper channel to ask. Right now uwp devs have to extensively declare filetypes in manifest if they want their app to be default handler of that filetype. Instead content type should be declared in the manifest and app can be default handler of all files that have the declared content type.

Rationale

Declaring all filetypes is really taxing and in some cases like for a text editor app impossible to do. Instead declaring content type makes it easier for devs. Also in case of win32 apps, user can simply provide executable path to open the file with their app of choice but in case of uwp users can't choose it to default handler of unsupported filetypes. Current filetype association can be kept for silent take over as default handler also giving special icons to some filetypes.

• Enable broad range of filetype support without much difficulty.
• StorageFile methods like renaming file fails if trying to rename the file to a unsupported filetype as described in here.
• StorageFile.GetFileAsync() fails for unsupported file types. This is useful to users as this enables them to open files from command line or WSL environments with uwp app.
• Also, Launcher.LaunchFileAsync() fails if the filetype is undeclared which I observed when I tried to implement desktop extension in 0x7c13/Notepads#534 to enable users to launch custom filetype with this app.

Scope

Open Questions

Should user be able set app as default handler of any kind of file like they can do so with win32?

Proposal: Allow the App to Print without showing the Confirmation Dialog to user

Summary

We should be able to programatically list printers, select the printer, configure paper size, orientation, settings... and PRINT without user interaction.

Rationale

I was trying to make a Touch Screen Kiosk Receipt Print application on UWP, but the samples show

await Windows.Graphics.Printing.PrintManager.ShowPrintUIAsync();
This brings the UWP Print Dialog.

I need to print directly without this dialog. How to do this?

I need something like

await Windows.Graphics.Printing.PrintManager.PrintAsync();
We should be able to programatically list printers, select the printer, configure paper size, orientation, settings...

This will enable:

• Enable easy printing from Voice / Touch applications
• Make the printing API more complete, like the WPF Printing API was.
• This Permission will be very useful for ATM Applications, Touch Screen Kiosk Apps, Barcode Printing Software, Point of Sale applications, Line-of-Business Applications, etc;

Scope

Important Notes

This may require the creation of a new permission/capability for UWP AppModel:
AllowPrintingWithoutUserIteraction

Open Questions

Discussion: Unifying app delivery methods: Store vs other

I don't know if this is in scope, but I hope so. This issue is to discuss how the Windows Dev Center and Store can be improved to offer functionality you could get by delivery your app by another means, and, conversely, how people delivering their app via other means could still make use of some of the features of the Store. Hopefully some of this disussion can result in features that are implemented in the Windows Dev Center, Microsoft Store and related SDKs.

To start the discussion, I'm copying in an issue which I originally posted to the WinUI repository for lack of a better place to post it (microsoft/microsoft-ui-xaml#2300). It suggests some possible solutions that Microsoft could implement in order for apps delivered via the Store to offer different versions, such as LTS and beta. Some of the suggestions are more widely applicable in terms of allowing the developer to distribute the same app both via the Store and outside the Store, when that app contains add-on purchases.

This project is basically reunion of UWP and WPF => One best option for creating windows apps with capabilities from both technologies. And now, we have another way of making Windows app. MAUI.

How does it fit together, will be future maui app also under reunion. Will be every reunion app "compatible" with maui app?

Proposal: Improve register-app-for-start-at-log-in Experience (UWP App Model)

Summary

Using the StartupTask API app developers can register their app to automatically start at log-in. The API is available for both UWP apps and DesktopBridge apps (MSIX-packaged Win32 apps). Depending on the "app model" this API has a different User Experience and I want to highlight one major difference in this proposal.

The linked documentation above states the following:

UWP apps must call RequestEnableAsync from a UI thread to trigger a user-consent dialog. If the user consents, the UWP app will then start on startup or user log in. Note that UWP startup apps will start minimized.

If RequestEnableAsync is called from a packaged desktop app, no user-consent dialog is shown.

It is this user-consent dialog which is at the heart of this proposal.

If the user has granted an UWP app start at log-in permission in the Windows Settings app, every subsequent API pair call of StartupTask.Disable() and permission-granting StartupTask.RequestEnableAsync() will trigger this user-consent dialog (*1). You can observe this behavior in the following GIF below. In this GIF the app initially has its start at log-in permission granted in the Settings app.

(*1) (If the user has denied the app this permission in the Settings app or denies the request using the user-consent dialog, the next call to StartupTask.RequestEnableAsync() will fail and show no such dialog.)

Now observe how the API behaves when calling it from a DesktopBridge app given the documentation above. Again, the app already was granted start at log-in behavior by the user in the Settings app (or the Task Manager):

As stated in the documentation, as long the app start at log-in has been disabled with a StartupTask.Disable() call, a subsequent call to StartupTask.RequestEnableAsync() will enable app start at log-in without asking for user consent again.

This does not feature the, what I consider, bad UX of UWP apps where a user is asked twice if they really want to enable automatic app start. (First ask is the user clicking the ToggleSwitch button, second ask is the user-consent dialog prompt.) The UX here should be fast and straight-forward and should not require by default to have the user confirm their choice whenever they want to enable start-at-log-in for the app in question.

Proposal: UWP apps should feature the same straight-forward register-app-for-start-at-log-in experience as DesktopBridge apps come with as shown in the GIF above.

It is important to note that this proposal will not result in the user losing control over their apps! As long as the user denies the app start at log-in permission in the Settings app, a call to StartupTask.RequestEnableAsync() will not succeed:

As this GIF shows, if the user denied the app permission in Windows Settings at the time of the request, the app cannot programmatically set itself as a startup app.

For each UWP app, the system default is that the user has not granted the app permission to start at log-in. As such, even without the user actively denying the app permission, the app's very first call to StartupTask.RequestEnableAsync() since installation will also fail. It will, of course, require the user to first actively grant the app this permission in the Settings app.

No malicious app can use the absence of the user-consent dialog as outlined in this proposal to just do as it pleases. The user still rules!

Scope

(*2) Or denied the request using the user-consent dialog prompt.

Additional Context

@BenJKuhn Feedback Hub entry here.

Attached Files

I created a sample project showcasing the current behavior for both UWP and DesktopBridge apps. Please check that out if you still have questions regarding the different behavior:
StartupSandboxDemo.zip

I am trying to make a Print application on UWP, but the samples show
await Windows.Graphics.Printing.PrintManager.ShowPrintUIAsync();
This brings the UWP Print Dialog.

I need to print directly without this dialog.
I need something like
await Windows.Graphics.Printing.PrintManager.PrintAsync();

Describe the bug
Not sure this is a bug or just me doing something wrong, could not find documentation regarding this, but I get the following app crash when using a Configuration name different from Debug or Release:

Faulting application name: App1.exe, version: 1.0.0.0, time stamp: 0x5bb69bfe
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.17763.404, time stamp: 0x5c3c199a
Exception code: 0xc000027b
Fault offset: 0x008dc0f1
Faulting process id: 0x28bc
Faulting application start time: 0x01d4ff7fbe41260f
Faulting application path: C:\xxxxx\WinUIConfig\App1\bin\x86\Debug1\AppX\App1.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: d999fdc1-4bb6-46d0-9e39-8aaf0168a949
Faulting package full name: 797cbdfa-8cfb-4c0f-9e19-79943324e67e_1.0.0.0_x86__wgcfbsqfkre0m
Faulting package-relative application ID: App

Steps to reproduce the bug
Open attached project WinUIConfig.zip and try to run the app using configuration Debug1
and platform x86. Debug1 is the same Debug default configuration with a different name. The app should crash almost immediately.

Here is debug output from when the app crashes:

Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: EETypeLoadException at memory location 0x06C7D19C.
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'.
'App1.exe' (Win32): Unloaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'.
'App1.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown: 'System.TypeLoadException' in App1.exe
Exception thrown at 0x75E8C6F2 (KernelBase.dll) in App1.exe: WinRT originate error - 0x80131522 : 'System.TypeLoadException: Could not find Windows Runtime type 'Microsoft.UI.Xaml.Controls.XamlControlsResources'.
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.InitTypeTables()
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.LookupTypeIndexByName(String typeName)
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.GetXamlTypeByName(String typeName)
at App1.App1_XamlTypeInfo.XamlMetaDataProvider.GetXamlType(String fullName)
at App1.App.GetXamlType(String fullName)'.
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\userenv.dll'. Cannot find or open the PDB file.
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\profext.dll'. Cannot find or open the PDB file.
'App1.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\profext.dll'
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\profext.dll'. Cannot find or open the PDB file.
Exception thrown at 0x75E8C6F2 (KernelBase.dll) in App1.exe: WinRT originate error - 0x802B000A : 'Cannot deserialize XBF metadata type list as 'XamlControlsResources' was not found in namespace 'Microsoft.UI.Xaml.Controls'. [Line: 0 Position: 0]'.
Windows.UI.Xaml.dll!046F1727: (caller: 0438AD7D) Exception(1) tid(3470) 80004005 Unspecified error
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: wil::ResultException at memory location 0x06C7DEB0.
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Windows.UI.Xaml.dll!046F243C: (caller: 0451975E) ReturnHr(1) tid(3470) 80004005 Unspecified error
Msg:[Windows.UI.Xaml.dll!046F1727: (caller: 0438AD7D) Exception(1) tid(3470) 80004005 Unspecified error
]
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'.
'App1.exe' (Win32): Unloaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'.
'App1.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

App runs fine if using configuration Debug.

Expected behavior
App does not crash.

Version Info
NuGet package version: Microsoft.UI.Xaml 2.1.190405004.2

Additional Context
Not sure it matters, but I noticed the generated file XamlTypeInfo.g.cs is much larger when using Debug1 (38KB) than when using Debug (6KB) .

Proposal: Add per-machine storage to MSIX

Summary

Even after several years, MSIX still has some significant limitations when compared to Win32 installation technologies such as MSI.

Rationale

• As a developer of a Desktop Bridge app, I cannot store licensing data in a common location that is not also easily erased. I can't store this in the app's private Registry, as then (a) it's per-user only, so I (or the admin if in an organization) have to enter the licensing information for every user that uses the app. Also, if the user resets the app in Settings (perhaps because it's malfunctioning), the license information will be erased as well, causing confusion and annoyance (and probably a call to the help desk so IT can reenter it).

Note: For purposes of brevity, I will refer to this per-machine storage feature as PMLS.

Scope

Implementation Notes

• I can accomplish this today by (ab)using customInstallActions to install a small support program that runs outside the MSIX container (so it can modify the shared HKLM hive), and the app then funnels all PMLS write operations through it.
• This feature may be best implemented as an extension to the MSIX manifest format, which will not function correctly on downlevel version of Windows. We may need to do something to my workaround above backport this functionality to older versions of Windows.

Open Questions

• Should I provide a way for an elevated app to write to another package’s PMLS? This would be useful to installation or automation tools to write licensing data in an automated process, without needing to launch the app and manipulate its UI. Note that I could accomplish this today by using a console EXE in the AppX package that accepts a license key, and then using the existing support for putting packaged EXEs in the PATH to make it available.

There's no real information on what Project Reunion is, other than a label affixed to existing projects such as WinUI and WebView2, and a bunch of confusing information about what the team thinks UWP is/was. The repository needs a clear purpose, clear documentation, and clear goals.

Summary

Windows 10 native toast notification settings can be changed by the user in the Windows Settings app (i.e. which app is allowed to send notifications). Apps cannot programmatically change this setting. There are still cases though where an app is interested in tracking the current state of notification permissions granted by the user to this app. Currently, the Windows Runtime only provides a ToastNotifier.Setting API which the app needs to actively poll to notice permission changes.

I believe we can do a lot better than this! This proposal will proceed to make the case for introducing an event which apps can register to in order to get notified when notification permissions for the app are changed.

Rationale

In the following, I'll list two example app cases which would benefit from such an event API.

Case 1:
The app in question is an app with a strong focus on user notifications. As such the app developer wants to show the user in the app UI whether notifications for this app are currently enabled or not. The user should not have to open the Windows Settings app just to retrieve this information.

As we can see in the image above the app shows the current status of the notification setting for the app in a status bar at the bottom (and a link to the Settings app to change this setting). Obviously, this information has to be updated whenever the notification permission is changed by the user.

Case 2:
This time, we have an app which provides several types of notifications to the user. The user can opt-in to or out of each type of notification:

Consequently, when the user has denied the app the permission to send notifications, each in-app notification setting should be disabled:

(In this case, the app probably should also inform the user that they first have to grant this app notification permission in Windows itself before they can change the in-app settings.)

As in case 1, the in-app notification settings UI should reflect the current permission state "live". In other words, if the user changes the setting in Windows, the new permission state should be reflected in the UI as soon as possible.

Both apps would benefit a lot if the Windows Runtime would provide an event the apps can listen to in order to get notified whenever they are impacted by a notification permission change. More precisely, the event will be raised when:

• the system-wide notification setting is changed while the specific app notification setting is enabled (if it is disabled, changing the system-wide notification setting won't enable/disable notifications for the app)
• the notification setting for the app listening to the event is changed

API draft

My idea is to add a NotificationSettingChanged event to the ToastNotifier class as it already contains the ToastNotifier.Setting property. The event arguments will be based on the return value of this property which is a NotificationSetting.

/// <summary>Occurs when the notification setting for this app has changed.</summary>
public event TypedEventHandler<ToastNotifier, NotificationSettingChangedEventArgs> NotificationSettingChanged;

The NotificationSettingChangedEventArgs class:

/// <summary>
/// Provides data for the <see cref="ToastNotifier.NotificationSettingChanged"/> event.
/// </summary>
public class NotificationSettingChangedEventArgs : EventArgs
{
    /// <summary>
    /// Create a new instance of the <see cref="NotificationSettingChangedEventArgs"/> class.
    /// </summary>
    /// <param name="setting">The notification setting for this instance.</param>
    public NotificationSettingChangedEventArgs(NotificationSetting setting)
    {
        this.Setting = setting;
    }

    /// <summary>Get the new notification setting.</summary>
    public NotificationSetting Setting { get; }
}

Given this API, no longer do apps have to actively poll the ToastNotifier.Setting proprty in order to provide "live" updates based on the changed settings. Instead, all they have to do is listen to this event. I strongly believe this is a much improved API surface and as a result makes interacting with Windows Settings and thus the UWP app model very easy for developers.

Scope

Open Questions

Currently none.

The title is self-explanatory... you bought me and I want in, how do I now convert my existing, really-old, .net-4.7 winforms app to Reunion?

Some Win32API calls may require extensive use of resources and proper pointer management, I wonder how Project Reunion will handle these cases when Win32 APIs are needed and how these libraries will be optimized to comply with effective resource management that UWP life cycle offers.

Describe the bug
The WinUI 3.0 templates have a number of opportunities for improvement.

• AssemblyInfo.cs (in all 3 project templates) contains 3 counts of trailing white-space. Remove these are they're unnecessary and things like StyleCop will report them for formatting issues in default settings. Changing these three instances of the issue at the source will remove the need for, potentially, thousands of developers from having to remove these characters themselves.
• AssemblyInfo.cs (in all 3 project templates) does not end with a NewLine character. Ending files with a single newline character (or CrLf as this is Windows) is a common convention that is followed by all other generated code files in the templates. Not having this can also cause some version control/management tools to flag the fact that the file doesn't end with a blank line as a possible issue. Fixing this here will ensure consistency across the generated files and avoid developers seeing a potentially confusing message about line endings that they really shouldn't need to be bothered by.
• Opportunity to use Pattern Matching in App.xaml.cs (in Blank App template). The OnLaunched method could be updated to use pattern matching to simplify the code. This only removes a line from the code but, more importantly, this is something that Visual Studio suggests as an improvement. This wasn't something that could be done in the older UWP templates because of a need to support older versions of tooling but this isn't an issue for WinUI 3.0. Make use of the newer language features that are now available.
• Inconsistent comment formatting. Primarily in App.xaml.cs but applies more broadly. The inconsistency in the code that is currently generated shows a lack of attention to detail. There are also popular analysis tools that will highlight these issue with their default settings.
• Comments should start with a single space. There are 2 instances in App.xaml.cs where this is not the case.
• Comments should end with a period (full stop.)

Version Info

Templates version 3.0.0.1911010

Additional context
Make these templates public and I'll happily submit PRs for fixes.

Proposal:

UWP/WinRT Libraries should be able to expose .NET interfaces and classes

Summary

It should be possible to create UWP controls which implement .NET Standard interfaces in an UWP control library. Currently it's only possible when the control is moved to the project of the host application. This prevents the reusability of the control.

Rationale

When implementing an UWP control using ReactiveUI, we need to put an IViewFor<TViewModel> interface on the control.

For reusability with non-UWP Apps, the ViewModel might be a class from an .NET Standard project. Also the IViewFor<> Interface is defined in a .NET standard library.

As long as the control is defined in the UWP app project, everything works fine. However, the code does not compile when the control is moved to an external library.

Scope

It shouldn't be required to reimplement .NET Standard libraries as WinRT libraries.

Important Notes

• ReactiveUI

Open Questions

It is unclear to me how to best approach this issue.

Proposal: Expose all UWP titlebar and coretitlebar API to Win32 apps

Summary

The ApplicationViewTitleBar and CoreApplicationViewTitleBar
have amazing features to personalizing the title bar (see title bar customization documentation. We can easily change the colors of the title bar or put a control in the title bar. These features are absent from Win32 (or less affluent) they are also unavailable in WinUI 3 Desktop Desktop.

Rationale

• Allow Win32 apps developers to customise title bar easily.
• Allow consistent title bars and navigation UI between UWP and Win32 especialy for WinUI 3.

Scope

Important Notes

• usage examples
  Extend NavigationView TabView or Pivot into title bar like it's already possible in UWP in WinUI 3 desktop according title bar to the Application color scheme…

• other implementation notes
  I think these API depend on CoreWindow and Win32 windows have Hwind windows that is different and it's may be complicated to merge the capabilites of CoreWindow title bar to Hwind title bar.

I know these are early days for this project, but it may be helpful if there were some kind of guidance as to what asks are beyond the scope or ability for this project.

One example has been with WinUI. There were certain asks around Windowing APIs and Models, which were OS dependant, and not within the control of the WinUI team/project.

If there were no bounds to this project, you could theoretically reduce Windows to a backend kernel and driver model - and everything from Shell to Apps being moved to this repo and open-sourced.

Proposal: RadialController injection input

Summary

There is a preview API to inject HID input. Currently the input types are restricted to

• keyboard
• mouse
• gamepad
• pen

It would be great if RadialController (Surface Dial) input could be injected, too. This would enable making non-compatible devices act as RadialController devices via a user-space app instead of writing a driver.

Rationale

• Would enable people to write e.g. emulators for RadialController without having to resort to driver development (which is a barrier)
• For the usecase of emulating a RadialController device with another hardware device, I added background input to the must haves. This is because if you want to build a "bridge" app for a certain hardware device, that app should be supportive to other apps by running in the background. It should not need to be in the foreground to be able to inject RadialController input.
• Windows shows / hides the Wheel page in the Settings app based on whether a Wheel device is connected. To support that functionality, an emulator / bridge app should be able to indicate when the app is connected
• I put the request in this repository since there is no good alternative where feedback feels heard

Scope

Open Questions

If there is a better place to request this, please let me know. I just do not feel that feedback hub entries with API proposals are responded to, they seem to get lost in the stream of other feedback.

Proposal: [uwp] Proposal: Allow bringing application in foreground on drag-and-drop from another app

Summary

There should be a way to bring the application to foreground on drag-and drop - whether programmaticaly or manually.

Rationale

The reason I want this is to handle drag and drop (of files/folders) properly. My app needs to be full screen (since it's got plenty of information to show). When the user drags something, I want to contextually show him where to drop his files.

Right now, this is not possible, because I can't bring the app in foreground

This has been asked time and time again:
https://social.msdn.microsoft.com/Forums/en-US/bf42b98f-1e35-4699-9001-ca3a733f3cb2/uwp-how-to-bring-the-app-to-foreground-on-drop-event?forum=wpdevelop
https://developercommunity.visualstudio.com/idea/560137/bring-the-app-to-foreground-on-drop-event.html
https://stackoverflow.com/questions/42176570/bring-uwp-app-in-foreground

This sandbox-over-micro-management in UWP is starting to get to me. There are valid reasons for allowing an app to bring itself into the foreground. And no, the "CompactOverlay" is not the solution - I have no idea why anyone would ever use that.

Open Questions

There is a huge disconnect between what us - developers - really want, and the things that are in this sandboxed environment.

I really hope, once WinUI 3.0 is complete, someone (or some team) will go over all the sandbox limitations, and simply remove those that don't make sense (like, the Suspend API, for instance).

Mentioning Rust in the README ad seeing no mention to vb, which is still the 6th most used language in the world, is outraging.
Will there be support for vb?

Discussion: Adding support for new features to MSIX manifests

Currently, only Microsoft can add new features to the MSIX manifest schema, through extending the code and data inside AppxPackaging.dll. However, some users have asked for MSIX to be able to install more esoteric payloads, such as MMC snapins or Windows credential providers. Currently, the only way one could try to do this is to use customInstallActions and pack an MSI into the MSIX package. While this would work (assuming App Installer permits installation of apps that declare that rescap, which I am unsure of), IMO it goes against the design of MSIX. Furthermore, waiting for Microsoft to add new features into Windows core goes against the spirit of Project Reunion. 😄

One way new features in MSIX could be implemented in a backwards-compatible way would be to to invent a namespace not natively supported by Windows, and put custom features into that. Then users would add its prefix into IgnorableNamespaces so that Windows doesn’t complain about not recognizing it. Finally, the app would bundle a small component run using customInstallActions that parses the manifest file and processes the elements during the installation process. This small component should be extensible, so that third parties can add support for their specific needs by writing a plugin DLL, instead of having to fork and vendor the entire tool.

I have a good enough grasp of this process to start on a preliminary implementation in my own repo, but I don’t yet have enough detail for a formal Feature Proposal just yet.

Describe the bug
All the icons in the template selectors (project & item) use the same icon, this adds extra cognitive load to distinguish between them making selection slower and more error prone.

I know you like the new icon but this over-use of it is unhelpful in aiding the ability to distinguish between the different options.

Steps to reproduce the bug
Open a New project or new Item dialog

Expected behavior

The icons should be unique to help enable differentiation.

Screenshots

New Project dialog

New Item dialog

Version Info

WinUI 3.0 Alpha (the only public version)

NuGet package version:

Additional context

Discussion: Dark mode for applications

Currently, reliably detecting dark mode in Win32 applications requires either reading the registry or using undocumented methods from uxtheme.dll.

I strongly suggest to document those two existing methods:

• ShouldAppsUseDarkMode:
  • This allows apps to detect whether the dark theme is used for apps.
  • Particularly useful to follow system settings, like Microsoft Edge and UWP-based apps do.
  • Changes to this can be detected by listening for WM_SETTINGCHANGE.
• ShouldSystemUseDarkMode:
  • This allows apps to detect whether the taskbar, start menu and other system shell elements uses the dark theme or not.
  • Particularly useful for determining if a white or black notification area icon should be used. OneDrive already does this.
  • Changes to this can be detected by listening for WM_SETTINGCHANGE.

This will allow existing apps to easily implement dark theme support, and to follow system settings without relying on workarounds. A WinRT API should probably be exposed (the two settings and an event to listen for changes) as well, but some applications are already tentatively using those two APIs, so it would be the best case to document the Win32 APIs, as those won't have to do any significant work to adopt an official solution rather than an undocumented one (and, truth be told, they are much simpler to use than their WinRT counterparts, especially if your language doesn't have a WinRT projection available)

Also, there exists other APIs in uxtheme.dll which might be of interest for people transitioning to WinUI and/or XAML islands:

• SetPreferredAppMode:
  • This allows apps to enable dark theme support for Win32 controls. This is notably used by Windows Explorer for its dark theme.
• AllowDarkModeForWindow:
  • Once the app mode is set to AllowDark using the API above, it is a per-window opt-in.
  • Once this method is called, the Win32 controls in the window uses dark theme if the system dark theme is enabled, and automatically switches to light theme when the user changes their settings.
  • Note that some controls might need to have their theme manually set to DarkMode_Explorer for this to be effective
  • Dark mode ribbon can be opt-in with the window property UI_PKEY_DarkModeRibbon

Those methods are useful because when transitioning, it allows developers to use a dark theme for old controls and new controls alike, to get a somewhat consistent UI. Darkening Win32 or winforms controls manually is extremely hard to get right, and leveraging the work done in Windows Explorer would prevent a lot of misdirected attempts at dark theming Win32 controls.

EVEN MORE, there's an undocumented window attribute allowing dark mode title bars (DWMWA_USE_IMMERSIVE_DARK_MODE). This one was even used by the command prompt itself and openly on GitHub, before it got removed from the OSS version because it was internal (see microsoft/terminal@bc7eb96#diff-e26a93b2aa9fea92ebf24336c4fe6412L19-L22). No true dark mode comes without a dark titlebar, and customizing the titlebar is a complex endeavour that would be greatly simplified by the publication of this attribute.

All of the APIs mentioned have been added since the introduction of dark mode Explorer, and have proven to be stable or only very slightly modified, so I'm sad they are being kept private because it would allow so many apps to get a dark mode (light mode makes me cry 😢)

I know the readme says

Project Reunion will help you update and modernize your existing apps with the latest functionality

but does "existing apps" include MFC ones, or just those using Win32 directly? I'd be very interested in hearing about plans for how to help migration of MFC apps to modern APIs.

"Project Reunion" targets both UWP and Win32 and we are already seeing issues for both app types. As such, for easier grouping and filtering of issues, it could be useful to have labels like "UWP" and "Win32" to clearly indicate which proposal/question is targeting which app type.

I see there are bindings for JavaScript, rust and c++. What about languages that want to support this that aren't officially supported? Are there ways to use the new apis from c(which all languages can work from) or any info on how it fits together internally?