Category Archives: UWP

Auto Added by WPeMatico

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 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

#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.

Application Engagement in Windows Timeline with User Activities

Great applications help users do great things — enabling a wide range of creative, productivity and entertainment scenarios. Returning to activities can be a challenge, especially when a person wants to continue those activities across multiple devices. By writing User Activities, application developers have a new tool to get users back into their application.
In this article, you’ll learn how to drive application re-engagement by writing great User Activities into the Microsoft Graph with their UWP applications. This article is also a companion to the Microsoft Connect(); session: Engaging with your customers on any platform using the Microsoft Graph, Activity Feed, and Adaptive Cards.
User Activities and Timeline
Starting in Windows Insider Preview build 17056 or higher, User Activities generated by your application appear in Timeline. By writing User Activities into the Microsoft Graph, you can express specific content within your application as a destination which is showcased in Windows, and accessible on your iOS and Android devices.

Each User Activity represents a single destination within your app: such as a TV show, document or your current campaign in a game. When you engage with that activity (by creating an Activity Session), the system creates a history record indicating the start and end time for that activity. As you re-engage with that User Activity over time, multiple History Records will be recorded for a single User Activity. Here’s how to get started:
Install Windows SDK for Windows 10 Fall Creators Update (10.0.16299) or the latest Windows Insider Preview SDK. The Windows Insider Preview SDK requires Visual Studio 2017
To try out Timeline, install the Windows Insider Preview on the target machine
Adding UserActivities to your app
UserActivities are the unit of user engagement in Windows, and they consist of three components: a deep-link, visuals and content metadata.
The Activation Deep Link is a URI that can be passed back to an application or experience in order to resume the application with specific context. Typically, these links take the form of protocol handler for a scheme (e.g. “my-app://page2?action=edit”) or an AppUriHandlers (e.g.
Visuals are a set of properties that allow users to visually identify an activity, for example: title, description, or Adaptive Card elements.
Finally, Content Metadata is metadata for the content of the of activity that can be used to group and retrieve activities under a specific context. Often, this takes the form of data.
In order to integrate UserActivities with your application, you need to:
Generate UserActivity objects when your user’s context changes within an application (page navigation, new game, etc.)
Populate UserActivity objects with the minimum set of required fields: ActivityId, ActivationUri, DisplayText
Add a custom scheme handler to your application so it can be re-activated by your UserActivities
UserActivities can be integrated into an application with just a few lines of code:

UserActivitySession _currentActivity;

private async Task GenerateActivityAsync()
//Get the default UserActivityChannel and query it for our UserActivity. If the activity doesn’t exist, one is created.
UserActivityChannel channel = UserActivityChannel.GetDefault();
UserActivity userActivity = await channel.GetOrCreateUserActivityAsync("MainPage");

//Populate required properties
userActivity.VisualElements.DisplayText = "Hello Activities";
userActivity.ActivationUri = new Uri("my-app://page2?action=edit");

await userActivity.SaveAsync(); //save the new metadata

//Dispose of any current UserActivitySession, and create a new one.
_currentActivity = userActivity.CreateSession();

The first line in the GenerateActivityAsync() method gets a user’s UserActivityChannel. This is the feed that this app’s activities will be published to. The next line queries that channel of an activity called “MainPage”
Your application should name activities in such a way that same ID is generated each time the user is in a particular location in the app. For example, if your application is page-based, use an identifier for the page, if it’s document based, use the name of the doc (or a hash of the name).
If there is an existing activity in the feed with the same ID, that activity will be return from the channel (with the UserActivity object State property set to Published). If there is no activity with that name, and new activity with State set to New.
Activities are scoped to your app, there is no need to worry about your activity ID colliding with IDs from other applications
After getting or creating the activity the next lines of code specify the other two required fields: the DisplayText and the ActivationUri.
Next, save the UserActivity metadata, by calling SaveAsync(), and finally CreateSession(). That last method returns a UserActivitySession object that we can use to manage when the user is actually engaged with the UserActivity. For example, we should call Dispose() on the UserActivitySession when the user leaves the page. In the example above, we also call Dispose() on _currentActivity right before we call CreateSession(). This is because we made _currentActivity a member field of our page, and we want to stop any existing activity before we start the new one (the ‘?’ is an inline null-check).
Since, in this case, our ActivationUri is a custom scheme, we also need to register the Protocol in the application manifest. This can be done in the Package.appmanifest XML file, or using the designer, as shown below. Double-click the Package.appmanifest file to launch the designer, select the Declarations tab and add a Protocol definition. The only property that needs to be filled out, for now, is Name. It should match the URI we specified above hello-activities.
Now we need to write some code to tell the application what to do when it’s been activated via a protocol. In this case, we’ll override the OnActivated method in App.xaml.cs to pass the URI on to our MainPage:

protected override void OnActivated(IActivatedEventArgs e)
if (e.Kind == ActivationKind.Protocol)
var uriArgs = e as ProtocolActivatedEventArgs;
if (uriArgs != null)
Frame rootFrame = Window.Current.Content as Frame;
if (uriArgs.Host == "page2”)
rootFrame.Navigate(typeof(SecondaryPage), uriArgs)

Use Adaptive Cards to Improve the Timeline Experience
User Activities will appear in Cortana and Timeline experiences. When activities appear in Timeline, we display them using the Adaptive Card framework. If you do not provide an adaptive card for each activity, Timeline will automatically create a simple activity card based on your application name and icon, the required Title field and optional Description field. Below is an example Adaptive Card payload and the card it produces.

"$schema": "",
"type": "AdaptiveCard",
"backgroundImage": "",
"body": [
"type": "Container",
"items": [
"type": "TextBlock",
"text": "Windows Blog",
"weight": "bolder",
"size": "large",
"wrap": true,
"maxLines": 3
"type": "TextBlock",
"text": "Training Haiti’s radiologists: St. Louis doctor takes her teaching global",
"size": "default",
"wrap": true,
"maxLines": 3

Adaptive Cards can be added to the UserActivity object by passing a JSON string to the AdaptiveCardBuilder and setting the UserActivity.VisualElements.Content property:

activity.VisualElements.Content =

Cross-platform and Service-to-service integration
If your application has a cross-platform presence (for example on Android and iOS), or maintains user state in the cloud, you can publish UserActivities via integration with Microsoft Graph.
Once your application or service is authenticated with a Microsoft Account, it is two simple REST calls to generate Activity and History objects, using the same data as described above.
In this blog post, we learned how to use the UserActivity API to make your application show up in Timeline and Cortana, but there is much more you can do:
Learn more about UserActivity API on the Windows Dev Center, or check out the sample code at
Check some more sophisticated Adaptive Cards at io
Publish UserActivities from iOS, Android or your web service via MS Graph
Learn more about Project Rome on GitHub

Extend your desktop application with Windows 10 features using the new Visual Studio Application Packaging Project

Visual Studio 2017 15.4 introduced the new Windows Application Packaging project to help you modernizing your application by using the new Windows 10 App Deployment Stack.
We talked about it in our previous post: Visual Studio 2017 Update 4 makes it easy to modernize your app and make it store ready and today we want to describe the new capabilities in Visual Studio 2017 15.5 that enable new scenarios to the Windows application packaging project to take advantage of more Windows 10 features in your applications.
During this article we will cover three examples to highlight the new capabilities added to the packaging project to enable packaging for not only Win32 applications, but also UWP applications and components:
Background execution using UWP background tasks.
Windows Shell integration using the Share Target contract.
Include Win32 code investments in your UWP app package.
The first two samples are existing WPF applications packaged as APPX with extended functionality implemented as UWP components. The first application adds background execution based on UWP background tasks, while the second app shows how to deeply integrate the application with the Windows 10 shell using a widely available feature as Share contracts. Finally, the last app is a UWP entry point that calls to a classic Win32 process that interop with Excel.
Note: Because the UWP components require to be compiled for a specific platform: x86 or x64, the Any CPU solution configuration will not work in any of these samples.
All samples are available in the GitHub repo Windows-Packaging-Samples. These samples require Visual Studio 2017 15.5 Preview 4 or greater, available to download from
1. WPF with Background Tasks
The Universal Windows Platform includes support for advanced background processing. Background tasks allow running code even when the app is suspended. Background tasks are intended for small work items that do not require user interaction, such as downloading mail, showing a toast notification for an incoming chat message or reacting to a change in a system condition.
To show how to use this feature from your Win32 applications, we are going to implement a small utility that will make an HTTP request to a URL configured by the user and will show the elapsed milliseconds in a Toast Notification.

We will create a WPF application to allow the user to specify the URL to check and enable/disable the background task. The background task will be implemented as a Windows Runtime Component (WINMD). To be able to include this component in the package, we need to create a UWP application that uses the component, and finally add the WPF and UWP projects as references to the packaging project. Below is the list of steps needed.
You can find the complete source code of this sample in the GitHub repository, but if you want to create the sample from scratch here are the most important steps.
Package your desktop application using the packaging project
Add a Windows Runtime component to implement the background task
Add a UWP application that reference the runtime component
Add a reference to the UWP application from the packaging project
Configure the Background task in the manifest
Register the background task from the Desktop application
Once you completed steps 1 to 4, you should have a solution for projects as shown in the image below:

The packaging project references not only the WPF application, but also the UWP project. For this reason, the solution needs to be configured for a specific platform, since UWP is not available for Any CPU configurations.
Background Task implementation
The background task is a C# class that implements the IBackgroundTask interface. This interface defines the Run method that will be called when the system triggers the task.

public sealed class SiteVerifier : IBackgroundTask
public async void Run(IBackgroundTaskInstance taskInstance)

taskInstance.Canceled += TaskInstance_Canceled;
BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
var msg = await MeasureRequestTime();

private async Task<string> MeasureRequestTime()
string msg;
var url = ApplicationData.Current.LocalSettings.Values["UrlToVerify"] as string;
var http = new HttpClient();
Stopwatch clock = Stopwatch.StartNew();
var response = await http.GetAsync(new Uri(url));
var elapsed = clock.ElapsedMilliseconds;
msg = $"{url} took {elapsed.ToString()} ms";
catch (Exception ex)
msg = ex.Message;
return msg;

Note how we use the LocalSettings in ApplicationData to share information between the WPF application and the UWP background task.
To configure the background task, you need to update the manifest using the manifest designer. Go to the declarations tab, add the background task and configure the entry point as the implementation.

To register the background task in the system, we need to call a Windows 10 API from the WPF application. This API is available in the Windows 10 SDK, and to use it from .NET we need to add the references explained here. Once you have access to the Windows 10 API you can use  the BackgroundTaskRegistration class to configure the background task as shown in the code below:

public void RegisterBackgroundTask(String triggerName)
var current = BackgroundTaskRegistration.AllTasks
.Where(b => b.Value.Name == triggerName).FirstOrDefault().Value;

if (current is null)
BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
builder.Name = triggerName;
builder.SetTrigger(new MaintenanceTrigger(15, false));
builder.TaskEntryPoint = "HttpPing.SiteVerifier";
System.Diagnostics.Debug.WriteLine("BGTask registered:" + triggerName);
System.Diagnostics.Debug.WriteLine("Task already:" + triggerName);

To register the background task, first we make sure the task has not been registered before, and then we use the BackgroundTaskBuilder to configure the name and the Trigger, in this case we are using the MainteinanceTrigger.
2. Register your application as Share Target
Share contracts is a Windows 10 feature that allows the sharing of information between two apps, the sender and the receiver. Thanks to the Desktop Bridge, we can register a UWP application as a Share receiver and then integrate with a Win32 application. Once the app is registered, it will be shown every time the user invokes a share operation as shown below:

In this sample, we are extending a WPF application to become a share target where users can send images from other apps like the Photos app, Edge or even the Shell to our application. We are using the packaging project to include not only the WPF application, but also a UWP application that allows a UWP UI to receive events from the share target. Below you can see the solution explorer with the packaging project referencing the WPF and UWP projects.

The package needs to declare the Share Target, including the name of the UWP application:

When the application gets activated, it receives the share target information from the ShareOperation parameter as shown in the code snippet below:

protected async override void OnNavigatedTo(NavigationEventArgs e)
operation = (ShareOperation)e.Parameter;
if (operation.Data.Contains(StandardDataFormats.StorageItems))
var items = await operation.Data.GetStorageItemsAsync();
file = items[0] as StorageFile;
IRandomAccessStreamWithContentType stream = await file.OpenReadAsync();

await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
BitmapImage image = new BitmapImage();
this.img.Source = image;
await image.SetSourceAsync(stream);

Now every time the user shares a picture and selects our application, the Share UI application gets invoked and the UWP UI will be displayed.

After clicking the “Share to WPF app” button, the UWP will process the event handler, and will copy the picture to the ApplicationData folder and run the Win32 application using the FullTrustProcessLauncher.

private async void ShareBtn_Click(object sender, RoutedEventArgs e)
await file.CopyAsync(ApplicationData.Current.LocalFolder);
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();

To use the FullTrustProcessLauncher we will use the Desktop extension to UWP, this extension is available as an SDK reference available in the Add References dialog of the UWP application:

And finally, register the desktop extension and the target executable in the manifest:

<Package xmlns=""
IgnorableNamespaces="uap mp rescap desktop">
<… >
<desktop:Extension Category="windows.fullTrustProcess"
Executable="WPFPhotoViewerWPFPhotoViewer.exe" />
<… >

3. Enable Office interop from UWP application
One of the key features of the Desktop Bridge is the ability to include Win32 executables on your application package and run those as full trust process from a UWP application. Now, with the Windows Application Packaging project, you can create packages that contain both UWP and Win32 binaries.
Additionally, to the process launcher, the App Service extension will help you to establish a communication channel between your UWP application and the Win32 process.
In this sample we are going to include a Win32 process (a command line application) to manage an Excel worksheet using office interop.
We start with a UWP application that uses the Telerik data grid to show some tabular data, and we will add button to export the same data to Excel as shown in the image below:

The solution explorer of this example looks very similar to our previous example, with three projects in the solution: The UWP application, the Win32 command line and the packaging project with a reference to both projects. However, note that in this case the Application entry point (shown in bold) is the UWP project:

As we did in our previous example, we need to add a reference to the Desktop extension and register the full trust process in the manifest. But this time, we will also register the application service in the package manifest:

To open the communication channel in the Win32 process, we will add a reference to the Windows API as described here:
To establish the connection, we will use the AppServiceConnection class, where we need to specify the package family name of the application we want to connect with, and the event handlers we will use to process the incoming requests.

Connection = new AppServiceConnection();
connection.AppServiceName = "ExcelInteropService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
connection.ServiceClosed += Connection_ServiceClosed;

The new features added to the packaging project in Visual Studio 2017 will help you to modernize your existing desktop applications to get the best from UWP and Win32 in the same package. This new project will help you to configure your package by using the manifest designer, debug your application in the context of the Desktop Bridge and finally, help to create the packages for store submission or sideloading. Here are some resources for more details:
Desktop Bridge docs
Desktop Bridge samples
Windows Application Packaging project samples
App Modernization video on Channel 9
Are you ready to submit your desktop application to the Microsoft Store? Let us know about it here, and we will help you through the process!

The UWP Community Toolkit v2.1

We are extremely excited to announce the latest update to the UWP Community Toolkit, version 2.1!
This update builds on top of the previous version and continues to align the toolkit closer to the Windows 10 Fall Creators Update SDK. Thanks to the continued support and help of the community, all packages have been updated to target the Fall Creators Update, several controls, helpers, and extensions have been added or updated, and the documentation and design time experience have been greatly improved.
Below is a quick list of few of the major updates in this release. Head over to the release notes for a complete overview of what’s new in 2.1.
This release introduces the DockPanel control that provides an easy docking of elements to the left, right, top, bottom or center.

#DockPanel is now part of #UwpToolkit get the pre-release from here thanks to @metulev & @dotMorten for their review
— Ibraheem Osama (@IbraheemOM) November 2, 2017

HeaderedContentControl and HeaderedItemsControl
There are now two controls, HeaderedContentControl and HeaderedItemsControl that allow content to be easily displayed with a header that can be templated.

&lt;controls:HeaderedContentControl Header=&quot;Hello header!&quot;&gt;
&lt;Grid Background=&quot;Gray&quot;&gt;


Connected and Implicit Animation in XAML
There are two new sets of XAML attached properties that enable working with composition animations directly in XAML
Implicit animations (including show and hide) can now be directly added to the elements in XAML

&lt;Border extensions:VisualExtensions.NormalizedCenterPoint=&quot;0.5&quot;&gt;

&lt;animations:TranslationAnimation Duration=&quot;0:0:1&quot;
To=&quot;0, 100, 0&quot; &gt;&lt;/animations:TranslationAnimation&gt;
&lt;animations:OpacityAnimation Duration=&quot;0:0:1&quot;


Connected animations can now be defined directly on the element in XAML by simply adding the same key on elements on different pages

&lt;!– Page 1 –&gt;
&lt;Border x:Name=&quot;Element&quot; animations:Connected.Key=&quot;item&quot;&gt;&lt;/Border&gt;

&lt;!– Page 2 –&gt;
&lt;Border x:Name=&quot;Element&quot; animations:Connected.Key=&quot;item&quot;&gt;&lt;/Border&gt;

Improved design time experience
Added designer support for controls, including toolbox integration and improved design time experience by placing properties in the proper category in the properties grid with hover tooltip.

Added @VisualStudio Toolbox integration to #UWPToolkit: #DragNDropLikeItsHot
— Morten Nielsen (@dotMorten) August 31, 2017

New SystemInformation properties
SystemInformation class now includes new properties and methods to make it easier to provide first run (or related) experiences or collect richer analytics.

The #uwptoolkit got some new SystemInformation properties fresh from the oven thanks to @mrlacey. What would you use these for?
— Nikola Metulev (@metulev) October 13, 2017

Easy transition to new Fall Creators Update controls
To enable a smooth transition from existing toolkit controls to the new Fall Creators Update controls, the HamburgeMenu and SlidableListItem have new properties to use the NavigationView and SwipeControl respectively when running on Fall Creators Update. Take a look at the documentation on how this works.
All documentation is now available at Microsoft docs. In addition, there is new API documentation as part of .NET API Browser.
Built by the Community
This update would not have been possible if it wasn’t for the community support and participation. If you are interested in participating in the development, but don’t know how to get started, check out our “help wanted” issues on GitHub.
As a reminder, although most of the development efforts and usage of the UWP Community Toolkit is for Desktop apps, it also works great on Xbox One, Mobile, HoloLens, IoT and Surface Hub devices. You can get started by following this tutorial, or preview the latest features by installing the UWP Community Toolkit Sample App from the Microsoft Store.
To join the conversation on Twitter, use the #uwptoolkit hashtag.

Windows Application Driver is no longer in Beta!

We’re excited to announce the release of Windows Application Driver (WinAppDriver) version 1.0. This 1.0 release is the first WinAppDriver release without the Beta label. This release is a big milestone for the project which was first introduced during Build 2016 and has been growing in adoption.
What is WinAppDriver
Today, it’s easier than ever to build software for multiple platforms and devices. Microsoft supports any developer working on any platform to build software for any device. We’re showing this support in many tooling investments including .Net, UWP with .Net Standard, Rome, VS Code, Xamarin and WSL. In alignment with this vision we need a test tooling strategy that is equally cross platform and cross device, and that is where WinAppDriver fits in.
WinAppDriver is an open standards based tool for UI Test Automation. You can use WinAppDriver to run Automated UI tests for any application on Windows 10. The support for open standards means if you’ve been running UI Test Automation using Appium or Selenium, you can use your existing tools and preferred languages to write tests for Windows applications.
Version 1.0 Details
This release of WinAppDriver is our first non-Beta for a few reasons:
WinAppDriver now supports the core set of features we initially aspired to back when we launched the project. This doesn’t mean we’re done, but we do feel confident about the supported set of features.
Over the last year we’ve received feedback from the community and been improving WinAppDriver’s performance and quality based on that feedback. Thank you to everyone who participated! A big thank you to the Appium community for including WinAppDriver in the Appium installer.
Removing the Beta label shows we believe strongly in the future of Open Standard based tools and plan to continue to invest in WinAppDriver.
Looking ahead
The WinAppDriver team’s focus is to continue building a feature rich and high performance set of tools for running Automated UI tests on Windows devices. This vision includes enabling support for more Windows devices, test scenarios and tool integrations.
The team is actively working on improvements that include:
Addition to workflows such as Continuous Integration
Multi-touch input support
Pen input support
Bringing WinAppDriver to additional Windows devices
Where can I get it?
You can find the v1.0 installer on the WinAppDriver project’s Github page where we also provide samples, documentation and issue tracking:
The next release of Appium (1.7.2) will install WinAppDriver v1.0 for you if you don’t already have it.
How do I provide feedback?
Please provide feedback on our Github issue board
Stay Informed
To stay up to date with WinAppDriver news follow @mrhassanuz and @yosefdurr.
The v1.0 release of WinAppDriver is a major milestone which no longer has a Beta label.  Please try upgrading to v1.0 as soon as you can. If you haven’t tried WinAppDriver yet, now is a great time.
Thank you from the WinAppDriver Team!