Tag Archives: SDK

For a long time, desktop PC users have been able to configure Win32 apps to start at startup or user log-in. This has also been possible for Desktop Bridge apps since the Windows 10 Anniversary Update (v10.0.14393.0). We’ve now extended this feature to allow regular Universal Windows Apps to take part in this also. This is available in Insider builds from Build 16226 onwards, along with the corresponding SDK. In this post, we’ll look at the code changes you need to make in your manifest and in your App class to handle the startup scenario, and how your app can work with the user to respect their choices.

Here’s a sample app, called TestStartup – the app offers a button to request enabling the startup behavior, and reports current status. Typically, you’d put this kind of option into a settings page of some kind in your app.

The first thing to note is that you must use the windows.startupTask Extension in your app manifest under the Extensions node, which is a child of the Application node. This is documented here. The same Extension declaration is used for both Desktop Bridge and regular UWP apps – but there are some differences.

Desktop Bridge is only available on Desktop, so it uses a Desktop-specific XML namespace. The new UWP implementation is designed for use generally on UWP, so it uses a general UAP namespace (contract version 5) – although to be clear, it is currently still only actually available on Desktop.

The Desktop Bridge EntryPoint must be “Windows.FullTrustApplication,” whereas for regular UWP it is the fully-qualified namespace name of your App class.

Desktop Bridge apps can set the Enabled attribute to true, which means that the app will start at startup without the user having to manually enable it. Conversely, for regular UWP apps this attribute is ignored, and the feature is implicitly set to “disabled.” Instead, the user must first launch the app, and the app must request to be enabled for startup activation.

For Desktop Bridge apps, multiple startupTask Extensions are permitted, each one can use a different Executable. Conversely, for regular UWP apps, you would have only one Executable and one startupTask Extension.

For both Desktop Bridge apps and regular UWP apps, the user is always in control, and can change the Enabled state of your startup app at any time via the Startup tab in Task Manager:

Also for both app types, the app must be launched at least once before the user can change the Disabled/Enabled state. This is potentially slightly confusing: if the user doesn’t launch the app and then tries to change the state to Enabled in Task Manager, this will seem to be set. However, if they then close Task Manager and re-open it, they will see that the state is still Disabled. What’s happening here is that Task Manager is correctly persisting the user’s choice of the Enabled state – but this won’t actually allow the app to be activated at startup unless and until the app is launched at least once first – hence the reason it is reported as Disabled.

In your UWP code, you can request to be enabled for startup. To do this, use the StartupTask.GetAsync method to initialize a StartupTask object (documented here) – passing in the TaskId you specified in the manifest – and then call the RequestEnableAsync method. In the test app, we’re doing this in the Click handler for the button. The return value from the request is the new (possibly unchanged) StartupTaskState.

Because Desktop Bridge apps have a Win32 component, they run with a lot more power than regular UWP apps generally. They can set their StartupTask(s) to be Enabled in the manifest and do not need to call the API. For regular UWP apps, the behavior is more constrained, specifically:

The default is Disabled, so in the normal case, the user must run the app at least once explicitly – this gives the app the opportunity to request to be enabled.

When the app calls RequestEnableAsync, this will show a user-prompt dialog for UWP apps (or if called from a UWP component in a Desktop Bridge app from the Windows 10 Fall Creators Update onwards).

StartupTask includes a Disable method. If the state is Enabled, the app can use the API to set it to Disabled. If the app then subsequently requests to enable again, this will also trigger the user prompt.

If the user disables (either via the user prompt, or via the Task Manager Startup tab), then the prompt is not shown again, regardless of any requests from the app. The app can of course devise its own user prompts, asking the user to make manual changes in Task Manager – but if the user has explicitly disabled your startup, you should probably respect their decision and stop pestering them. In the sample code above, the app is responding to DisabledByUser by popping its own message dialog – you can obviously do this if you want, but it should be emphasized that there’s a risk you’ll just annoy the user.

If the feature is disabled by local admin or group policy, then the user prompt is not shown, and startup cannot be enabled. The existing StartupTaskState enum has been extended with a new value, DisabledByPolicy. When the app sees DisabledByPolicy, it should avoid re-requesting that their task be enabled, because the request will never be approved until the policy changes.

Platforms other than Desktop that don’t support startup tasks also report DisabledByPolicy.

Where a request triggers a user-consent prompt (UWP apps only), the message includes the DisplayName you specified in your manifest. This prompt is not shown if the state is DisabledByUser or DisabledByPolicy.

If your app is enabled for startup activation, you should handle this case in your App class by overriding the OnActivated method. Check the IActivatedEventArgs.Kind to see if it is ActivationKind.StartupTask, and if so, case the IActivatedEventArgs to a StartupTaskActivatedEventArgs. From this, you can retrieve the TaskId, should you need it. In this test app, we’re simply passing on the ActivationKind as a string to MainPage.

Note that when your app starts at startup, it will start minimized in the taskbar. In this test app, when brought to normal window mode, the app reports the ActivationKind and StartupTaskState:

Using the windows.startupTask manifest Extension and the StartupTask.RequestEnableAsync API, your app can be configured to start at user log-in. This can be useful for apps which the user expects to use heavily, and the user has control over this – but it is still a feature that you should use carefully. You should not use the feature if you don’t reasonably expect the user to want it for your app – and you should avoid repeatedly prompting them once they’ve made their choice. The inclusion of a user-prompt puts the user firmly in control, which is an improvement over the older Win32 model.

For some apps (especially games) it is not uncommon for the app to get into a state where it needs to restart – perhaps after a license update, after installing downloadable content, its caches have become corrupt or unwieldy, or for any other reason where the app needs to refresh state from scratch. In earlier releases, your only option would have been to prompt the user to close and relaunch, or to call CoreApplication.Exit – and both options provide sub-optimal user experience.

We have therefore introduced a new API that enables an app to request immediate termination and restart, and to pass arbitrary arguments into the fresh instance. In this post, we’ll look at how this works and how you can build it into your app. This is available now in Insider builds from Build 16226 onwards, along with the corresponding SDK.

Here’s a sample app, called TestRestart.

The app provides a ListView of cities on the left, the currently-selected city on the right and a TextBox for providing arguments to the app when it is restarted. When the user taps the Request Restart button, the app will terminate and restart itself, passing in the supplied arguments. The new API, RequestRestartAsync, is exposed as a static method on the CoreApplication object. It takes a string parameter, which can be any string value you like – including input from the user or another external entity. If you do choose to accept input in this way, it is your responsibility to validate it correctly to make sure it conforms to whatever constraints you choose to impose. You should do this validation on input, before passing it to RequestRestartAsync. In this sample app, we’re expecting the user to type in the name of a city.

To mitigate privacy concerns, an app is only permitted to restart itself if it is in the foreground at the time it makes the request. When the app restarts, it restarts with normal UI – that is, as a normal foreground window. If we were to permit a background task or minimized app to restart, the result would be unexpected to the user. This is why the API is framed as a request. If the request is denied, the app would need to handle the failure – perhaps by waiting until it is in the foreground and trying again. If you were to request a restart and then through some twist of logic managed to request it again before the system started the operation, then you’d get the RestartPending result, although this is an edge case. You’re unlikely to ever get the other result – unless something goes wrong in the platform.

Note that this is the only significant constraint, but you should use this API carefully. For example, you probably should not use it if your app was not originally launched by the user – for example, if it was launched as the result of a share or picker operation. Restarting in the middle of one of those contract operations would certainly confuse the user.

If the request is granted, the app is terminated and then restarted. There are many different ways to activate an app: in addition to a regular launch activation, apps can choose to support file activation, protocol activation, share or picker activation and so on. The list is documented here. For the restart case, the app will be activated as a regular launch – just as if the user had closed the app manually and tapped its tile to launch it again – but including the arbitrary arguments supplied earlier (if any).

In your App class, you should handle this by overriding the OnActivated method. Test the ActivationKind, and if it’s ActivationKind.Launch, then the incoming IActivatedEventArgs will be a LaunchActivatedEventArgs. From this, you can get hold of the incoming activation arguments. For a regular user-initiated launch, the Arguments will be empty, so if it’s not empty you could simply infer that this is a restart activation. You can also check the PreviousExecutionState, which for a restart operation will be set to Terminated.

Although the arguments might have originated from an untrusted source (eg, the user), you should have done the validation before requesting restart. If so, you can consider them trustworthy when you receive them in OnActivated.

What you do with the incoming arguments is entirely up to you. In this app, we’re simply passing them on to the MainPage. In the MainPage in turn, we have an override of OnNavigatedTo which uses the string to select an item in the ListView:

As you can see, the CoreApplication.RequestRestartAsync method is a simple API. You can use it to terminate your app immediately, and have it restart as if by user action, with the additional option of passing in arbitrary arguments on activation.

Kevin Gallo will be live on Channel 9 with Seth Juarez on July 26th, 2017 at 9:30am PST. Kevin will be providing updates to the state of the Windows SDK inside Windows 10 Falls Creators Update since everyone last chatted with him at Microsoft Build 2017. As always, we’ll be answering live questions afterwards.

A few of the topics Kevin and Seth will be discussing are the Windows 10 Fall Creators Update SDK, .NET Standard 2.0, Fluent Design, Microsoft Graph with the Activity API and more.

Over time, we’ll hold more frequent community standups to provide additional transparency on what we are building out, and clarity on why we are building them. The community standups will not only be with just Kevin, but the entire Windows development team as well. We’ll be testing different streaming technologies and interaction models to see what works best. We would love feedback on this as well.

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 16232 or greater). The Preview SDK Build 16232 contains bug fixes and under development changes to the API surface area.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

Known Issues

Designer fails to render: When viewing the XAML in the Designer Window in Visual Studio, the controls fail to render. This can be resolved by using Visual Studio 2017.3 Preview.

Compilation fails on non-Windows 10 platformsWhen building apps on previous platforms, you may get a build error:

This will occur if the minimum target platform version is set to 10.0.16225.0. To work around this, right click on your project file and choose properties or open your project file in your favorite editor, and change the version to a previous released SDK. For example:

Breaking Changes

ecmangen.exe removal from the SDK: Ecmangen.exe will no longer ship with the Windows SDK. Developers who rely on ecmangen for event manifest creation are advised to install the Windows Creators Edition of the SDK to obtain the file. Developers may also use notepad or other XML editor of choice for manifest creation. A schema file is available on MSDN to aid in manifest creation, for tools that support it.

At Build this year, we gave a sneak preview of a set of new APIs designed to provide diagnostic information about running apps. You can see the videos here and here – but note that these were based on a pre-release implementation. So, while the Build videos are still correct on broad functionality, the final API names are almost all slightly different. Plus, we added a couple of extra features after Build.

The final versions for the upcoming release are available in the Insider builds from Build 16226, along with the corresponding SDK.

At a high level, these APIs allow an app to:

Enumerate a list of running apps, including UWP apps, Win32 apps, system services and so on.

For each app, get process-specific metrics on:

Memory usage (private commit and working set).

CPU usage.

Disk reads and writes.

For each UWP app, get additional metrics on:

Memory usage (including shared commit) equivalent to the Windows.System.MemoryManager report previously available to an app for its own usage.

State info: running, suspending, suspended, not running.

Energy quota info: under or over.

Enumerate a list of any background tasks that are active for the app, including name, trigger type and entry point.

Enumerate all the processes for the app (using an enhancement to the existing Windows.System.Diagnostics.ProcessDiagnosticInfo class that was previously restricted to an app for its own usage).

The API has a simple hierarchical structure:

The AppDiagnosticInfo type represents a single app. Callers would normally request either a single AppDiagnosticInfo for the app you’re interested in or a list of AppDiagnosticInfos if you’re interested in multiple apps.

Once you’ve gotten hold of an AppDiagnosticInfo for an app you’re interested in, you’d call GetResourceGroups to get a list of AppResourceGroupInfo objects. Each AppResourceGroupInfo corresponds to a resource group. An app can define resource groups in its manifest as a way to organize its components (foreground app, background tasks) into groups for resource management purposes. If you don’t define any explicit resource groups, the system will provide at least one (for the foreground app) plus potentially more (if you have out-of-proc background tasks, for example).

From there, you’d call any of the AppResourceGroupInfo methods to get snapshot reports of memory usage, execution and energy quota state, and the app’s running background tasks (if any) via the AppResourceGroupMemoryReport, AppResourceGroupStateReport and AppResourceGroupBackgroundTaskReport classes.

And finally, each group exposes a list of ProcessDiagnosticInfo objects.

As you can see from the class diagrams, the AppDiagnosticInfo and ProcessDiagnosticInfo each have a link to the other. This means you can get all the rich process-specific info for any running process and get the UWP-specific info for any process related to a UWP app (including Desktop Bridge apps).

These APIs are intended to support app developers who either need more diagnostic support during their own app development and testing, or who want to build a general-purpose diagnostic app and publish it in the Windows Store. Exposing information about other apps raises potential privacy concerns, so if your app uses these APIs, you’ll need to declare the appDiagnostics capability in your manifest, along with the corresponding namespace declaration:

This is a restricted capability: If you submit an app with this capability to the Windows Store, this will trigger closer scrutiny. The app must be in the Developer Tools category, and we will examine your app to make sure that it is indeed a developer tool before approving the submission.

At run time, the capability also triggers a user-consent prompt the first time any of the diagnostic APIs are called:

The user is always in control: If permission is denied, then the APIs will only return information about the current app. The prompt is only shown on first use, but the user can change his or her mind any time via the privacy pages in Settings. All apps that use the APIs will be listed here, and the user can toggle permission either globally or on a per-app basis:

Given the richness of the APIs, it’s not too much of a stretch to envisage creating a UWP version of Task Manager. There are a few features that we can’t implement just yet (terminating apps and controlling system services, for example), but certainly most of the data reporting is perfectly possible with the new APIs:

The first thing to do is to request permission to access diagnostics for other apps using AppDiagnosticInfo.RequestAccessAsync. The result could be Denied, Limited (which means you can only get information for the current app package) or Allowed.

For each running process, you can extract the top-level process-specific information such as the ExecutableFileName and the ProcessId. You can also get the more detailed process information from each of the three reports for CpuUsage, MemoryUsage and DiskUsage.

For any process associated with a UWP app, the IsPackaged property is true. So, for each of these, you can get from the ProcessDiagnosticInfo to the AppDiagnosticInfo. It might seem strange that we can get AppDiagnosticInfos (plural) from a process – but this is to allow for the possibility that a single process is associated with more than one app. That’s an extremely uncommon scenario, but it is possible in the case of VoIP apps where two or more apps in the same package can share a component running in a separate process at run time. In almost all cases, though, there will only be one AppDiagnosticInfo per process.

From the AppDiagnosticInfo, you can walk down the hierarchy and get a collection of AppResourceGroupInfos. Then, for each AppResourceGroupInfo, you can get the UWP-specific state and memory information:

Note: to get the packaged logo from the app, there’s a little extra work. You call GetLogo from the AppDisplayInfo to return the data as a stream; if there are multiple logos available, this will return the largest one that is within the specified size.

Once you’ve collected all the various detailed metrics you’re interested in, it’s a simple matter to populate your viewmodel for data-binding purposes, to perform data analytics or to do whatever other processing you might want.

In a later post, we’ll look at how you can integrate the diagnostic APIs with existing developer tools such as Visual Studio and Appium.

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 16225 or greater). The Preview SDK Build 16225 contains bug fixes and under development changes to the API surface area.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

Known Issues

Designer fails to render: When viewing the XAML in the Designer Window in Visual Studio, the controls fail to render. This can be resolved by using Visual Studio 2017.3 Preview.

Compilation fails on non-Windows 10 platforms: When building apps on previous platforms, you may get a build error:

This will occur if the minimum target platform version is set to 10.0.16225.0. To work around this, right click on your project file and choose properties or open your project file in your favorite editor, and change the version to a previous released SDK. For example:

Windows Ink is about transforming the way we think about computers, from a tool that is great at getting things done, to one that harnesses your personality and your emotions into the things you create. It’s about bringing back the human aspects that a mouse and keyboard (and even touch) cannot express fully, it’s about making personal computers more personal, and an extension of yourself, not just a tool. We want you to feel empowered to create from the moment you pick up the pen, and have the confidence that Windows understands you, knows what you want to do – by understanding your handwriting, your words and your expression. This is the journey we’re on.

With the Creators Update, Windows Ink is now better than ever! When used with the Surface Dial, it allows you to discover new ways to work and interact with Windows. With Windows Ink, we continue to make it possible for you to do more than with pen and paper. Applications like Photos and Maps have added incredible inking functionality in the last year, and continue to evolve and expand. With Paint 3D in the Creators Update, Windows Ink can now create 3D objects! As we evolve what Ink means to users, we’re also introducing new Smart Ink capabilities to Windows Ink. These capabilities allows developers to understand the ink that is being laid down by the user, using AI to help create, connect and complete user actions on ink. We’ve also improved and added features to the building blocks for Windows Ink, introducing new stencils and adding tilt support to create a richer drawing experience.

Devices that support the Pen on Windows have also doubled in the last year, and is on track to double again in the next year! We’re seeing high demand not just for devices, but also for applications that support ink. To make it easier to find compatible pens, Wacom has partnered with us to develop the Bamboo Ink Pen. This pen will be in market in summer and supports almost all Windows PCs that are pen-capable. It features the Microsoft Pen Protocol (MPP), which is based on Surface Pen technology. In addition, we are also excited that the Surface Dial is now available in more countries, like Australia, Canada and New Zealand, giving more people an opportunity to try this incredible new input device. In addition, new hardware from our OEM partners, like the Dell Canvas 27, are shipping soon and takes advantage of the same RadialController APIs that are used for the dial. As a developer building for the Surface Dial today, it means that you are ready for all the new hardware that our OEM partners will bring to the ecosystem.

The progress we’ve made with Windows Ink would not have been possible without the feedback and passion you developers bring to us. With over a thousand inking applications in the store and growing everyday, with well over half of the top 10 paid store apps being ink apps, there is incredible enthusiasm and interest in this space. This is an incredible opportunity that you have embraced with us, and it inspires us to do more in each Windows release.

What’s new with Windows Ink platform?

Ink is the ultimate way humans can express themselves, it opens up new opportunities for application developers to differentiate, and helps make their applications stand out. From the latest fads like adult coloring books to simple games like tic-tac-toe, to applications that help you organize your life, there is just so much opportunity to build the next big thing in the inking space. We also know that people who use Windows Ink are more satisfied with their experience, what they look for, and buy more inking applications. From the platform perspective, we have 2 ways that we help developers:

Make it as easy and quick for a developer to add inking into their application by providing controls that can be dropped in quickly into any application and get Windows Ink support.

Provide the most flexible platform building blocks for developers to innovate upon. This gives you the flexibility to choose where to start developing for Windows Ink.

Introducing Smart Ink

Let’s start with a new building block that developers have access to in the Creators Update. Introducing Ink Analysis, this is the first of our family of Smart Ink capabilities that we are bringing to the platform. Smart Ink brings AI technology to not just understand what you write, but also helps connect the dots to what you may want to do. With Ink Analysis, it starts simple, with recognizing shapes and making that square you drew more perfect, but it can also do much more, like understanding you wrote words in squares and making it into an org chart using understanding about your organization. Our goal is to understand user intent and empower developers to turn it into rich digital constructs, as well as to leverage understanding from all parts of the system. Ink Analysis allows any developer to understand the ink they capture, whether it is handwriting, shapes, phone numbers, stock symbols, lists, document structure and more. This is the same technology we debuted in Sticky Notes in the Window 10 Anniversary Update, and now it’s available for you to use! We can’t wait to see what you can do with this technology.

Here is an example of how to use Ink Analysis to recognize shapes. For this snippet, we’ll use DirectInk to handle rendering the ink strokes. Start by initializing an InkAnalyzer and connecting it with InkPresenter:

Next you want to feed strokes to the analyzer. Commonly this is done via explicit user action (e.g. the user clicks a button) or after the user has been idle for a while.

inkAnalyzer.AnalyzeAsync();

The result is a tree representation of the whole document with different kinds of nodes, such as paragraph, line, list, word, and drawing. If for instance you want to find all the shapes in the ink, you can with the code below:

Many of Microsoft’s first party applications have incorporated the inking tools to create engaging user experiences. For example, Photos added a calligraphy pen and the ability to draw on any photo in the gallery. Maps added a feature that lets you measure the distance of a route drawn on the map. Edge browser added inking on webpages. It has never been easier to add Windows Ink to your applications.

In the Creators Update, we continue our commitment to improving these controls! If you already use them in your applications, these improvements will benefit you with no additional work!

In response to users, the Creators Update introduces a new stencil, the protractor. This new stencil makes it easy for you to draw circles and arcs of any size. When drawing an arc, the protractor displays a readout that tells you the precise angle of the arc. You can also resize the stencil with just a pinch/zoom gesture with your fingers.

We’ve also made the ruler stencil better! Like the protractor, it now provides an angle readout that shows the ruler’s angle with the horizontal line. The ruler also snaps to 0, 45 and 90 degrees for easy access to the most common angles being used by our users.

You asked for an improve stroke preview in the Ink Toolbar, and in the Creators Update, we have it! We’re also make changes in the Ink Toolbar to work better with High Contrast themes, by automatically showing only colors that meet visibility requirements for the current user profile.

New Exciting Inking Capabilities

Today we announced the new Surface Pro and the new Surface Pen. Together they enable the next generation of inking capabilities that truly make writing digitally as natural as pen on paper. Here are some of the highlights:

Low latency Ink that virtually eliminates lag when you write

Tilt support to capture an additional dimension in digital inking

Ink that captures the entire spectrum of your expression with 4,096 levels of pressure sensitivity

Effortless inking with half the activation force required to being inking

Our customers have asked us for these capabilities, and they are finally here! From a developer perspective, if you already use the Windows Ink platform, all these capabilities show up in your application automatically! There are no changes required, and you are ready for the new Surface Pro, with the new Surface Pen.

Low latency Inking is a unique addition to Windows Ink. It is the result of a close partnership between hardware and software. The Pixelsense Accelerator chip in the new Surface Pro, is the first device to run Windows Ink acceleration code natively on hardware. This is how we achieve a new milestone in inking, virtually eliminating lag between the pen tip and the ink that flows out of it, creating the most natural writing experience with Windows Ink.

Tilt is another great addition to the Inking experience. The great news is, in addition to the new Surface Pro/Pen supporting this new capability, Wacom Pens that feature tilt will also “just work”! Tilt allows Windows Ink to model natural pencil sketching that response to the tilt of the pen. This support is now built into the pencil brush on the Ink Toolbar. In the above diagrams, we demonstrate how the pencil brush can be used to shade lines (on the left) and to draw arcs of varying thickness depending on the degree of tilt (on the right).

As mentioned above, tilt integration happens automatically if you use the Ink Toolbar. However, if you are not using the Windows Ink platform to render ink, and want to build your own brush that responds to tilt, you still can! There are two properties, TiltX and TiltY (respective angle of tilt against each axis of the screen plane) which are included with pointer input messages. You can access the tilt values from the PointerPointProperties included with Pointer input events, or the POINTER_PEN_INFO struct from WM_POINTER input.

These improvements automatically show up on any application that uses the Windows Ink controls, and you can be confident that we’ll continue to evolve and improve them in each release of Windows.

What’s new with Surface Dial and RadialController?

The Surface Dial introduces a new input paradigm to computing. It was designed alongside the Windows Ink experience, allowing it to truly shine when used together with a Pen. We’ve seen many experiences built to harness the new capabilities the Surface Dial brings, and are also seeing new hardware emerging, and adopting the RadialController standard. In response to your feedback, we’ve added more capabilities to the RadialController experience in the Creators Update.

First off, are some new button events for RadialControllers. These new events, Pressed and Released, combined with existing events for rotation and screen contact, will allow you to track complex interactions such as press-and-rotate or press-and-move. The example below illustrates a simple way to capture a press-and-rotate action.

You also now have access to the Haptics engine in the Surface Dial hardware. Using SimpleHapticsController—a new object that uses the HID Simple Haptics specification—you have the power to directly send feedback to the user. You can use this to customize the feel of your menu, adding a new dimension to the experience. This object is available in the arguments of all radial controller input events.

In cases where you may want to suppress the radial menu to prevent it from blocking UI, we now have new properties ActiveControllerWhenMenuIsSuppressed and IsMenuSuppressed to let you configure when the menu is available or suppressed. When a menu is suppressed, it will not appear on press-and-hold interactions for the foreground app. Your app can listen to a new event during menu suppression to give the user an indication the menu is blocked, or build an alternate experience. Here is a code sample for this functionality:

User input running on a UI thread can sometimes lead to performance bottlenecks. With the Creator’s Update, radial controller interactions can now be handled on an off-UI thread using RadialControllerIndependentInputSource. Below is an example on how to get additional performance using this method.

In addition to all the API additions above, you can now customize and easily add new menu items on the Radial Menu. Under “Wheel Settings” in the settings app, you can add application specific menu items that trigger keyboard combinations. Imagine customizing the controller to send your favorite shortcuts in Visual Studio, Photoshop or even when browsing the web!

The Surface Dial continues to excite users and developers alike, with these new enhancements, both developers and users have more control and flexibility in their experience. We invite you to join the numerous applications that have already delivered a great Surface Dial experience, like CorelDRAW, Autodesk’s SketchBook, Silicon Bender’s Sketchable and Algoriddim’s djay Pro. We can’t wait to see what you can do with this unique new form of input on Windows.

Join us in making Windows Ink better!

With Windows Ink and the Surface Dial additions in the Creators Update, we believe we’re just scratching the surface of what Windows Ink can do in people’s lives. Our commitment is to invest in areas that can help you innovate and remove all the barriers to our users using, loving and needing Windows Ink. This involves a spectrum of efforts, from the hardware we build by ourselves and with our partners, to the next SDK additions we make to power you app. As we continue this journey, we invite you to lend us your voice, your ideas and your feedback. Help us help you make the next great application and help us help you change the world. Tweet your ideas using #WindowsInk, email us at WindowsInk@Microsoft.com or tweet us at @WindowsInk. We would love to hear from all of you.

Make sure your apps are updated to use the latest versions of the Microsoft Advertising SDK.

The latest advertising SDK versions, which are MRAID 1.0 compliant, support richer creatives experiences. These SDK versions can also send user signals such as advertiser ID, age, gender, geo and other behavioral signals to advertisers (subject to user’s privacy preferences). This enables advertisers to identify the same user across different apps and websites, and as a result can target them better.

Advertisers today seek these capabilities and are willing to spend more money on ad inventory that supports them, so this will translate into higher revenue for you.

The latest Advertising SDK versions for UWP apps also support new ad formats like Interstitial Banner, Native Ads and Playable Ads, which deliver higher eCPMs and can drive up your revenue even further!

Today, we released a new Windows 10 Preview Build of the SDK to be used in conjunction with Windows 10 Insider Preview (Build 16190 or greater). The Preview SDK Build 16190 contains bug fixes and under development changes to the API surface area.

Things to note:

This build works in conjunction with previously released SDKs and Visual Studio 2017. You can install this SDK and still also continue to submit your apps that target Windows 10 Creators build or earlier to the store.

The Windows SDK will now formally only be supported by Visual Studio 2017 and greater. You can download the Visual Studio 2017 here.

What’s New

This release of the Windows 10 SDK Preview Build, we have introduced the following new controls: NavigationView, TreeView, RatingsControl, ColorPicker, ParallaxView and PersonPicture to the Windows.UI.XAML.Controls namespace. It also adds brushes for Acrylic and Reveal, part of the Fluent Design System. See also the new XAML Controls Gallery in the Windows Universal Samples collection.

See API Updates and Additions for additional APIs.

Known Issue

Failed to compile WRL projects due to missing WindowsContracts.h

When building WRL projects, your code may fail to compile due to a missing file: WindowsContracts.h. This will be addressed in the next update. To work around this, create an empty header file: WindowsContracts.H and include it in your include Search path.

Breaking Changes

WinRT type header generation moving from MIDL to MIDLRT

Header generation for WinRT types is moving from being generated by the MIDL tool to the MIDLRT tool. This change will enable significant performance enhancements and will also enable a number of new features.

The most common issue developers are likely to encounter is the addition of deprecation support to the generated WinRT headers. With this change, if you consume a deprecated API, the C++ compiler will now generate a warning indicating that your code is accessing a deprecated type.

Consider the following when evaluating how your code will be impacted:

The WinMDIDL tool used to emit cpp_quote directives to work around a MIDL header generation limitation. Those cpp_quote directives are incompatible with the new header generation logic and need to be removed (or the IDL file needs to be regenerated).

WinRT types that are marked as [deprecated] are now also marked as [[deprecated]] in the generated C++ headers. This means that you may encounter C4996 warnings indicating that you are accessing a deprecated type. To resolve this issue, you can define DISABLE_WINRT_DEPRECATION in the preprocessor definitions for your project to ignore the deprecations.

Windows Runtime enumeration definitions are now compliant with C++ standard

To further align Visual C++ with the ISO standard for C++, enumerations for Windows Runtime types are now standards-compliant. If you develop software with the Windows 10 SDK, this change might affect you.

Specifically, variables in operations with enumerations that are marked as flags must be cast as unsigned integers. An operation that uses a signed integer with an enumeration constant will result in a compiler error, because enumeration constants are now unsigned integers. The affected enumerations are flags enumerations supplied by the SDK and enumerations that you cast with the [flags] attribute.

It was an amazing day today at Build 2017. With the Windows 10 Fall Creators Update, we continue to grow the Windows platform so that Windows is home for all developers. As I reflect on the day, I want to highlight how Windows and VS are creating the best end-to-end development process and enabling developers not only to maximize their code reuse, but also to create experiences that are engaging, powered by intelligence and connected across devices.

.NET Development Improvements

With today’s announcement that .NET Standard 2.0 for UWP and XAML Standard will be coming later this year, .NET is now the most complete cross-platform development framework. This combination, along with Visual Studio, makes it easier than ever before to write fully native and full-featured apps for all your target platforms in C#, including Windows, iOS, Android, Linux and, of course, the cloud!

.NET Standard 2.0 and XAML Standard

.NET Standard 2.0 is expanding the UWP surface by over 20,000 APIs to make sure your code is more interoperable than ever. We also know that about 70% of NuGet packages are API compatible with .NET Standard 2.0. Your most requested APIs for UWP, such as Reflection and SqlClient, will be fully accessible to you from the Windows 10 Fall Creators Update. In addition, XAML Standard allows you to keep much of your UI code common and still maintain a native look and feel across Windows, iOS, and Android. Your experience on Windows will automatically provide Fluent UI and all input interaction models for free. Our goal is to unify our XAML dialects across UWP XAML and Xamarin Forms, making cross platform development easier than ever. We encourage you to give us direct feedback in the GitHub repo – http://aka.ms/xamlstandard.

Microsoft Graph and Creating Connected Experiences

We are connecting Windows to the Microsoft Graph, enabling amazing new Windows shell features such as Timeline, Cloud Clipboard, and Pick up Where I Left Off (PWILO). And you can use the same APIs to enhance your own applications too.

Devices in the Microsoft Graph

Using the Microsoft Graph API, you can now access your all of your users’ devices, enabling you to break down boundaries between devices. You can call apps and app services on each device, allowing for cross-device coordination of experiences.

Activities in the Microsoft Graph

Starting with the Windows Fall Creators Update, we are releasing the UserActivity APIs, enabling you to drive engagement in your apps, across devices and platforms. A UserActivity is the unit of user engagement in Windows, and consists of three components: a deep-link, visuals, and metadata. When a UserActivity session is created by an application, it accrues engagement records as users interact with the application.

Adaptive Cards

Activities in the Microsoft Graph provide a great way to store and track your activity across all your devices. Being able to visualize those activities is a critical part of the experience your customers will expect. Adaptive cards provide developers a visualization, using an open format, that works across multiple applications and experiences. The visualization for all the activities in the Timeline is provided by attaching an adaptive card to the activity using the Project Rome APIs. Adaptive cards are based on a JSON schema that enables app/content providers to have a rich visualization surface that can be represented in numerous experiences. The experience that hosts the card has control over exactly how the card is represented so that the card feels like a natural extension of the UI of the host app.

Microsoft Fluent Design System

With the Fluent design system, we are taking a significant step forward in re-envisioning the way we develop the next generation of apps and experiences that translate seamlessly and naturally across devices. Our world is increasingly being driven by multiple devices – phones, tablets, PCs, game consoles, mixed reality headsets, etc. We don’t use just one device, we use many, and we’re constantly expressing ourselves by creating and consuming content across them. Each of these devices behaves differently and fulfills different needs. Some rely on touch and ink, some read our voices and gestures. It’s because of this world we live in today that Microsoft is making a big investment in our design system.

Fluent Design enables the creation of more expressive and engaging experiences that work continuously across devices—from large screens, to small screens, to no screen—all in a way that will drive higher engagement and love for your apps. There are 5 fundamentals to Fluid design system – light, depth, motion, materials and scale. All of these join together in concert to give us the capabilities to build immersive, rich apps that scale continuously across the device ecosystem:

Light – Light helps enable the ability to draw someone’s attention, or more clearly guide them through their navigations

Depth – Depth helps us understand how things relate to each other when they’re within a more layered, physical environment

Motion – Motion is a powerful way to establish context and imply relationships between content in natural, subtle and delightful ways

Material – Material can help take full advantage of the available screen space to celebrate content. It can also bring a sense of lightweight, ephemeral user experience

Scale – Scale allows us expand our toolbox for more dimensions, inviting innovation across new device form factors

Test, Deploy and Manage More Quickly

Testing and a secure deployment system is critical, so I’m particularly excited by Visual Studio Mobile Center, which allows you to have a CI/CD pipeline for UWP (in addition to iOS and Android) and integrates with our Store to make publication and distribution of your apps a breeze! We are also adding Windows devices to our test cloud, to enable developers to see how the app will look on the various devices and to help find issues before publishing.

Windows is the ultimate dev box

Our ambition is to make Windows the best dev box – for any dev, writing any app, targeting any platform.

Last year at build, I announced that bash was coming to Windows through the Windows Subsystem for Linux. We heard your feedback that deployment was a bit challenging, so we are streamlining deployment to come directly from the Windows store. In addition, we are working with Suse and Fedora Linux to enable multiple Linux distributions to run simultaneously. On top of these additional distros, there are loads of improvements under the hood, such as USB device communications support (e.g. deploy your Raspberry Pi bits via USB from Bash), USB drive mounting (for FAT32/exFAT/NTFS formatted USB drives), network share mounting, improved network configuration sync between Windows and Linux, and deeper syscalls to improve the breadth and depth of WSL’s compatibility with Linux apps.

In addition, there’s now the Xamarin Live Player which allows you to deploy, run, test and debug iOS apps directly from a Windows PC. Never before have you been able to build for so many platforms on one dev box!

Finally, I love seeing what our developer community can create, and the amazing experiences you are bringing to Windows. Just a couple of days ago I had the opportunity to celebrate with some of you our first windows developer awards: