Page 18 - MSDN Magazine, May 2018

Figure 3 Additional Manifest Entries for a Console App
of the benefits of the UWP, including APPX packaging, Store publication, easy updates and so on.
Broader File-System Access
Until now, a UWP app has only been able to access certain specific folders, such as the Pictures library and the Music library—and then only if the app declares these as capabilities in its manifest. Beyond that, the app could get access to anywhere else in the file system by raising a FilePicker dialog and prompting the user to choose a location, which grants the app permissions.
Now, the third major feature added for Win32 parity increases the level of file-system access for UWP apps. This was done in two ways by including:
• Implicit access to the current working directory.
• Broad file-system access gated by a restricted capability. Any UWP app (either a regular windowed app or a console app) that declares an AppExecutionAlias is now granted implicit access to the files and folders in the current working directory and downward, when it’s activated from a command line. The current working directory is from whatever file-system location the user chooses to execute your AppExecutionAlias. This was debated for a long time, as the UWP model has always been very cautious about granting file-system access to apps. On balance, it was decided that the user choosing to execute the app from a particular location is equivalent to the user choosing a location in a FilePicker dialog,
in terms of granting permissions.
It’s important to note that the app has exactly the same file permis-
sions as the user who’s running the app—so there might still be files or folders the app can’t access, because the user can’t access them, either. For example, if the user can’t see a hidden file when they exe- cute a dir command, the app also won’t be able to see that hidden file.
To take advantage of this feature, you can code the OnActivated override to look for CommandLineActivatedEventArgs. This will include the CurrentDirectoryPath, which in this case will be the file-system location from which the user executed your AppExecutionAlias. Figure 6 shows an example; here, the app extracts the current directory and passes it on to the MainPage.
You could then code your MainPage OnNavigatedTo override to retrieve this path from the incoming NavigationEventArgs, as shown in Figure 7. In this example, the app is initializing a StorageFolder from this path, and then building a TreeView con- trol for the files and folders from here downward.
<Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="App9.App" desktop4:Subsystem="console" desktop4:SupportsMultipleInstances="true" iot2:Subsystem="console" iot2:SupportsMultipleInstances="true">
... <Extensions>
<uap5:Extension Category="windows.appExecutionAlias" Executable="App9.exe" EntryPoint="App9.App"> <uap5:AppExecutionAlias
desktop4:Subsystem="console" iot2:Subsystem="console"> <uap5:ExecutionAlias Alias="App9.exe"/>
</uap5:AppExecutionAlias> </uap5:Extension>
</Extensions> </Application>
Figure 4 Template-Generated Code for a Console App Main Function
int __cdecl main() {
// You can get parsed command-line arguments from the CRT globals. wprintf(L"Parsed command-line arguments:\n");
for (int i = 0; i < __argc; i++)
{
wprintf(L"__argv[%d] = %S\n", i, __argv[i]); }
wprintf(L"Press Enter to continue:");
getchar(); }
have console windows right now. The same XML namespaces are declared. The <Application> element includes both Supports- MultipleInstances and Subsystem attributes, with Subsystem set to “console”. Console apps must be multi-instanced—this is the expected model for apps moving from traditional Win32 console apps. In addition, the app includes an AppExecutionAlias—and this also has the new Subsystem attribute, as shown in Figure 3.
YoucanchangetheAliasvaluetosomethingappropriateforyour app. Again, as with multi-instancing, the code-generation includes a Program.cs or Program.cpp file. The generated code provides an example of how you could implement the required main function, as shown in the C++ example in Figure 4. You can replace all the code inside main with your own custom code.
Once you’ve built and deployed the app, you can execute it from a regular command prompt, PowerShell window, or Windows-R, as shown in Figure 5. Note that because the app uses the console window, it’s not expected to create any other windows—and indeed, this is not supported. Instead, the app can now use all the System.Console APIs, plus many traditional Win32 APIs that have now been added to the approved list specifically to support console apps.
With this feature, you can finally build com- mand-line console apps that take advantage
14 msdn magazine
Figure 5 Executing a Console UWP App from the Command Line
Universal Windows Platform