The three main topics that were discussed were UWP Console applications, multi-instance apps and broader file access. You can watch the recording on Channel9 or right here.
If you just want to get a quick peek at the news, read on the rest of the article, because I have prepared a compact summary for you 🙂 .
UWP Console Apps
Console apps support is coming to UWP. With new project templates (for now for C++ only) in Visual Studio, you will be able to quickly create a console application running as a Universal Windows Platform app, with support for UWP APIs and many benefits like automatic updates through Microsoft Store, easy install and uninstall and more.
UWP Console Apps aim to look and feel familiar with programming model very similar to classic Win32 Console apps. Hence you have the well-known
Main method as the entry point (with optional command line arguments).
For now, console applications are compatible with Desktop and IoT SKUs only, because only these two currently have a console shell.
Finally, a concept of execution aliases is introduced, which allows the developer to create a
.exe “executable name” for the app. When deployed, the app will get registered as if it was in the
PATH environment variable and the user can then call the UWP console app from anywhere just using its name. In case multiple apps register the same alias, the rule is the first registered app wins but the user can also switch aliases on and off for specific apps manually in the System Settings -> Apps -> Manage app execution aliases.
<uap5:ExecutionAlias Alias="YourApp.exe" />
To learn more about UWP Console apps see the pereliminary documentation and try it out in Insider preview SDKs.
Up until now, UWP apps behaved differently from most classic desktop apps in the way that they were single-instance. UWP originated from the mobile app world and on most devices like phones, tablets and Xbox it usually made sense to have just single app window. When you tried to launch the app again, it just activated the already-open instance. This was not a bad thing per se. It simplifies the programming model and the developer knows that shared resources will not be accessed by multiple processes at the same time. On the other hand it took away some flexibility as the user could perform more than one task at once.
UWP, however, offered an alternative for this in the form of multi-view apps. This enabled a single app instance (process) to open multiple windows at once. This, however, has its limitations like when an unhandled exception occurs in one of the views, it brings down the whole process (taking all other views with it). Also multi-view apps still rather support the idea of having one main view and one or more subordinate views showing additional related information.
The multi-instance model allows us to launch multiple independent processes of one UWP app. At the start, only Desktop and IoT will be supported. There is no limit on the number of instances of your app running at the same time (except your hardware’s limit, of course 🙂 ).
To opt-in the multi-instance mode, you need to add the
SupportsMultipleInstances declaration to your
Package.appxmanifest file. Many apps will work as expected once this is enabled, but the developer needs to be aware of the situations when the instances will access shared package specific resources like files and ApplicationData. To make sure these resources are accessed in a safe manner, you should use a named mutex to protect access to these critical sections of your code.
Visual Studio debugger will automatically attach to all running instances of your app so debugging them is quite easy.
To get a more advanced implementation of the multi-instance app you can provide your own
Main entry point and use the new
AppInstance type to decide when to open a new instance or when to activate an existing one only.
Broad file-system access
One of the most requested features by enterprise developers – broader file system access – is now coming to UWP in two flavors.
Apps that declare an execution alias and are launched from a folder through command line will implicitly have file-system permissions from the current directory down the folder tree.
If this is not enough for your use-case, you may declare the restricted
broadFileSystemAccess capability. On first use, the user will be prompted that he wants to allow this and then the app will be able to access any file-system location (including network drives). The only obstacle is that if your app declares this capability, you must have a good reason to do so, as it will be considered during the app certification when publishing on Microsoft Store.
For more information about broad file-system access see documentation.
February Windows Community Standup was filled with information about great new features coming to the UWP platform in the upcoming release of Windows 10, especially UWP Console apps, multi-instance apps and broader file system access. All are very welcome additions and will give developers an opportunity to create new innovative experiences. The show is released monthly so we can expect a new episode in March if it is not skipped because of Windows Developer Day on March 7th.