Category Archives: UWP

Auto Added by WPeMatico

C# Console UWP Applications – Windows Developer Blog

We’ve just published an update to the Console UWP App project templates on the Visual Studio marketplace here. The latest version (v1.5) adds support for C#. The C# template code only works with Visual Studio 2017 version 15.7 or later. In a previous post, I described how to build a simple findstr UWP app using the C++ Console templates. In this post, we’ll look at how to achieve the same with C#, and call out a few additional wrinkles you should be aware of.Having installed the updated VSIX, you can now choose a C# Console UWP App from the New Project dialog:

Note that C# console apps are only supported from version 10.0.17134.0 of the platform. You should therefore specify a version >= 10.0.17134 for the minimum platform version when you create your project. If you forget this step, you can fix it at any time later by manually editing your .csproj and updating the TargetPlatformMinVersion value. 

Also note that with the C# template, you might get the error message “Output type ‘Console Application’ is not supported by one or more of the project’s targets.” You can safely ignore this message – even though it is flagged as an error, it doesn’t actually make any difference to anything and doesn’t prevent the project from building correctly.
As with the C++ template, the generated code includes a Main method. One difference you’ll notice with the C# version is that the command-line arguments are passed directly into Main. Recall that in the C++ version, you don’t get the arguments into main, but instead you need to use the global __argc and __argv variables. Notice that you can also now use the System.Console APIs just as you would in a non-UWP console app.

static void Main(string[] args)
{
if (args.Length == 0)
{
Console.WriteLine(“Hello – no args”);
}
else
{
for (int i = 0; i < args.Length; i++) { Console.WriteLine($"arg[{i}] = {args[i]}"); } } Console.WriteLine("Press a key to continue: "); Console.ReadLine(); } As before, for the file-handling behavior needed for the findstr app, you need to add the broadFileSystemAccess restricted capability. Adding this will cause your app to get some extra scrutiny when you submit it to the Store. You will need to describe how you intend to use the feature, and show that your usage is reasonable and legitimate.  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap mp uap5 desktop4 iot2 rescap">

Because the app will be doing some simple file handling and pattern matching, in the C++ version, I had to #include the Windows.Storage.h and regex, and declare the corresponding namespaces. In C#, you need the equivalent Windows.Storage and System.Text.RegularExpressions namespaces.
For the findstr functionality, recall that I’m expecting a command-line such as “CsFindstr foo C:Bar”, where “foo” is the pattern to search for, and “C:Bar” is the folder location from which to start the recursive search. I can strip out all the generated code in Main, and replace it with firstly a simple test for the expected number of command-line arguments, and secondly a call to a RecurseFolders method (which I’ll write in a minute). In the C++ version, I tested __argc < 3, but in the managed version I need to test the incoming args.Length for < 2 (the executable module name itself is not included in the C# args). static void Main(string[] args) { if (args.Length < 2) { Console.WriteLine("Insufficient arguments."); Console.WriteLine("Usage:"); Console.WriteLine(" mFindstr ."); Console.WriteLine("Example:"); Console.WriteLine(" mFindstr on D:\Temp."); } else { string searchPattern = args[0]; string folderPath = args[1]; RecurseFolders(folderPath, searchPattern).Wait(); } Console.WriteLine("Press a key to continue: "); Console.ReadLine(); } Now for the custom RecurseFolders method. Inside this method, I need to use a number of async methods for the file handling, so the method needs to be declared async – and this is also why I called Wait() on the Task return from the method back up in Main. I can’t make Main async, so I must make sure to contain all meaningful async return values within the lower-level methods. In this method, I’ll get the StorageFolder for the root folder supplied by the user on the command-line, get the files in this folder, and then continue down the folder tree for all sub-folders and their files: private static async Task RecurseFolders(string folderPath, string searchPattern) { bool success = true; try { StorageFolder folder = await StorageFolder.GetFolderFromPathAsync(folderPath); if (folder != null) { Console.WriteLine( $"Searching folder '{folder}' and below for pattern '{searchPattern}'"); try { // Get the files in this folder. IReadOnlyList files = await folder.GetFilesAsync(); foreach (StorageFile file in files) { SearchFile(file, searchPattern); } // Recurse sub-directories. IReadOnlyList subDirs = await folder.GetFoldersAsync(); if (subDirs.Count != 0) { GetDirectories(subDirs, searchPattern); } } catch (Exception ex) { success = false; Console.WriteLine(ex.Message); } } } catch (Exception ex) { success = false; Console.WriteLine(ex.Message); } return success; } The GetDirectories method is the actual recursive method that performs the same operation (get the files in the current folder, then recurse sub-folders):  private static async void GetDirectories(IReadOnlyList folders, string searchPattern) { try { foreach (StorageFolder folder in folders) { // Get the files in this folder. IReadOnlyList files = await folder.GetFilesAsync(); foreach (StorageFile file in files) { SearchFile(file, searchPattern); } // Recurse this folder to get sub-folder info. IReadOnlyList subDirs = await folder.GetFoldersAsync(); if (subDirs.Count != 0) { GetDirectories(subDirs, searchPattern); } } } catch (Exception ex) { Console.WriteLine(ex.Message); } } Finally, the SearchFile method, which is where I’m doing the pattern-matching, using Regex. As before, I’m enhancing the raw search pattern to search for any whitespace-delimited “word” that contains the user-supplied pattern. Then I walk the returned MatchCollection, and print out all the found “words” and their position in the file.  private static async void SearchFile(StorageFile file, string searchPattern) { if (file != null) { try { Console.WriteLine($"Scanning file '{file.Path}'"); string text = await FileIO.ReadTextAsync(file); string compositePattern = "(\S+\s+){0}\S*" + searchPattern + "\S*(\s+\S+){0}"; Regex regex = new Regex(compositePattern); MatchCollection matches = regex.Matches(text); foreach (Match match in matches) { Console.WriteLine($"{match.Index,8} {match.Value}"); } } catch (Exception ex) { Console.WriteLine(ex.Message); } } } With this, I can now press F5 to build and deploy the app. For console apps it often makes sense to set the Debug properties to “Do not launch, but debug my code when it starts” – because the most useful testing will be done with varying command-line arguments, and therefore by launching the app from a command prompt rather from Visual Studio.  I can test the app using a command window or powershell window:  That’s it! You can now write Console UWP apps in C#. Full source code for this sample app is on Github here. 

Console UWP Applications and File-system Access

As announced in the May 2018 issue of MSDN Magazine, the latest Windows update introduces support for Console UWP apps. We’re also introducing support for UWP apps to get broader access to the file-system than was previously possible. In fact, it was during the design and development phases of the Console app support that we realized we’d need to provide these apps with better file-system access – so the two features complement each other nicely.
Console apps represent a significant departure from the “normal” UWP model. Specifically, these apps don’t have their own windows, and don’t use the familiar input mechanisms. One of the attractions of UWP is the rich UI support, which allows you to build beautiful, highly-interactive apps. Console apps, on the other hand, use the standard console window for input and output, and the model is very much command-line driven and plain-text-based.
So, yes, Console apps are very different from traditional UWP apps, and they meet the requirements of a rather different target audience. They’re aimed squarely at developers who need to build admin or developer tools. To help you get started, we published a set of Console App (Universal) Project Templates in the Visual Studio Marketplace.
Let’s walk through creating a very simple Console UWP app, just to explore the possibilities, and to examine some of the options you have in using UWP features. The finished app is an (extremely primitive) implementation of the classic findstr tool – the app is in the Store here, and the sources are in the AppModelSamples repo on GitHub here.
To create this app from scratch, in VS, having installed the project templates, select File | New Project, and then select one of the two C++ project types for Console UWP apps – either C++/CX or C++/WinRT. In this example, I’ll choose C++/WinRT:

When prompted for the target platform version information, select a version that’s at least 17083 or later (including Windows Insider builds):

Two things to notice in the generated code. First, the Package.appxmanifest declares namespace aliases for desktop4 and iot2, and adds the SupportsMultipleInstances and Subystem attributes to both the Application node and the AppExecutionAlias node:

<Applications>
<Application Id="App"
Executable="$targetnametoken$.exe"
EntryPoint="MyFindstr.App"
desktop4:Subsystem="console"
desktop4:SupportsMultipleInstances="true"
iot2:Subsystem="console"
iot2:SupportsMultipleInstances="true"
>

<Extensions>
<uap5:Extension
Category="windows.appExecutionAlias"
Executable="MyFindstr.exe"
EntryPoint="MyFindstr.App">
<uap5:AppExecutionAlias
desktop4:Subsystem="console" iot2:Subsystem="console">
<uap5:ExecutionAlias Alias="MyFindstr.exe" />
</uap5:AppExecutionAlias>
</uap5:Extension>
</Extensions>

</Application>
</Applications>

From this it should be clear that in this release Console UWP apps are only supported on Desktop and IoT devices. Currently, only Desktop and IoT devices have consoles, so the feature only makes sense there.
The second thing to notice is the main function in Program.cpp. This simply gets hold of the command-line arguments and prints them out in a loop to the console.

int 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] = %Sn", i, __argv[i]);
}

wprintf(L"Press Enter to continue:");
getchar();
}

You can press F5 at this point, just to get the app built and deployed, before changing anything.

As expected, if you execute the app this way, the only command-line argument is __argv[0], which is the executable filename itself. Now that the app is deployed, you can also run it from its tile on the Start menu – and get the exact same results.
However, if you run a separate cmd (or Powershell) window, and execute the app from there, you can then provide any arbitrary command-line arguments you like. This works because installing the app also registered the AppExecutionAlias declared in the manifest. By default, this is set to the same as the project name, although you can of course change this, if you wish:

You can see from the standard generated code that you can use many of the traditional Win32 APIs – the latest Windows update adds a lot more console-specific APIs to the approved list, so that these can be used in Store-published apps.
But, what if you want to use WinRT APIs? Well, of course, this is a UWP app, so you’re free to use WinRT APIs also. This does come with a caveat, however. There are some WinRT APIs that assume that the caller is a regular UWP app with a regular window and view. A console app doesn’t have a regular window or view, so any window-specific APIs won’t work. For the more obvious window-related APIs, you should have no reason to call any of them since you don’t have your own windows, so the point should be moot.
For our simple findstr app, the first change is to add the broadFileSystemAccess restricted capability to the manifest. Add the namespace declaration at the top:

xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp desktop4 iot2 rescap">

…and then the capability itself at the bottom:

<Capabilities>
<Capability Name="internetClient" />
<rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>

This corresponds to the File system setting under Privacy in the Settings app. This is where the user can enable or disable broad File-system access on either a per-app basis, or globally for all UWP apps:

Now for the meat of the app. The classic findstr tool is used to perform string searches in files. It has a lot of command-line options for configuring the search. Internally, it performs all the operations from scratch, using low-level Win32 APIs and without using any higher-level libraries. However, for the purposes of this demo, I’m going to cheat and use the std::regex APIs. One obvious reason for this is because I don’t want to write thousands of lines of code for this sample. A less obvious reason is that I want to explore how to use libraries of different types in my Console UWP app (more on this in a later post). My cut-down version of findstr will take in only two simple command-line arguments:
A pattern to search for.
A fully-qualified folder path, in which to search.
First, some housekeeping. I’ll add some #includes in my pch.h. I plan on using the Windows.Storage APIs as well as std::regex:

#include "winrt/Windows.Storage.h"
#include <regex>

At the top of my Program.cpp, I’ll add corresponding namespace declarations:

using namespace winrt;
using namespace winrt::Windows::Storage;
using namespace Windows::Foundation::Collections;

Now I can update main to get the search pattern and the starting folder supplied on the command-line. If for some reason I can’t open that folder using the Storage APIs, I’ll just bail with some suitable error code. This could be because the user has disabled File-system access in Settings, or because the folder path supplied was non-existent or badly-formed, and so on. Also note that I’m not doing any input-validation here – but of course in a real app you would be very careful to check all inputs before proceeding, and most especially if your app is expecting to have broad file-system access.

int main()
{
hstring searchPattern = to_hstring(__argv[1]);
hstring folderPath = to_hstring(__argv[2]);
StorageFolder folder = nullptr;
try
{
folder = StorageFolder::GetFolderFromPathAsync(folderPath.c_str()).get();
}
catch (…)
{
wprintf(L"Error: cannot access folder ‘%S’n", __argv[2]);
return 2;
}

If I did manage to get the folder open, I can then continue to use the Storage APIs to get all the files in this folder for searching, and then to call a recursive GetDirectories function, so that I can walk the folder tree from this point downwards. I’ll write the GetDirectories and SearchFile functions shortly.

if (folder != nullptr)
{
wprintf(L"nSearching folder ‘%s’ and below for pattern ‘%s’n", folder.Path().c_str(), searchPattern.c_str());
try
{
IVectorView<StorageFolder> folders = folder.GetFoldersAsync().get();

// Recurse sub-directories.
GetDirectories(folders, searchPattern);

// Get the files in this folder.
IVectorView<StorageFile> files = folder.GetFilesAsync().get();
for (uint32_t i = 0; i < files.Size(); i++)
{
StorageFile file = files.GetAt(i);
SearchFile(file, searchPattern);
}
}
catch (std::exception ex)
{
wprintf(L"Error: %Sn", ex.what());
return 3;
}
catch (…)
{
wprintf(L"Error: unknownn");
return 3;
}
}

return 0;
}

Now for the recursive GetDirectories function. Given the collection of folders in the current directory, I can recursively process all sub-directories. At each level, I can also get all the files for searching.

void GetDirectories(IVectorView<StorageFolder> folders, hstring searchPattern)
{
try
{
for (uint32_t i = 0; i < folders.Size(); i++)
{
StorageFolder folder = folders.GetAt(i);

// Recurse this folder to get sub-folder info.
IVectorView<StorageFolder> subDir = folder.GetFoldersAsync().get();
if (subDir.Size() != 0)
{
GetDirectories(subDir, searchPattern);
}

// Get the files in this folder.
IVectorView<StorageFile> files = folder.GetFilesAsync().get();
for (uint32_t j = 0; j < files.Size(); j++)
{
StorageFile file = files.GetAt(j);
SearchFile(file, searchPattern);
}
}
}
catch (std::exception ex)
{
wprintf(L"Error: %Sn", ex.what());
}
catch (…)
{
wprintf(L"Error: unknownn");
}
}

Now, the SearchFile function. This is where I’m cheating and using std::regex instead of doing all the work myself. First, I’ll read all the text out of the file with ReadTextAsync. If the file isn’t a text file, this will throw an exception – for simplicity, I’m just reporting the error and moving on. Then, I enhance the raw search pattern to search for any whitespace-delimited “word” that contains the pattern. Finally, I use regex_search to do the pattern-matching, and print out all the found words and their position in the text:

void SearchFile(StorageFile file, hstring searchPattern)
{
if (file != nullptr)
{
try
{
wprintf(L"nScanning file ‘%s’n", file.Path().c_str());
hstring text = FileIO::ReadTextAsync(file).get();
std::string sourceText = to_string(text);
std::smatch match;
std::string compositePattern =
"(S+s+){0}S*" + to_string(searchPattern) + "S*(s+S+){0}";
std::regex expression(compositePattern);

while (std::regex_search(sourceText, match, expression))
{
wprintf(L"%8d %Sn", match.position(), match[0].str().c_str());
sourceText = match.suffix().str();
}
}
catch (std::exception ex)
{
wprintf(L"Error: %Sn", ex.what());
}
catch (…)
{
wprintf(L"Error: cannot read text from file.n");
}
}
}

One additional convenience: because this is a UWP app, it will have an entry in the Start menu app-list, and the user could pin its tile to Start. So, if could be executed from Start – in which case, of course, it won’t have any command-line arguments. Given how I’m assuming the command-line includes at least a search pattern and folder path, I’ll allow for this with a simple check. So, I’ll add this right at the beginning of main:

if (__argc < 3)
{
ShowUsage();
return 1;
}

…and define the matching ShowUsage function:

void ShowUsage()
{
wprintf(L"Error: insufficient arguments.n");
wprintf(L"Usage:n");
wprintf(L"MyFindstr <search-pattern> <fully-qualified-folder-path>.n");
wprintf(L"Example:n");
wprintf(L"MyFindstr on D:Temp.n");

wprintf(L"nPress Enter to continue:");
getchar();
}

That’s it! Having re-deployed this version with F5, I can then execute it from a cmd or Powershell window, supplying a search pattern and a starting folder on the command-line:

Now admittedly, my findstr app has only the most basic functionality, but hopefully it does illustrate how easy it is to create a simple Console UWP app that consumes both standard C++ library APIs and WinRT APIs.
For anyone who has already started experimenting with Console UWP apps, it’s worth calling out that the original version of the VS templates had a couple of bugs (or, arguably, a bug and an anomaly), which were fixed in version 1.4. The issues do not prevent the app from building and executing, but they do prevent F5 debugging and also correct packaging and store publication. If you have already created projects using the old templates, you can apply the fixes by making the same changes in the .vcxproj and package.appxmanifest files manually (for both C++/CX and C++/WinRT).
First, the bug. In the package.appxmanifest file, v1.4 added iot2 to the ignorable XML namespaces:

IgnorableNamespaces="uap mp uap5 iot2 desktop4">

Of course, if you’re not targeting IoT devices, then you can instead delete this, and also delete the IoT namespace declaration itself:

xmlns:iot2="http://schemas.microsoft.com/appx/manifest/iot/windows10/2"

…as well as the iot2-scoped Subsystem declarations in both the Application and AppExecutionAlias nodes:

iot2:Subsystem="console"

Now for the anomaly: v1.3 of the template included declarations in the .vcxproj file that are specific to .NET Native. These are required if your app includes say a C# WinRT component, where .NET Native is used. However, if your app doesn’t include such a component then the declarations will prevent correct packaging. In v1.4 of the template, these have been removed – both the target framework declarations at the top of the file:

<TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier>
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>

…and also multiple instances of the following:

<PlatformToolset>v141</PlatformToolset>
<UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>

Please also note that all C++/WinRT templates are still experimental at this stage, and subject to change.
Apologies for any inconvenience caused by the bugs – and please do let us know if you have any feedback on the templates, or on the Console UWP feature.
For documentation, see Create a Universal Windows Platform Console app and File access permissions.

Announcing a new name for the UWP Community Toolkit: Windows Community Toolkit

I’m really excited to announce, starting with the next major release, the UWP Community Toolkit will have a new name – the Windows Community Toolkit. This is a huge milestone for the toolkit and the community that has made this project possible.
The toolkit was first released over a year and a half ago with 26 different features. Since then, we’ve added five new packages over nine new releases, each one adding new controls, helpers, services, extensions, object models and more – most coming from the community directly. Today, there are over 100 distinct features. Just compare the number of controls (and categories) in the sample app from the initial release:

UWP Community Toolkit Sample App (v1.0)

UWP Community Toolkit Sample App (v2.2)
When we initially released the UWP Community Toolkit, we received feedback that developers want to share toolkit components with other frameworks such as WPF, WinForms, Xamarin, .NET Core, and more. In v2.0, with the help of the community, we identified components that could be factored out in .NET Standard libraries and created new .NET Standard packages so more developers could take advantage of the community work – and many did. Many of the services, helpers, and parsers are cross platform today and can be used anywhere – and we are working to enable even more.
Enabling more developers is what the toolkit is all about, so starting with the next Windows Community Toolkit release, we are setting a goal to enable more Windows developers working on Windows 10 experiences to take advantage of toolkit components where possible. Therefore, the new name is reflective of this increased focus and more inclusive of all Windows developers.
The community is working enthusiastically towards the next major toolkit update, currently scheduled for late May. All the work is done in the open and we invite any developer to participate and contribute. To get started with the latest and greatest today, visit the GitHub repository and dive into the code. Or if you rather use NuGet packages, preview packages will be published on NuGet right on time for the Microsoft Build conference. We will update the documentation and the sample app at the same time but keep in mind these are pre-release packages and they might change for the final release.
To join the conversation on Twitter, use the #windowstoolkit hashtag. And if you are attending Microsoft Build 2018, just stop by our booth to say hi!
Happy coding!

Start developing on Windows 10 April 2018 Update today

We’re excited to announce that the Windows 10 April 2018 Update (build 17134.1) and SDK is now available. You may also know this as Windows 10, version 1803.
A few new features and APIs sure to become your favorites
Every major Windows 10 update always includes a wide range of APIs. These will surely be among your favorites.
Windows Machine Learning (WinML): WinML allows you to run ML ONNX models on any Windows 10 device on the April 2018 Update or greater. By just dragging your model into VS, loading the model, then executing it based on inputs, you can add machine learning into your application. If your model isn’t already in the ONNX format, there are converts for most formats.
Timeline, User Activities, and Adaptive Cards: User Activities and Timeline are amazing new ways for users to re-engage with your application and maintain context. To do your graphical representation, use Adaptive Cards, an open source card exchange format. Be sure your application has a URI schema, so you can enable deep linking. User Activities and Adaptive Cards will also become important APIs in Sets, which we’ll discuss more at Microsoft Build 2018.
New UX controls: Tree view, pull to refresh, and content links are just a few of the new controls added. These new controls can add new functionality and richness to your application.
Multi-instance for UWP applications: In the April 2018 update, you can create multi-instance applications. On top of launching new processes, it allows for customization in cases where you want to select whether a new instance of your app is launched or an instance that is already running is activated.
Update your dev environment in two simple steps
Update your system to Windows 10 April 2018 Update.
Get Visual Studio 2017 with the updated tooling and Windows 10 SDK.
How to update your device to Windows 10 April 2018 Update
There are multiple ways you can update, but the easiest way is to go to Windows Update in your settings and click “check for updates.” It’s that simple. You can also use the Update Assistant or the media creation tool also.
Acquire the Windows 10 SDK and Visual Studio 2017
Now that your system is on Windows 10 April 2018 Update, install Visual Studio and the new SDK.
• If you are currently running Visual Studio 15.6:
Download install the SDK from here: https://go.microsoft.com/fwlink/?linkid=870807
Install
• When Visual Studio 2017 15.7 is released:
Run the installer or go to https://www.visualstudio.com/downloads/ and download it.
Select “Universal Windows Platform development” under Workloads.
Verify Windows 10 SDK (10.0.17134) is checked
Click “Install.”
More useful tips
Do you want tools for C++ desktop or game development for UWP? Be sure one of these two are selected:
C++ Universal Windows Platform tools in the UWP Workload section
Desktop development with C++ Workload and the Windows SDK 10 (10.0.17134)

If you want the Universal Windows Platform tools:
Select the Universal Windows Platform tools workload.

Once your systems are updated and recompiled and your app is tested, submit your app to Dev Center.
Your take on the Update
Tell us what crazy things you’ve been working on with the new Update by tweeting @WindowsDev or @ClintRutkas.

Announcing new Ad Monetization policies and updates to Ad unit management UX

Today, we are announcing new policy around ad unit decommissioning, user experience updates to manage active/inactive ad units, default policies around Ad network enablement, and changes to the Ad impression measurement methodology for Windows apps. You may be impacted if you are monetizing using Ads on your Windows app leveraging the Microsoft Advertising SDK (UWP or 8.x apps).
1) Auto enabling new ad networks for Manual ad units on UWP apps
Our team continues to evaluate and onboard new Ad networks to improve yield and offer better variety of demand (formats, market specific demand) for our publishers. Today, when a new ad network is onboarded to our system, UWP ad units that are configured with the ‘Manual configuration’ option do not benefit from these networks as they are not automatically turned on for the Manual ad units. We will be making a change over the next few weeks to turn on any new ad networks by default for all our UWP ad units independent of the Manual or Automatic configuration. For ad units in the Manual configuration, since the ad network waterfall configuration is determined by publisher’s choice, these ad networks will be added to the bottom of the waterfall order. The publisher can then make necessary changes to reorder or opt out of the ad networks as necessary. As always, our recommendation is to choose the ‘Automatic’ ad unit configuration to benefit the most from our platform’s yield maximization capabilities. 
2) Policy updates around decommissioning of Ad units
We are implementing an ad unit decommissioning policy wherein an ad unit that hasn’t generated any Ad request over the last 6 months will be subject to deactivation and deletion. We don’t expect active apps to be impacted since we look for a prolonged period (6 months) of ad unit inactivity before we deactivate. However, there may be exceptional circumstances where you may be affected. For instance, if you created an ad unit several months ahead of app deployment time and trying to use this ad unit as your app goes live. Or, you are trying to reuse an existing ad unit from your previous inactive app into your new app. Recommendation in both cases is to use newly created ad units instead of reusing an existing one to avoid potential Ad revenue loss.
Along with this policy announcement, we are making changes in the Windows Dev Center dashboard to make it easy to view active and inactive Ad units. Ad unit state is identified in a separate Status column; in addition, you can choose to view just the Active or Inactive ad units by choosing the appropriate filter on the top of the page.

3) Transitioning to Standards based Ad impression measurement
Standards based Ad impression measurement requires that the ‘Ad must be loaded and at minimum begin to render’ to be counted as a valid impression. For Ad networks that are relying on other methods such as server based Ad impression counting, we are making changes to gradually migrate all our Windows app ad units over the next few months closer to Standards based measurement. More specifically, the impression counting will rely on techniques such as firing an ad network impression beacon upon starting to render the Ad on the client. This is done to better adhere to the IAB standards around Ad impression counting and to be fair to the advertisers. This will also benefit apps that are striving to do right by making sure that Ads are rendered on the client and are viewable.
If you are following standard guidelines put forth in our documentation and recommendations from earlier blogs on how to design the Ad placements in your app, you should not see adverse impact on your Ad monetization. However, if your app is designed in a way that interferes with the rendering of the Ad, you may see a negative impact on your App Ad revenues. For instance, if you are placing an Ad in a UI dialog box that can be easily dismissed by the user before the Ad gets a chance to render or your app is pulling Ads on a background thread, these Ads that previously were possibly counted as valid impressions will not be counted in the new standard. We strongly recommend you to evaluate your app for such practices and actively fix these issues to minimize impact to your Ad revenues.
Please reach out to aiacare@microsoft.com for questions or comments!

Windows Community Standup on February 22, 2018

Kevin Gallo, VP of Windows Developer Platform, is hosting the next Windows Community Standup on February 22, 2018 at 12:00pm PST on Channel 9! 
Kevin will be joined by Andrew Whitechapel to discuss the latest updates to the application model which will be available in the next update for Windows 10. Andrew and Kevin will discuss multi-instance, broader file access, and UWP console applications. We will also be answering your questions live.  
Windows community standup is a monthly online broadcast where we provide additional transparency on what we are building and why we are excited. As always, we welcome your feedback. 
Once again, please tune in on February 22, 2018 at 12:00pm PST on https://channel9.msdn.com.

#ifdef WINDOWS – One Developer’s Guide to the Surface Hub

Building experiences for the Surface Hub requires developers to tailor their apps for the big screen and multiple users interacting with different components at the same time. Gian Paolo Santopaolo came to Redmond all the way from Switzerland to share best practices for developing engaging and natural user experiences for the Surface Hub. He has spent the last 6 years as a Windows MVP, designing and developing natural user experiences for various devices including the Microsoft Surface Hub and Microsoft HoloLens. During this time, Gian Paolo has developed many open source components and helpers to enable developers to build better and more personal UWP apps for every device and scenario.
Watch the full video above and feel free to reach out on Twitter or in the comments below for questions or comments.
Happy coding!

Target Surface Hub and Windows 10 S on a Snapdragon processor with your UWP apps

When submitting your UWP app or game to Microsoft Store through Dev Center, you have the flexibility to choose the device families on which customers can acquire your app. By default, we make your app or game available to all device families which can run it (except for Xbox, which you can opt into as appropriate if your packages support it). This lets your apps and games reach the most potential customers.
Recently, we’ve added new options that let you offer your submission to customers on Surface Hub. You can now also offer ARM packages to Windows 10 S on a Snapdragon processor (Always Connected PCs).

To target Surface Hub when submitting your UWP app to the Microsoft Store, simply ensure that the box for the Windows 10 Team device family is checked. This is generally the case if you upload packages targeting the Universal or Team device family.
If you include an ARM package in your submission that targets the Universal or Desktop device family, this package will be made available to Windows 10 S on a Snapdragon processor (Always Connected PCs) devices as long as the Windows 10 Desktop device family box is checked.
The example above shows three packages that target the Universal device family, x64, ARM and x86. The boxes for Windows 10 Desktop, Windows 10 Mobile, Windows 10 Xbox, Windows 10 Team, and Windows 10 Holographic are selected. This means that customers on any of those device types can download this submission.
For more about device family selection, check out our documentation.

App packaging and testing
App packages are configured to run on a specific processor architecture. We highly recommended that you build your app packages to target all architectures whenever possible, so your app will run smoothly on all Windows 10 devices. To learn more, visit our app package architecture documentation.
We highly recommend that you test your app on all device families that you plan to support to ensure the best experience on all devices. To learn more about steps to take before packaging and submitting your UWP app, read our documentation.

#ifdef WINDOWS – LottieUWP – Native Adobe After Effects animations in UWP apps

Lottie is a client library that parses Adobe After Effects animations exported as json and renders them natively on the client. Alexandre maintains the UWP port of the library (LottieUWP), and stopped by to discuss why developers should use Lottie over other formats (such as gifs) and the benefits of a natively rendered and accelerated animations.
Check out the full video above where I learned how to get started with LottieUWP, and more importantly, where to discover existing animations that can make your apps more beautiful and responsive. And feel free to reach out on  Twitter or in the comments below.
Happy coding!

Now Available: Offer Add-on Subscriptions with Automated Recurring Billing in Your UWP Apps

Today we are extremely excited to announce that subscription add-ons are available to all UWP developers. You can use subscriptions to sell digital products in your app with automated recurring billing while giving your customers a seamless purchase experience. One thing to keep in mind is that the Store fee for recurring billed subscriptions differs from other business models in Microsoft Store. For any add-on subscriptions in apps (but not games), you receive 85% of the subscription price, minus applicable taxes. For game add-on subscriptions, you receive 70% of the subscription price, minus applicable taxes. Please read the Microsoft Store App Developer Agreement for further details on Store Fees and other terms relating to subscriptions.
Creating a subscription add-on
To enable the purchase of subscription add-ons in your app, your project must target Windows 10 Anniversary Edition (10.0; Build 14393) or a later release in Visual Studio (this corresponds to Windows 10, version 1607), and it must use the APIs in the Windows.Services.Store namespace to implement the in-app purchase experience instead of the Windows.ApplicationModel.Store namespace. For more information about the differences between these namespaces, see In-app purchases and trials.
1) Create an add-on submission for your subscription in the Dev Center dashboard and publish the submission.
For Product type, ensure that you select Subscription.

When offering subscription add-ons to your customers, you can choose to offer a subscription period of 1 month, 3 months, 6 months, 1 year or 2 years. You can also add a free trial period of 1 week or 1 month so your customers can try out the add-on before they commit to purchasing.
2) In your app, use APIs in the Services.Store namespace to determine whether the current user has already acquired your subscription add-on and then offer it for sale as an in-app purchase.
3) Test the in-app purchase implementation of your subscription in your app. You’ll need to download your app once from the Store to your development device to use its license for testing.
4) Create and publish an app submission that includes your updated app package, including your tested code.
For a complete overview of add-on subscriptions and how to implement them into your UWP app, please visit our documentation.
Customer management
Customers can manage their purchased subscriptions from the services & subscriptions page for their Microsoft account. Here they’ll find all the subscriptions they have acquired, with options to cancel a subscription or change the form of payment associated with a subscription.
Offering add-on subscriptions can be a great monetization strategy for your apps and games. As you go through the implementation process, please provide us with any feedback via the Feedback link in the upper right corner of the Dev Center dashboard.