Today at Build, we announced the release of Visual Studio 2017 version 15.7 and the first preview of the next update, Visual Studio 2017 version 15.8 Preview 1. If you would rather try these without installing them, check out the Visual Studio images in Azure that will be available soon.

Before digging in, I’d like to call out other Visual Studio and .NET news:

• We have a generally available release of Visual Studio 2017 for Mac version 7.5, our IDE for cloud, mobile, and game development on macOS.
• We have a release candidate for .NET Core 2.1, our cross-platform, open source .NET implementation.
• We published the .NET Core 3 roadmap; .NET Core 3 is the next major version of .NET Core and includes support for WPF, Windows Forms, and UWP on Windows.
• We have a generally available release of Xamarin.Forms 3.0 for productive mobile development

There are also two really interesting previews I’d call your attention to:

• We have a public preview of Visual Studio Live Share, our real-time collaboration system for developers
• We have a private preview of Visual Studio IntelliCode, our new AI-assisted development capabilities

We will publish blog entries on these soon, and as we do we’ll update this post with the links.

There is a lot we have accomplished in this release and I’ll share the highlights in this post. It is a long post, so grab a cup of your preferred warm beverage and read on. For the complete list of all the updates in today’s releases, check out the Visual Studio 2017 version 15.7 release notes and list of bugs submitted by you that are fixed.

Installer Updates

One of the first things you’ll probably notice is a nice change to the way updates work. You can now initiate a check for updates (Help -> Check for Updates) and, after you save your work and choose “Update Now,” Visual Studio will automatically apply the update and reopen where you left off.

Starting with this release, you can reduce the installation footprint on your system drive by directing the download cache, shared components, and some SDKs and tools to separate locations. Because these pieces are shared among Visual Studio installations, you can only set the locations with your first installation, meaning that you can’t change them later. If you have a solid-state drive (SSD), we recommend that you install the Visual Studio core product on your SSD because this will make Visual Studio run significantly faster.

Performance Improvements

We’ve done a lot of work on Visual Studio performance during the Visual Studio 2017 cycle, particularly things like solution load (see this post for some of the most recent improvements), but we’re making continual improvements. Here are a few other improvements to performance in this update.

UI Responsiveness: One change that will improve general UI responsiveness in version 15.7 is that the debugging windows are now asynchronous. This means that they will no longer block Visual Studio as they do work. This change will allow for faster stepping because you can continue interacting with Visual Studio without interruption.

.NET mobile performance improvements: Visual Studio will boot and deploy the Xamarin runtime on your device while a compile is taking place. This reduces the time that you have to wait to see your app show up. With our test app, on a fresh device and no previous deployment, including launching the Android emulator, we see performance gains ranging between 33% to 300% depending on the scenario.

TypeScript Performance: We’ve made background analysis of closed files optional (“Only report diagnostics for files opened in the editor” under Tools > Options > TextEditor > JavaScript/TypeScript / Project).

Editor Productivity Improvements

With each release, we add capabilities that improve developer productivity, particularly focusing on that “inner loop” of editing, building, and debugging.

.NET Refactorings and Navigation: Every release, we increase the number of refactorings and improve navigation for our managed languages. In Visual Studio 2017 version 15.7 we added the following refactorings:

• Toggle between foreach loop and for-loop (C# and Visual Basic)
• Make private field read only (C# and Visual Basic)
• Convert LINQ query expression into a foreach loop (C#)
• Convert implicit type to explicit type (C#)

We also enabled Go To Definition (F12 or Ctrl+Click) in more scenarios, like on LINQ query clauses, deconstructions, and on the ‘override’ keyword (to navigate to base).

XAML IntelliSense: The XAML editor now provides IntelliSense for authoring conditional XAML. When using a type that is not present in the target-minimum version of your app, the XAML editor now not only warns but also provides several options to fix it. The quick fix Lightbulb figures out the right conditional using statement based on the platform version where the type was first introduced, allowing the app to target a wider range of platform versions while being able to consume the latest controls.

Xamarin.Forms XAML Editing Improvements: If you use Xamarin.Forms in Visual Studio 2017 version 15.7 you will notice a vastly improved IntelliSense experience when editing XAML. The Xamarin.Forms XAML editing experience is now powered by the same engine that powers WPF and UWP. This brings many enhancements including improved matching, Lightbulb suggestions, code navigation, error checking, resource completion, and markup extension completion.

TypeScript Editing and TypeScript 2.8: Visual Studio 2017 version 15.7 will include TypeScript 2.8. We’ve continued our push to help make TypeScript and JavaScript developers more productive by adding support for fixing all occurrences of a problem in a document (for example, removing unused variables), organizing imports (including sorting and removing unused declarations), and displaying the lightbulb more proactively when optional improvements are possible. We’ve also fixed some of the top issues that you have raised, including premature triggering of snippets, un-cancellable refactorings, hard-to-disable formatting, and incorrect TypeScript version selection. These improvements are powered by TypeScript 2.8, so for the best experience, we recommend updating your existing projects to use the latest TypeScript version.

C++ ClangFormat: We’ve added ClangFormat support for C++ developers in the IDE. Like with EditorConfig, you can use ClangFormat to automatically style and format your code as you type, in a way that can be enforced across your development team. For more information, see the ClangFormat Support blog post.

C++ CMake: This release of Visual Studio includes features to make it easier than ever to use CMake without needing to generate projects and Solutions. The new CMake CMake Targets View provides an alternative way to view a CMake project’s source in the Solution Explorer; instead of a folder-based view, it organizes the code into individual CMake targets. Additionally, CMake projects now support single file compilation and static analysis of C++ code, without the need to generate a VCXProj file. The version of CMake that ships with Visual Studio has also been upgraded to 3.11.

C++ Standards Conformance: And last, but not least in this section, I want to highlight that Visual C++ is now conforming to ++11, C++14, and C++17. Yes: the MSVC compiler toolset in Visual Studio version 15.7 conforms with the C++ Standard! We’re not going to stop there with our conformance effort. Expect to see more future communications from our team as we alleviate the remaining caveats. More details are available at the Visual C++ Team Blog post on how MSVC conforms to the C++ Standard.

Debugging and Diagnostics

IntelliTrace Events and Snapshots for .NET Core: IntelliTrace’s new step-back debugging feature, which we first shipped in Visual Studio 2017 version 15.5, is now supported for debugging .NET Core applications. The feature automatically takes a snapshot of your application on each breakpoint and debugger step. This enables you to go back to a previous breakpoint or step and view the state of the application as it was in the past. To enable this feature, go to Tools > Options > IntelliTrace settings > and select ‘IntelliTrace events and snapshots’. IntelliTrace step-back is a Visual Studio Enterprise feature available on Windows 10 Anniversary Update or above for debugging .NET applications.

Source Link Authentication: The debugger now supports authenticated Source Link requests for Visual Studio Team Services and private GitHub repositories. When debugging code that was built on another computer, such as a library in a NuGet package, Source Link enables the debugger to show correctly matching source code by downloading it from the internet. To build your own code with Source Link enabled see https://aka.ms/SourceLinkSpec. For VSTS repositories, authentication is provided by signing into Visual Studio. For GitHub, we leverage credentials from the GitHub extension for Visual Studio and the Git Credential Manager for Windows. If Source Link fails due to an authentication error a new “Source Link Authentication Failed” page is shown to explain the issue. This page allows you to login to VSTS or GitHub and retry the Source Link request.

Edge Debugging: Visual Studio ASP.NET and ASP.NET Core developers on Windows Insider builds can now set breakpoints and debug their JavaScript files using Microsoft Edge browser. Visual Studio will use the new Edge DevTools Protocol developed by the Microsoft Edge team when targeting Microsoft Edge browser, which means that developers will be able to debug and fix JavaScript issues from within Visual Studio in both Microsoft Edge and Google Chrome. We are glad to enable this oft-requested feature from our customers and would love to hear what you think about it.

Mobile Development

We’ve made many improvements to the mobile development experience, some listed elsewhere in this post, but for the core platform support, here are a few.

Android Development Improvements: We are now distributing the Android Oreo SDK (Android API level 27) and are shipping the Android emulators with Quick Boot enabled. Additionally, Visual Studio will now detect scenarios where the project requires a different version of the Android SDK that is installed and will download required components in the background.

Apple Development Improvements: The iOS, macOS, tvOS, and watchOS apps now feature a fully static type system. This brings many benefits, such as smaller app size, faster app startup, and reduced memory usage. We have also introduced the [Weak] attribute for fields that make it simpler to write code that is garbage collection friendly in Apple platforms. The provisioning of iOS devices has historically been a chore, requiring multiple trips to the documentation. We have incorporated the same experience that we shipped on macOS and you can now provision your devices in seconds and keep your entitlements up to date with the click of a button.

ASP.NET, Cloud, and Web Development

Visual Studio 2017 version 15.7 is the recommended version of Visual Studio to use with .NET Core 2.1 and has a bunch of new features like a new managed socket implementation and various improvements like better support for HTTPS. It doesn’t matter which you install first, either way Visual Studio version 15.7 will find .NET Core 2.1 and offer it as an option.

Deployment to Azure App Services on Linux: Visual Studio now offers you the ability to deploy non-containerized applications to Azure App Service on Linux in addition to our previous support for apps built with Docker. To publish your application to App Service and run in Linux, from the Publish dialog choose “App Service Linux” and select “Create new.”  To continue to publish a containerized application to App Service for Containers using Linux, choose “Create new App Service for Containers.”

Key Vault Connected Service: Please don’t store your application keys in your app – if possible use Azure Key Vault. We’ve made it easier in this release with the Connected Service experience – using it will add the right configuration the NuGet packages to your project and enable you to access secrets from the Key Vault. Once the Key Vault has been added, you will be able to manage secrets and permissions through the Azure portal. This is available for both ASP.NET and ASP.NET Core applications. We’ve also made it easier to use Key Vault during development: when running an ASP.NET or ASP.NET Core application on the local machine, the app may not have access to the Key Vault from the account specified under Tools > Options > Azure Service Authentication, so it won’t be able to run locally. Visual Studio detects that case and flags it for you with an error.

Universal Windows Platform Development

We have included the Windows 10 April 2018 Update SDK, Build 17134 as the new required SDK associated with the Universal Windows Platform workload. We have also added support for generating Windows Machine Learning class wrappers for an ONNX file that is added to a UWP project.

Automatic updates for sideloaded UWP apps: The Universal Windows Platform allows distributing applications without the Microsoft Store by using a mechanism called “sideloading.” With Visual Studio 2017 version 15.7 using the latest Windows 10 SDK there is now tooling to easily configure the automatic update settings for these UWP apps.

Loading code from C# Optional Packages: You can now create a new “Optional Code Package” Universal Windows project type. This project allows you to author C# code to be loaded in the context of the main application package when creating a related set. Learn more about creating C# Optional Code Packages.

Visual Studio 2017 version 15.8 Preview 1

In addition to Visual Studio 2017 15.7, we also have a Preview of 15.8 (the release notes are here). To install, you can get the preview here, or if you already have a prior Preview installed, either click on the in-product notification or check for an update directly. Previews of Visual Studio 2017 install side by side with generally available releases, so you can try the preview at the same time you have the GA version for your main coding work. Alternatively, with an Azure subscription, you can provision a VM with Visual Studio 2017 on it through the Marketplace.
C++ Quick Info Tooltips: C++ Quick Info tooltips on macros now show what they expand to and not just their definition. This is particularly useful for complex macros that reference other macros, as it’s now clear what the macro identifier will be replaced with by the preprocessor. See an example of what the tooltip now displays in the picture below.

Docker Single Project Experience: In this Preview, we’ve added a new single project Docker container experience for ASP.NET Core web projects, which builds on top of the existing Docker composed-based container tooling and makes it easy to create, debug, and build Docker containers right from Visual Studio. You can either add Docker support when creating the project, or you can add it to an existing project through right clicking on the project’s context menu in Solution Explorer. For more details on how to utilize this feature, please refer to the Visual Studio 2017 version 15.8 Preview 1 release notes.

LibMan – New Client-Side Library Manager for Web Apps: We are implementing a new tool for managing client-side libraries, colloquially known as “LibMan.” Designed as a replacement to Bower, LibMan allows you to easily acquire and manage static, client-side files for your web project from various sources, including CDNJS. You can read more about it in the post: Library Manager: Client-side content manager for web apps.

Share Your Feedback

As always, we want to know what you think. Please install Visual Studio 2017 version 15.7 and Visual Studio 2017 version 15.8 preview 1 and share your thoughts and concerns.

Please let us know any issues you have via the Report a Problem tool in Visual Studio. You can track your issues in Visual Studio Developer Community where you can ask questions and find answers. You can also engage with us and other Visual Studio developers through our new Gitter community (requires GitHub account), make a product suggestion through UserVoice, or get free installation help through Live Chat Support.

Thanks,

John

John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time.

Microsoft Build has always been a time when we deliver a wealth of developer-focused announcements. It’s an opportunity to share our vision for developer experiences across mobile, AR/VR, cloud, web, desktop, IoT and AI. This year, I’m excited to have brought this vision to life with more than a few exciting announcements:

1. .NET Core 2.1 RC
2. Future of Windows Desktop Development
3. Visual Studio 2017 version 15.7
4. Visual Studio for Mac version 7.5
5. Xamarin Forms 3.0 General Availability
6. Visual Studio Live Share Public Preview
7. Introducing Visual Studio IntelliCode

For an overview of announcements across the company, check out Scott Guthrie’s blog post; but for a round-up of Visual Studio and .NET headlines, read on.

.NET Core 2.1 RC

As of today, .NET Core 2.1 Release Candidate (RC) is available with a “Go-Live” license to use in production. .NET Core 2.1 improves on previous releases with hard-won performance gains and many new features:

• ASP.NET Core SignalR. Developers have been using SignalR to build real-time web communication solutions since 2013 on the .NET Framework. The stack has been streamlined and improved to run on the cross-platform and higher performance .NET Core runtime. We also released SignalR as an Azure service.
• ASP.NET Core web platform enhancements including support for Razor UI in class libraries, improvements in building WebAPIs, security enhancements, a new Identity UI library and HttpClientFactory.
• Entity Framework Core 2.1 introduces significant capabilities like lazy loading, data seeding, new data providers and enhanced support for CosmosDB.
• .NET Core 2.1 significantly improves build & runtime performance. It also introduces a new deployment and extensibility model for global tools.
• ASP.NET Core 2.1 is more than 15% faster than version 2.0. This means that when ASP.NET Core is released, it will top the TechEmpower benchmarks as the fastest mainstream web framework on the planet.

Of course, .NET Core remains free, cross-platform, and open source – just as it has been since 2014.

Learn more about .NET Core 2.1 RC.

Future of Windows Desktop Development

While we’re excited to release .NET Core 2.1 RC, we’re not stopping there. Today, we introduced the roadmap for .NET Core 3, which brings desktop development to our open source .NET stack. We are adding Windows Presentation Foundation (WPF) and Windows Forms on top of .NET Core. As always, developers building Universal Windows Platform apps will also continue to benefit from all the .NET Core improvements.

.NET Core 3.0 will enable Windows desktop apps use a globally installed .NET, or an app local copy, or build a single .EXE which includes .NET. Thus, .NET apps will no longer be impacted by system-wide updates. More importantly, this will allow us to make improvements to WPF and Windows Forms that we previously could not have done with .NET Framework without risking compatibility to existing apps

With .NET Core 3.0, developers will have the ability to share and easily integrate UI controls across all the major Windows desktop frameworks. You’ll be able to incorporate whatever UI controls make the most sense for your scenario, or even take a phased migration approach to modernizing your app’s UI. Developers will be able to seamlessly integrate almost all the Windows 10 API surface area into their .NET apps such as Cortana, Windows Hello, Windows ML, Rome, and more. And developers will be able to take advantage of the performance improvements and new API’s in .NET Core.

Developers targeting .NET Framework 4.8, the next version of .NET Framework, will also benefit from the improvements we plan to make such as the new Edge-based WebView control that they can host inside their apps, with more controls planned. And support for XAML Islands bringing UWP UI into existing applications.

This roadmap represents a significant investment in Windows desktop development by empowering developers to adopt the latest innovations in Windows 10 and .NET Core in their WPF and Windows Forms apps.

Learn more about the .NET Core 3.0 Roadmap.

Visual Studio 2017, version 15.7

Our flagship IDE, Visual Studio, received a significant upgrade today with the announcement of Visual Studio 2017 version 15.7. John Montgomery’s blog post has a full run-down of all the new capabilities, but some of the more significant headlines include:

• Cloud development: You’ll find several improvements to the project scaffolding and unit testing. Additionally, you can publish Helm charts directly to Azure Kubernetes Service (AKS). You can now also directly publish .NET applications to Kubernetes containers. For your ASP.NET and ASP.NET Core applications, you can configure the Key Vault connected service directly from the IDE.
• Debugging: IntelliTrace’s new step-back debugging, first shipped in Visual Studio 2017 version 15.5, is now available for .NET Core applications. The feature automatically takes a snapshot of your application on each breakpoint and debugger step so you can step “back in time” to view previous application states.
• MSVC C++ 17 conformance: Today, we are happy to announce we have reached full C++ 17 conformance in MSVC with Visual Studio 2017 version 15.7. We also added ClangFormat support for C++ developers in the IDE. Developers can use ClangFormat to automatically style and format your code as you type, in a way that can be enforced across your development team.
• Python: This release contains an opt-in preview of the Python debugger based on the popular open source pydevd debug engine, offering improved performance for many debugging scenarios.
• iOS and Android mobile development with Xamarin: The XAML editing experience has been greatly improved with full IntelliSense support. iOS devices can be provisioned for development with a single click, saving developers a lot of time and steps. Android and iOS project templates have been re-written to use the latest modern navigation patterns and are now better organized for improved discoverability.

Learn more about Visual Studio 2017, version 15.7

Visual Studio for Mac, version 7.5

Visual Studio 2017 wasn’t the only IDE to get an update. Today, we’re announcing Visual Studio for Mac version 7.5. This release includes bug fixes, performance improvements, and several new features:

• New editors for Razor, JavaScript, and TypeScript for building web projects
• Updated UI and templates for building serverless solutions with Azure Functions and .NET Core
• .NET Standard Library projects are now a fully supported option for sharing code between platforms when building Xamarin.Forms solutions.
• Preview support for Team Foundation Version Control (TFVC) in Team Foundation Server (TFS) and Visual Studio Team Services (VSTS) has arrived addressing one of our top UserVoice requests. Developers now have the option to use the existing Git source control integration or the new TFVC integration to manage their code.

Learn more about Visual Studio for Mac, version 7.5

Xamarin.Forms 3.0 General Availability

Today, we’re announcing immediate availability of Xamarin.Forms 3.0. Xamarin.Forms 3.0 delivers improved stability, faster performance, and new capabilities aimed at making it easier for you to create beautiful apps that work on Android, iOS, macOS, and Windows devices.

Xamarin.Forms 3.0 now builds with .NET Standard 2.0 using multi-targeting, while still maintaining support for PCL profiles and other .NET Standard versions. Projects load much faster when you use .NET Standard project types.

Xamarin.Forms 3.0 also includes a strong focus on developer productivity. Many developers are already familiar with the Visual State Manager already found in XAML for UWP and WPF. It’s now available for Xamarin.Forms, too. We’ve also heard from many ASP.NET developers who can build amazing layouts for the web using Flexbox and CSS. To empower these developers to build equally impressive layouts on mobile, we’ve added two features to Xamarin.Forms: FlexLayout and CSS. Xamarin.Forms 3.0 introduces both features without compromising the existing XAML experience desktop developers have come to know and love. Finally, because Xamarin apps are deployed globally, we also included right-to-left language support and many quality improvements in the 3.0 release.

Learn more about Xamarin.Forms 3.0

Visual Studio Live Share Public Preview

Today, we announced the public preview of Visual Studio Live Share. Now any developer can use Live Share to collaborate in real-time with other developers, with instant bi-directional collaboration directly from their existing tools like Visual Studio 2017 and Visual Studio Code. With Visual Studio Live Share:

• It doesn’t matter if the developer sharing doesn’t use the same editor or have the same OS as you; join a Live Share session from your own development environment. No need to install project- specific dependencies or configure runtimes. You’ll view the project in your development tool, retaining all your customizations and themes.
• Each team member in a Live Share session can separately open files, navigate, edit, and refactor code. Your changes are instantly reflected in your teammate’s editor. You can quickly jump to a teammate’s location and see their cursor as they make edits or pin to follow their actions. Want to focus their attention? Highlight a piece of code and it will highlight on their screen as well.
• Use Live Share with any language on any application pattern, including serverless, cloud native, and IoT development. At Connect() 2017, we showed Live Share working with JavaScript and Node.js. Today, Live Share supports nearly every language supported by your development tool, including C#, Python, Java, Go, C++, and
• Full-context sharing – Use Live Share to collaborate across all parts of your development workflow: co-editing, shared debugging, shared terminals, and shared servers (ports).

Learn more about Visual Studio Live Share

Visual Studio IntelliCode

Visual Studio IntelliCode is a new capability that enhances everyday software development with the power of AI. Today, IntelliCode provides intelligent suggestions to improve developer productivity and code quality in the tool that developers love, Visual Studio. Our vision is to apply AI to empower developers across the entire development lifecycle.

At Build, we shared a sneak peak of IntelliCode, showing how it uses AI to deliver better context-aware code completions, guide developers to code to the patterns and styles of their team, find difficult-to-catch code issues, and focus code reviews on areas that really matter.

Developers can sign up for news and a future private preview, as well as gain access to an experimental extension at http://aka.ms/intellicode

Send us Your Feedback

Our developer tools and services are shaped by your feedback, so please let us know what you think. To download, install and read documentation for all today’s announcements, go to:

• .NET Core 2.1 RC
• .NET Core 3.0 Roadmap announcement
• Visual Studio 2017 version 15.7
• Visual Studio for Mac version 7.5
• Xamarin Forms 3.0 General Availability
• Visual Studio Live Share Public Preview
• Introducing Visual Studio IntelliCode

If you have any trouble, you can report a problem from inside the IDE on both Visual Studio and Visual Studio for Mac.

To track issues, ask questions and find answers, explore the Visual Studio Developer Community. Or, to engage with our team and other Visual Studio developers in real-time chat, try our new Gitter community (requires GitHub account). We welcome your product suggestions through UserVoice. And, should you need it, you can also get free installation help through Live Chat Support.

Finally, don’t forget that we have three full days of announcements, deep dives, and developer interviews to share. You can live-stream or watch on-demand video later from the Microsoft Build website.

Happy coding.

Julia Liuson, CVP Developer Division Julia Liuson is Corporate Vice President of Developer Tools where she oversees business and software development of Visual Studio, Visual Studio Code and .NET – including CLR, Windows tools, all programming languages, user experience, and cloud development tools. She is a strong advocate of diversity in the workplace and a champion of women in STEM disciplines.

At Microsoft Build Live today, we are sharing a first look at our plans for .NET Core 3. The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.

We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.

ASP.NET Core will continue to move forward in parallel and will have a release with .NET Core 3.0. Our commitment to web and cloud applications remains unchanged. At the same time, it’s time to add Windows desktop applications as another supported workload for .NET Core. We have heard many requests for desktop applications with .NET Core and are now sharing our plan to deliver on that. Let’s take a look at that.

Benefits of .NET Core for Desktop

There are many benefits with .NET Core that are great for desktop apps. There are a few that are worth calling out explicitly:

• Performance improvements and other runtime updates that will delight your users
• Super easy to use or test a new version of .NET Core for just one app on a machine
• Enables both machine-global and application-local deployment
• Support for the .NET Core CLI tools and SDK-style projects in Visual Studio

We’re also announcing a set of improvements that we’ll be adding to both .NET Core 3.0 and .NET Framework 4.8:

• Access to the full Windows 10 (AKA “WinRT”) API.
• Ability to host UWP XAML controls in WPF and Windows Forms applications.
• Ability to host UWP browser and media controls, enabling modern browser and media content and standards.

.NET Framework 4.8

We’re also announcing our plans for .NET Framework 4.8. after shipping .NET Framework 4.7.2 only a week ago. We expect the next version to be 4.8 and for it to ship in about 12 months. Like the past few releases, the new release will include a set of targeted improvements, including the features you see listed above.

Visualizing .NET Core 3

Let’s take a look at .NET Core 3 in pictorial form.

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.

From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.

We’ll also be releasing a new version of .NET Standard at the same time. Naturally, all new .NET Standard APIs will be part of .NET Core 3.0. We have not yet added Span<T>, for example, to the standard. We’ll be doing that in the next version.

C#, F# and VB already work with .NET Core 2.0. You will be able to build desktop applications with any of those three languages with .NET Core 3.

Side-by-side and App-local Deployment

The .NET Core deployment model is one the biggest benefits that Windows desktop developers will experience with .NET Core 3. In short, you can install .NET Core in pretty much any way you want. It comes with a lot of deployment flexibility.

The ability to globally install .NET Core provides much of the same central installation and servicing benefits of .NET Framework, while not requiring in-place updates.

When a new .NET Core version is released, you can update one app on a machine at a time without any concern for affecting other applications. New .NET Core versions are installed in new directories and are not used by existing applications.

For cases where the maximum isolation is required, you can deploy .NET Core with your application. We’re working on new build tools that will bundle your app and .NET Core together as in a single executable, as a new option.

We’ve had requests for deployment options like this for many years, but were never able to deliver those with the .NET Framework. The much more modular architecture used by .NET Core makes these flexible deployment options possible.

Using .NET Core 3 for an Existing Desktop Application

For new desktop applications, we’ll guide everyone to start with .NET Core 3. The more interesting question is what the experience will be like to move existing applications, particularly big ones, to .NET Core 3. We want the experience to be straightforward enough that moving to .NET Core 3 is an easy choice for you, for any application that is in active development. Applications that are not getting much investment and don’t require much change should stay on .NET Framework 4.8.

Quick explanation of our plan:

• Desktop applications will need to target .NET Core 3 and recompile.
• Project files will need to be updated to target .NET Core 3.
• Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.

We intend to provide compatible APIs for desktop applications. We plan to make WPF and Windows Forms side-by-side capable, but otherwise as-is, and make them work on .NET Core. In fact, we have already done this with a number of our own apps and others we have access to.

We have a version of Paint.NET running in our lab. In fact, we didn’t have access to Paint.NET source code. We got the existing Paint.NET binaries working on .NET Core. We didn’t have a special build of WPF available, so we just used the WPF binaries in the .NET Framework directory on our lab machine. As an aside, this exercise uncovered an otherwise unknown bug in threading in .NET Core, which was fixed for .NET Core 2.1. Nice work, Paint.NET!

We haven’t done any optimization yet, but we found that Paint.NET has faster startup on .NET Core. This was a nice surprise.

Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.

There are many design decisions ahead, but the early signs are very good. We know that compatibility will be very important to everyone moving existing desktop applications to .NET Core 3. We will continue to test applications and add more functionality to .NET Core to support them. We will post about any APIs that are hard to support, so that we can get your feedback.

Updating Project Files

With .NET Core projects, we adopted SDK-style projects. One of the key aspects of SDK-style projects is PackageReference, which is a newer way of referencing NuGet packages. PackageReference replaces packages.config. PackageReference also make it possible to reference a whole component area at once, not just a single assembly at a time.

The biggest experience improvements with SDK-style projects are:

• Much smaller and cleaner project files
• Much friendlier to source control (fewer changes and smaller diffs)
• Edit project files in Visual Studio without unloading
• NuGet is part of the build and responsive to changes like target framework update
• Supports multi-targeting

The first part of adopting .NET Core 3 for desktop projects will be migrating to SDK-style projects. There will be a migration experience in Visual Studio and available at the command line.

An example of an SDK-style project, for ASP.NET Core 2.1, follows. .NET Core 3 project files will look similar.

Controls, NuGet Packages, and Existing Assembly References

Desktop applications often have many dependencies, maybe from a control vendor, from NuGet or binaries that don’t have source any more. It’s not like all of that can be updated to .NET Core 3 quickly or maybe not even at all.

As stated above, we intend to support dependencies as-is. If you are at the Build conference, you will see Scott Hunter demo a .NET Core 3 desktop application that uses an existing 3rd-party control. We will continue testing scenarios like that to validate .NET Core 3 compatibility.

Next Steps

We will start doing the following, largely in parallel:

• Test .NET Framework desktop application on .NET Core to determine what prevents them from working easily. We will often do this without access to source code.
• Enable you to easily and anonymously share dependency data with us so that we can collect broad aggregate data about applications, basically “crowd voting” on the shape of what .NET Core 3 should be.
• Publish early designs so that we can get early feedback from you.

We hope that you will work with us along the way to help us make .NET Core 3 a great release.

Closing

We have been asking for feedback on surveys recently. Thanks so much for filling those out. The response has been incredible, resulting in thousands of responses within the first day. With this last survey, we asked a subset of respondents over Skype for feedback on our plans for .NET Core 3 with (unknown to them) our Build conference slides. The response has been very positive. Based on everything we have read and heard, we believe that the .NET Core 3 feature set its characteristics are on the right track.

Todays news demonstrates a large investment and commitment in Windows desktop applications. You can expect two releases from us in 2019, .NET Core 3 and .NET Framework 4.8. A number of the features are shared between the two releases and some others are only available in .NET Core 3. We think the commonality and the differences provide a great set of choices for moving forward and modernizing your desktop applications.

It is an exciting time to be a .NET developer.

Today at Build 2018 there was a lot of great energy around the work Microsoft is doing in the area of Artificial Intelligence (AI).  This energy comes from our continued investment to deliver on the capabilities customer and partners have been asking for, along with unique new innovations.

While there is strong interest in the topic of AI, many business leaders and teams are trying to determine how to think about AI relative to their industry and/or company.  This has become incredibly apparent in the hundreds of AI conversations I’ve had with teams from around the globe in the last year.   In the spirit of bringing these conversations to life I’m going to publish 3 blog posts covering the core conversations we typically have on this topic including:

• The new generation of software building blocks and why the AI conversation is so active now (this post).
• Microsoft efforts around AI… from our AI platform, to the infusion of AI into our own products, to a new generation of AI solutions.
• AI in businesses and lessons from customers wanting to deploy AI solutions.

The software industry has historically looked to Moore’s law for guidance on how core technologies will advance to determine what is possible in the future.  Our industry over the last 20+ years has leveraged three core building blocks: Compute, Storage and Networking (CSN); to power multiple waves of transformation.  As these building blocks continuously became both more powerful and more affordable, the industry has evolved through multiple eras of compute paradigms including; standalone PC’s, client-server computing, the Internet wave, and the current cloud and mobile era, and the evolving intelligent edge and intelligent cloud paradigm.  While these core building blocks will continue to evolve and power new eras of software/computing there is also a new generation of building blocks emerging that will further accelerate what the software/IT industry is creating.

From AI, to mixed/virtual reality, to blockchain, to IoT, to quantum computing, and more… the students of today will join the industry with the ability to harness this new generation of building blocks.  In the same way we have observed how Compute-Storage-Networking have been interwoven into a seamless set of capabilities, this new generation of building blocks will also be interwoven over the next 20 years to create transformational opportunities we are only beginning to contemplate.  It is an incredible moment in time where we can see the emergence of both the people and the tools that will shape the next 20+ years of software and computing.

Even though the topic of AI is not new, three core capabilities have emerged that are allowing AI to be a front and center conversation in this new family of building blocks.

The field of AI goes back to the 1950s when a group of leading researchers met to discuss the possibility of cognitive machines. Since that time there have been booms and busts of euphoria for AI. “AI Winter” has been the name given to the busts.  What makes this time unique is the combination of access to CSN at scale through the cloud, the growth and availability of data at scale, and breakthroughs in AI research that are powering access to easier to use tools and techniques.

• Cloud – With the growth and availability of the cloud. Developers and researchers across the world have access to the CSN that they need at scale to create or work with AI tools, models, and data.
• Data – In parallel, the growth of data for building and training models is growing exponentially based on both human generated (e.g. social networks, photos, text) and machine generated (e.g. computers, phones, IoT sensors).
• Algorithms – The third key ingredient to AI acceleration is advances in the algorithms and AI tools available for developers and data scientists.

Big compute in the cloud provides many resources for processing enormous amounts of data which are critical for training AI algorithms. In Azure for example, there are the tools to store, transform and process big data sets along with the processing power (CPU, GPU, FPGA) to calculate equations quickly. Beyond the data sets that you provide Microsoft also has proprietary data sets to help companies. Bing, LinkedIn, and the Microsoft Graph provide unique insights that organizations can use in their applications.  With data and the cloud, the next step are the algorithms that make computer vision, natural language processing, and more possible.

While Microsoft Research has been working on AI and deep learning techniques for more than two decades, the last 5 years have seen an incredible rate of advancements in the state of the art across a variety of use cases.

• In 2016 Microsoft surpassed human parity in object recognition by deploying a 152-layer neural network.
• A year later we surpassed human parity for speech recognition over a phone line with the lowest percentage of errors.
• January of 2018 we surpassed human parity for machine reading comprehension about the same time as Alibaba.
• AI innovation is accelerating and a few months later in March we matched human parity in translating news from Chinese to English.

There is an incredible amount of energy in the research community right now around AI, so I anticipate many more advances in the coming years.

So now we have the core formula of CSN at scale for all developers, the growth of data for building and training models, and research advances in core algorithms that bring AI to the point where we can begin looking at what opportunities it can provide both today and into the future.  With that said, we are still in the early days of AI and all the new building blocks.

Join me again next week when I will discuss Microsoft’s efforts around AI and the role that this week’s Build announcements play in evolving them.

Cheers,

Guggs

Today, we are excited to announce that the first release candidate of EF Core 2.1 is available, alongside .NET Core 2.1 RC 1 and ASP.NET Core 2.1 RC 1, for broad testing, and now also for production use!

Go live support

EF Core 2.1 RC1 is a “go live” release, which means once you test that your application works correctly with RC1, you can use it in production and obtain support from Microsoft, but you should still update to the final stable release once it’s available.

Go live support for EF Core RC1 extends to the base functionality in EF Core and to the providers that are developed as part of the Entity Framework Core project, like the SQL Server, SQLite, and in-memory database providers. If you are using any other providers, we recommend you verify what level of support you can get from their corresponding developers.

Changes since Preview 2

For the full details on what has changed since EF Core 2.0, look at the What’s New section of our documentation. The main new features are:

• GroupBy translation
• Lazy loading
• Parameters in entity constructors
• Value conversion
• Query types
• Data seeding
• System.Transactions support

We have been stabilizing the product since Preview 2, therefore there are no new features in RC1. In fact, all changes in RC1 are either bug fixes or very small functional or performance improvements on existing features.

You can get an up-to-date list of bug fixes and small enhancements using this issue tracker query. Some of the small RC1 enhancements worth mentioning are:

• #9295 List.Exists is now translated to SQL. Thank you Massimiliano Donini for your contribution!
• #9347 Several performance improvements in model building
• #11570 DbContext scaffolding now generates a constructor that allows injection of DbContextOptions<TContext>

Obtaining the bits

The new bits are available in NuGet as individual packages, as part of the ASP.NET Core 2.1 RC1 metapackage and in the .NET Core 2.1 RC1 SDK, also released today.

The recommended way to obtain the new packages for ASP.NET Core applications is through the installation of the new SDK, rather than updating the packages. For other applications, either the SDK can be installed or the packages can be updated using the dotnet command line tool or NuGet.

EF Core 2.1 RC1 and the corresponding versions of the SQL Server and in-memory database providers are included in the ASP.NET Core metapackage. Therefore, if your application is an ASP.NET Core application and you are using one of these providers, you don’t need additional upgrade steps.

If you’re using one of the database providers developed as part of the Entity Framework Core project (for example, SQL Server, SQLite or In-Memory), you can install EF Core 2.1 RC1 bits by simply installing the latest version of a provider. For example, using dotnet on the command-line:

$ dotnet add package Microsoft.EntityFrameworkCore.Sqlite -V 2.1.0-rc1-final

If you’re using another EF Core 2.0-compatible relational database provider, it’s recommended that in order to obtain all the newest EF Core bits, you add a direct reference to the base relational provider in your application, for example:

$ dotnet add package Microsoft.EntityFrameworkCore.Relational -V 2.1.0-rc1-final

When updating packages, make sure that all EF Core packages are updated to the RC1 version. Mixing EF Core or infrastructure packages from older .NET Core versions (including previous 2.1 preview bits) will likely cause errors.

Provider compatibility

As we mentioned in previous announcements, some of the new features in 2.1, such as value conversions, require an updated database provider. However, it was our original goal that existing providers developed for EF Core 2.0 would be compatible with EF Core 2.1 as long as you didn’t try to use the new features.

In practice, testing has shown that some of the EF Core 2.0 providers are not going to be compatible with 2.1. Also, there have been changes in the code necessary to support the new features since Preview 1 and Preview 2. Therefore, we recommend that you use a provider that has been updated for EF Core 2.1 RC1.

We have news that some of these updated providers will be available within days of this announcement. Others may take longer.

We have been working and will continue to work with provider writers to make sure we identify and address any issues with the upgrade. In the particular case of Pomelo.EntityFrameworkCore.MySql, we are actively working with the developers to help them get it ready for 2.1.

If you experience any new incompatibility, please report it by creating an issue in our GitHub repository.

What’s next

We expect to ship the final version of EF Core 2.1 in the first half of 2018, as planned. We’re now getting very close to the finish line!

In the meantime, planning for the next versions of EF Core after 2.1 is ongoing. Stay tuned for upcoming announcements in this blog.

Thank you!

As always, the entire Entity Framework team wants to express our deep gratitude to everyone who has helped in making this release better by trying early builds, providing feedback, reporting bugs, and contributing code.

Please try EF Core 2.1 RC1, and keep posting any new feedback to our issue tracker!

Today we’re happy to announce the first release candidate of ASP.NET Core 2.1! This release should be very close to the final stable release of ASP.NET Core 2.1 and includes primarily bug fixes and polish for the features that we shipped in earlier previews. This is a "go live" release that can be used in production with the understanding that you will need to update to the final stable release once it is available.

Also, be sure to read about .NET Core 2.1.0-rc1 and Entity Framework Core 2.1.0-rc1.

Get started

To get started with ASP.NET Core 2.1.0-rc1 download the .NET Core 2.1.0-rc1 SDK

Customers using Visual Studio should also install Visual Studio 2017 Update 7 or Visual Studio for Mac 7.5.

Migrating an ASP.NET Core 2.0.x project to 2.1.0-rc1

To migrate an existing ASP.NET Core 2.0.x project to 2.1.0-rc1:

1. Open the project’s .csproj file and change the value of the <TargetFramework> element to netcoreapp2.1
   • Projects targeting .NET Framework rather than .NET Core, e.g. net471, don’t need to do this
2. In the same file, update the versions of the various <PackageReference> elements for any Microsoft.AspNetCore, Microsoft.Extensions, and Microsoft.EntityFrameworkCore packages to 2.1.0-rc1-final
3. In the same file, remove any references to <DotNetCliToolReference> elements for any Microsoft.AspNetCore, Microsoft.VisualStudio, and Microsoft.EntityFrameworkCore packages. These tools are now deprecated and are replaced by global tools.
4. In the same file, remove the <DotNetCliToolReference> elements for any Microsoft.AspNetCore packages. These have been replaced by global tools.

That should be enough to get the project building and running against 2.1.0-preview2. The following steps will change your project to use new code-based idioms that are recommended in 2.1

1. Open the Program.cs file
2. Rename the BuildWebHost method to CreateWebHostBuilder, change its return type to IWebHostBuilder, and remove the call to .Build() in its body
3. Update the call in Main to call the renamed CreateWebHostBuilder method like so: CreateWebHostBuilder(args).Build().Run();
4. Open the Startup.cs file
5. In the ConfigureServices method, change the call to add MVC services to set the compatibility version to 2.1 like so: services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
6. In the Configure method, add a call to add the HSTS middleware after the exception handler middleware: app.UseHsts();
7. Staying in the Configure method, add a call to add the HTTPS redirection middleware before the static files middleware: app.UseHttpsRedirection();
8. Open the project property pages (right-mouse click on project in Visual Studio Solution Explorer and select “Properties”)
9. Open the “Debug” tab and in the IIS Express profile, check the “Enable SSL” checkbox and save the changes
10. In you project file change any package reference to Microsoft.AspNetCore.All package to Microsoft.AspNetCore.App and add additional packages as needed to restore the your required dependency graph

Note that some projects might require more steps depending on the options selected when the project was created and modifications made to the project.

Deploying to Azure

Azure App Service will start deploying .NET Core 2.1.0-rc1 with the next week or so. In the meantime you can still deploy .NET Core 2.1.0-rc1 for your app as a site extension.

New features and enhancements

This release primarily contains refinements and bug fixes to the features we shipped in earlier previews, but there are a couple of new features and enhancements worth calling out. You can find a complete list of the features and enhancements in this release in the release notes.

New Razor UI Class Library template

The new Razor Class Library project template makes it easy to build reusable Razor UI class libraries. Razor class library projects are already setup with the Razor SDK to enable building Razor files (.cshtml) like MVC views and Razor Pages.

To create a new Razor class library project from the command-line:

dotnet new razorclasslib -o RazorClassLib1

You can also create Razor class library projects in Visual Studio from the "New ASP.NET Core Web Application" dialog.

Improvements to MVC test infrastructure

You can now derive from WebApplicationFactory to create a custom factory that configures the HttpClient by overriding ConfigureClient. This enables testing scenarios that requrie specific HttpClient configuration, like adding specific HTTP headers.

We also update the default environment setup by the WebApplicationFactory to be development to simplify scenarios like accessing user secrets and other development resources.

SignalR updates

• The MessagePack protocol library for SignalR was renamed to Microsoft.AspNetCore.SignalR.Protocols.MessagePack
• The JavaScript/TypeScript client now exposes a HubConnectionBuilder (similar to the C# client).

• Sticky sessions are now required when using the WebSockets transport unless the skipNegotiation flag is set to true:

  var connection = new signalR.HubConnectionBuilder()
    .withUrl("/chat", { skipNegotiation: true, transport: signalR.HttpTransportType.WebSockets })
    .build();
  

Summary

Thank you for trying out ASP.NET Core 2.1.0-rc1! Assuming everything goes smoothly with this release we should have a stable release of ASP.NET Core 2.1 shortly. If you have any questions or find any issues with this release please let us know by filing issues on GitHub.

Achieving conformance with the C++ Standards has been a long road for the Visual C++ team. If you’ve seen us at any conferences lately, you’ve probably seen the MSVC Conformance slide. (You can grab a copy of the slide or watch the 2017 CppCon talk here.) Finishing the features on this slide – which includes features from C++11, C++14, and C++17 – has been one of our team’s main goals for the past few years.

We’re happy to announce that in Visual Studio 2017 version 15.7 we’ve implemented these features. (The Technical Specifications are work-in-progress as they make their ways into the Standard.)

The MSVC compiler toolset in Visual Studio version 15.7 conforms with the C++ Standard!

We’re not going to stop our conformance effort – there are always new features, defect reports, etc. There are places within these features where we have known bugs, but we believe that, at this point, there are no feature areas in the C++ standard that you should avoid with the MSVC compiler (except for the preprocessor as described below, and floating-point <charconv> which is not yet implemented). Expect to see more future communications from our team as we alleviate the remaining caveats. See the details below in the blog.

Getting to conformance

Our compiler has a long history: February marked the 25th anniversary of the Visual C++ product. The Microsoft C product on which Visual C++ was built is 35 years old. And through the entire history of compilers our first concern has been maintaining compatibility so that your code isn’t broken. We carefully document all changes made for conformance, making our fixes source-compatible when possible and providing workarounds when changes are needed in your code. Three years ago, we unveiled our compiler rewrite. We’ve been doing a major overhaul of the compiler in a process we’ve referred to as “Rejuvenation”. Both the old YACC parser and the “Rejuv” Recursive Descent parser run side-by-side in our compiler today. We’ve moved features individually from the old code to the “Rejuv” code as we’ve been able to implement them. This technique has enabled us to continually make progress while minimizing breaking changes. Rewriting features has occasionally caused some regressions, and we are truly sorry for any inconveniences. However, overall it’s been far easier to implement modern C++ features on a modern compiler than it was on our decades-old parser, where some features just could not be implemented altogether.

Standard Library Conformance

The MSVC implementation of the Standard Library has gained major new features recently: Parallel Algorithms, Filesystem, constexpr char_traits, Special Math, and support for class template argument deduction. A detailed table of our feature status is below in this post.

Compiler Conformance

With Visual Studio 2017 version 15.7 we’re shipping a complete implementation of almost all features in the C++ Standard, including all versions up through C++17. The remaining features have been implemented (and will ship soon) or are being implemented today. This includes the completion of some of the more difficult features that we’ve been working on from C++11/14: two-phase name lookup, expression SFINAE, extended constexpr, and pack expansions. Every compiler has bugs—we reported some conformance bugs in other implementations while implementing old features with fresh eyes. We’ll continue to address our bugs and continue to implement new features as they are adopted in draft Standards.

Technical Specifications

MSVC also leads on many technical specifications. MSVC has the most complete implementation of the Extensions to C++ for Modules TS. We’ve got the oldest implementation of the C++ Extensions for Coroutines and have recently rewritten our optimizer for coroutines. Microsoft is shipping products that substantially use both Modules and Coroutines. We’ve been working on the C++ Extensions for Ranges TS, both to improve the TS and to bring MSVC to the point where we can support Ranges. And while most of the C++ Extensions for Concepts has been merged into the C++20 standard draft, we’re committed to implementing the feature early in our C++20 work.

“But what about…?”

We’ve driven our conformance effort by focusing on popular OSS libraries while maintaining source compatibility for large codebases. Some major libraries still don’t compile correctly with MSVC, and we are actively working on them.

• Boost.Hana:
  • Extended constexpr has also been a challenge in our compiler. We have some known bugs, but we believe our implementation is conforming. For a concrete example, we’ve discovered about 10 blocking constexpr bugs in the compiler when building Boost Hana, the “standard library for metaprogramming”. While we are actively working on fixing these compiler bugs, if we apply source workaround changes to Hana then we are able to pass about 30-40% of the Hana tests. We’re currently completely rewriting our constexpr evaluator to address the remaining issues.
• Pack expansion:
  • Pack expansions are quickly becoming the fabric of C++. Our implementation is also evolving as we move constructs to use the new “rejuvenation” compiler parse tree. We have some bugs with variadic generic lambdas, pack expansions over arrays, and partial ordering of function templates that will be addressed by using the new parse tree. We’re also making some fixes to the rewording of inheriting constructors to work correctly with pack expansions.
• Range V3:
  • Alias templates are used heavily in many Modern C++ libraries. MSVC has bugs with alias templates that prevent some of these libraries from compiling, e.g. Range v3. We’re re-implementing parts of the feature on the new “rejuv” parser. The new parse trees will help us to fix all the remaining bugs with alias templates in MSVC. (Range v3 is the basis of a proposal to add range support to the C++ Standard. We have a fork of Range v3 that works with MSVC but it’s significantly behind the Range v3 trunk.)
• Preprocessor:
  • Most codebases don’t use esoteric macros so we’ve only just started our major preprocessor conformance effort. We’ve fixed bugs as we’ve encountered them in OSS libraries but we haven’t made changes that would break existing code. We’ll introduce an opt-in switch in a later Visual Studio 2017 release that will allow you to use a conforming preprocessor that no longer supports some of the old MSVC-isms that exist in many codebases.
• As always, any bugs that are reported at the Developer Community portal will get looked at and responded to by the Visual C++ Team.

Feature status tables

Here are feature status tables and notes prepared by Stephan T. Lavavej (without the usual color highlighting).

• C++20: We’re working on finishing C++17 before starting C++20, so not-yet-implemented C++20 features aren’t listed in these tables. In the STL, there are minor exceptions to “17 before 20”. P0809R0 “Comparing Unordered Containers” and P0858R0 “Constexpr Iterator Requirements” were already achieved by our implementation, and P0777R1 “Avoiding Unnecessary decay” was purely a compiler throughput improvement.
• N/A: For clarity, we’ve omitted a number of papers that are Not Applicable (nothing for implementers to do, or users to take advantage of), such as wording clarifications.
• [throw()]: In /std:c++14 mode, dynamic exception specifications remain unimplemented, and throw() is still treated as a synonym for __declspec(nothrow). In C++17, dynamic exception specifications were mostly removed by P0003R5, leaving one vestige: throw() is deprecated and required to behave as a synonym for noexcept. In /std:c++17 mode, MSVC now conforms to the Standard by giving throw() the same behavior as noexcept, i.e. enforcement via termination. The compiler option /Zc:noexceptTypes- requests our old behavior of __declspec(nothrow). It’s likely that throw() will be removed in C++20. To help with migrating code in response to these changes in the Standard and our implementation, new compiler warnings for exception specification issues have been added under /std:c++17 and /permissive- as documented here.
• [twoPhase]: Two-phase name lookup is now supported in /permissive- mode. Please read our Sept 2017 post for more details.
• [exprSFINAE]: Expression SFINAE is now supported, regardless of whether /permissive- mode is active. There are a few bugs remaining to be fixed, but in general, the “unique tag type” workaround is no longer necessary, and we’ve removed this workaround from our STL implementation.
• [preprocessor]: Support for C99’s preprocessor rules is unchanged (considered partial due to support for variadic macros, although there are numerous bugs). We’re overhauling the preprocessor, and we’ll experimentally ship those changes under the /permissive- mode soon.
• [ifConstexpr]: “if constexpr” is supported in /std:c++14 with a warning that can be suppressed, delighting template metaprogramming library authors everywhere.
• [launder]: std::launder() is defined in /std:c++17 mode. When the __builtin_launder compiler intrinsic is available (as is the case for MSVC’s front-end C1XX), std::launder() uses it to communicate information to the back-end, suppressing certain optimizations. Otherwise (as is the case for Clang 6.0.0), std::launder() returns the pointer unchanged. We’re using “__has_builtin(__builtin_launder)” to automatically adapt to future versions of Clang providing this intrinsic.
• [14]: These C++17/20 features are implemented unconditionally, even in /std:c++14 mode (the default). For some features, this was because they predated the introduction of MSVC’s Standard mode options. For other features, conditional implementation would be nearly pointless or undesirably complicated.
• [17]: These C++20 features are implemented in /std:c++17 mode.
• [DR]: These papers were voted into the Working Paper after C++17, but as Defect Reports, meaning that they retroactively apply to C++17 (as bugfixes).
• [atomic]: This was almost completely implemented in VS 2017 15.3, and the remaining differences are difficult to observe (some signatures differ from the Standard, as observed by taking their address or providing explicit template arguments). The STL’s next major binary-incompatible version will fix the remaining differences.
• [byte]: std::byte is enabled by /std:c++17, but has a fine-grained opt-out macro (_HAS_STD_BYTE can be defined to be 0). This is because given certain patterns of using-directives, it can conflict with the Windows SDK’s headers. This has been reported to the SDK team and will be fixed, but in the meantime the escape hatch is available.
• [C11]: First available in VS 2015, the Universal CRT implemented the parts of the C11 Standard Library that are required by C++17, with minor exceptions. Those exceptions (which are tracked by bugs) are: missing C99 strftime() E/O alternative conversion specifiers, missing C11 fopen() exclusive mode, and missing C11 aligned_alloc(). The strftime() and fopen() functionality will be implemented in the future. aligned_alloc() will probably never be implemented, as C11 specified it in a way that’s incompatible with our implementation (namely, that free() must be able to handle highly aligned allocations).
• [charconv]: from_chars() and to_chars() are available for integers. We’re currently working on floating-point from_chars(), to be followed by floating-point to_chars().
• [depr] and [rem]: See C++17 Feature Removals And Deprecations.
• [parallel]: See below.

New Features: Parallel Algorithms

C++17’s parallel algorithms library is complete. Note that this doesn’t mean every algorithm is parallelized in every case; the most important algorithms have been parallelized and execution policy signatures are provided even where algorithms are not parallelized. Our STL implementation’s central internal header, yvals.h, contains the following “Parallel Algorithms Notes”: C++ allows an implementation to implement parallel algorithms as calls to the serial algorithms. This implementation parallelizes several common algorithm calls, but not all.

• The following algorithms are parallelized.
  • adjacent_difference, adjacent_find, all_of, any_of, count, count_if, equal, exclusive_scan, find, find_end, find_first_of, find_if, for_each, for_each_n, inclusive_scan, mismatch, none_of, reduce, remove, remove_if, search, search_n, sort, stable_sort, transform, transform_exclusive_scan, transform_inclusive_scan, transform_reduce
• The following are not presently parallelized:
  • No apparent parallelism performance improvement on target hardware; all algorithms which merely copy or permute elements with no branches are typically memory bandwidth limited.
    • copy, copy_backward, copy_n, fill, fill_n, move, move_backward, remove, remove_if, replace, replace_if, reverse, reverse_copy, rotate, rotate_copy, swap_ranges
  • Confusion over user parallelism requirements exists; likely in the above category anyway.
    • generate, generate_n
  • Effective parallelism suspected to be infeasible.
    • partial_sort, partial_sort_copy
  • Not yet evaluated; parallelism may be implemented in a future release and is suspected to be beneficial.
    • copy_if, includes, inplace_merge, is_heap, is_heap_until, is_partitioned, is_sorted, is_sorted_until, lexicographical_compare, max_element, merge, min_element, minmax_element, nth_element, partition_copy, remove_copy, remove_copy_if, replace_copy, replace_copy_if, set_difference, set_intersection, set_symmetric_difference, set_union, stable_partition, unique, unique_copy

New Features: Filesystem

C++17’s <filesystem> is supported. This is a completely new implementation, incompatible with the previous std::experimental version, necessitated by symlink support, bug fixes, and changes in standard-required behavior. Currently, including <filesystem> provides the new std::filesystem and the previous std::experimental::filesystem, and including <experimental/filesystem> provides only the old experimental implementation. The experimental implementation will be REMOVED in the next ABI-breaking release of the libraries.

Performance and Throughput Improvements

• Refactored some of the metaprogramming in <variant>, reducing compile time of programs that use large variants by as much as 30%.
• The STL will now detect some inputs to std::swap_ranges that are safe to vectorize, providing 8x (times, not percent) performance wins for these special cases.
• std::stable_sort had an optimization applied to avoid doing “is the temporary memory we allocated big enough” checks on each element movement, resulting in a 2-3% performance win in release builds and a 26% win in debug builds when sorting ints.
• Refactored the vector::emplace_back family into separate “fast and nonallocating” and “slow and allocating” paths, allowing the former to be inlined into callers.
• Refactored some parts of the binary tree implementation that don’t depend on T out of templates for increased throughput.
• /std:c++17 now activates the STL’s internal usage of “if constexpr” to improve throughput, mitigating the throughput cost of providing more features. (More “if constexpr” refactoring remains to be done.)

Bug Fixes

• Fixed a bug in pmr::unsynchronized_pool_resource and pmr::synchronized_pool_resource that resulted in severe failures when allocating objects of multiple sizes from the same pool resource.
• Applied noexcept in more places in std::array, especially in std::array<T, 0> where we didn’t even provide the standard-mandated noexcepts.
• We use destructors rather than catch and reraise in more places in the STL, improving the debugging experience for unhandled exceptions by preserving their original throw site.
• Iterator debugging now runs order checking for homogenous ranges only, avoiding cases where we required more from comparison predicates than the standard requires.
• priority_queue now avoids unintentional argument-dependent lookup when calling std::make_heap() etc.
• <cmath>’s fma() and remquo() overloads are now constrained for consistency.
• Fixed truncation warnings in vector and string (on x64 with allocators providing 32-bit size_type).
• Added constexpr and noexcept to std::ignore.
• Implemented more LWG issue resolutions. Our tracking spreadsheet is massive, so here’s a summary. The LWG issues resolved in C++14 were completed in VS 2017 15.0. Of the LWG issues resolved in C++17 and the C++20 Working Paper (plus a few that are still open):
  • 130 are N/A
  • 64 were implemented before VS 2017
  • 47 were implemented in VS 2017 15.0
  • 32 were implemented in VS 2017 15.3
  • 13 were implemented in VS 2017 15.5
  • 8 were implemented in VS 2017 15.6
  • 33 were implemented in VS 2017 15.7
  • 14 have been implemented in VS 2017 15.8 so far
  • 4 have been implemented in our “WCFB02” binary-incompatible branch
  • 2 have been reported to the Universal CRT team (these involve ISO-deprecated headers)
  • 2 affect not-yet-implemented C++20 features
  • 6 remain to be implemented

Other Significant Changes

• The STL is now tested with Clang/LLVM 6.0.0 and no longer supports 5.x.
• Added more [[nodiscard]] attributes, especially in <complex> and <cmath>.
• The non-Standard <allocators> header has been deprecated with the same technique as <hash_map> (an impossible-to-ignore #error with an escape hatch). The message is: “#error The non-Standard <allocators> header is deprecated and will be REMOVED. Consider using the C++17 <memory_resource> header. You can define _SILENCE_STDEXT_ALLOCATORS_DEPRECATION_WARNING to acknowledge that you have received this warning.”

In closing

We’d love for you to download Visual Studio 2017 version 15.7 and try out all the new C++17 features. (Remember you’ll often have to use the /permissive- conformance switch as well as /std:c++17 or /std:c++latest as appropriate.)

As always, we welcome your feedback. We can be reached via the comments below or via email (visualcpp@microsoft.com). If you encounter other problems with MSVC in Visual Studio 2017 please let us know through Help > Report A Problem in the product, or via Developer Community. Let us know your suggestions through UserVoice. You can also find us on Twitter (@VisualC) and Facebook (msftvisualcpp).

In our blog posts on the Visual C++ Team Blog, we often encourage readers to submit suggestions on how to improve Visual Studio via UserVoice. We review these suggestions regularly and often work to incorporate them into future releases. This post aims to provide an update, expanding on our previous entry on completed UserVoice suggestions, and to let you know which suggestions we’ve recently marked as Complete.

The following list contains 22 completed suggestions, totaling 618 votes!

• Add a cl.exe option for system headers like gcc’s -isystem
• Hide compiler warnings coming from include paths
• Silence warnings from third party code
• Update Image Watch
• __has_include and __has_include_next
• Implement Guaranteed Copy Elision
• v140_xp toolset support
• Make forward slashes the default for Includes
• Provide a Macro Visualization Tool
• Support more C++ code-formatting features
• Adding C to Visual Studio / Add support for Visual C
• Enable IntelliSense completion on enter instead of tab
• Extract code into function
• Pause option during downloads
• Go to variable construction or initialization on right click
• Google-style code support
• CMake for Linux
• Linux console automatically opens on run
• Automatic scrolling in Linux console window
• Visual Studio for Linux support for GCC compilers
• Fix sync for cross-platform CMake remote build files
• Distribute VsMSBuildCmd.bat with Visual C++ Build Tools

If you voted for or suggested any of these items, your votes have been returned, and you can now once again use these to support other suggestions.

If you haven’t yet had the chance to suggest features, vote, or provide feedback, we welcome you to check out the Visual Studio forum on UserVoice and select Help > Send Feedback > Provide a Suggestion. Thank you again to everyone who helps make Visual Studio a better experience for all, and we’ll look forward to your feedback going forward.

With Visual Studio, we’re always looking for ways to save developers time and make them more productive. A good way to do this is to look at C/C++ language features that are difficult to work with, and make it easier to understand them. Today, we’re looking at macros. Macros are always a pain to deal with, yet they are one of those things that never seem to go away in C++. To make it easier to understand what a particular macro is doing, we are introducing a new feature: macro expansions in Quick Info tooltips. If you are already using Visual Studio, you may already know that you can hover over a code symbol (such as a variable) to quickly see the definition of that symbol, as well as any comments describing it (as long as those comments are present above the definition). As of Visual Studio 2017 version 15.8, when you hover over a macro, you get an additional line of information: the actual expansion of the macro that the preprocessor will replace during the first stage of compilation. Here is an example:

Hovering over a macro now shows the expansion of that macro.

For a very simple macro, like a macro defining a constant number such as Pi, this might not seem very useful, since the macro definition alone will tell you all you need to know. But when you have a macro that references other macros, getting the full expansion easily can save you a lot of time.

This feature is available today in the first 15.8 preview. You can download the latest preview build of Visual Studio that can run side by side with your release build from the Visual Studio website. Since this feature is still in preview, there are a few limitations which we plan to address in a future update. The following are a few cases where you will not yet see macro expansions:

1. On #define statements
2. On the condition blocks of #if / #ifdef statements
3. When hovering on a macro that is used as an argument to a function-like macro (you can still hover on the function-like macro name itself instead though).

As always, we encourage you to try out the newest features via the Visual Studio 2017 Preview channel. 15.8 Preview 1 is available today, and you will find even more new features in future previews. If you run into any bugs, we would appreciate if you can file a bug report via Help > Send Feedback > Report A Problem from the IDE. If you have some ideas for new features that we should add to Visual Studio, you can post suggestions on UserVoice.

Two years ago at //Build 2016, we made Service Fabric generally available and since then, we’ve seen tremendous growth with enterprise customers across a broad range of industries taking advantage of Service Fabric’s extensive capabilities to lift/shift and modernize, build business critical SaaS, transform gaming apps, write secure financial platforms and create scalable IoT solutions on Azure.

Today, Service Fabric powers many Azure and Microsoft services such as Azure Cosmos DB, Azure SQL Database, Skype for Business, hosting over a million applications and running millions of cores daily. It is a platform for business critical applications. Less than two months ago, we began to open source the entire code base for Service Fabric (all 2.5+ million lines of code) starting our journey to a completely open development process on GitHub.

At Microsoft Build 2018, we are excited to share with you announcements and updates on the road ahead.

Adding serverless capabilities to Service Fabric

Earlier today, we shared our product roadmap and demonstrated Azure Service Fabric Mesh, which offers the same reliability, mission-critical performance and scale customers get with Service Fabric, but no more overhead of cluster management and patching operations. Service Fabric Mesh supports both Windows and Linux containers allowing you to develop with any programming language and framework of your choice.

Whether it be modernizing existing workloads or building highly available, cloud native applications with stateful services, Service Fabric Mesh allows you to deploy microservices running in containers, and quickly scale to meet the needs of most demanding workloads right from Visual Studio or Azure Portal/CLI, and pay only for what you use (per second billing). It also offers intelligent routing between microservices using Envoy.

Here is a screen capture showing how easy it is for you to write an application, test and debug locally on Service Fabric and publish it to Service Fabric Mesh in seconds - no VMs, storage, network to manage.

You can sign up for the private preview, with a public preview planned in the upcoming weeks.

Enhancements to Service Fabric Clusters

We recently rolled out the 6.2 release of Service Fabric providing general availability for .NET Core and Java runtimes on Linux, along with preview support for RHEL as the operating system to augment the Windows based cluster offerings.

We’ll be releasing the next update of Service Fabric (v6.3), which will provide an integrated development experience to target your choice of Service Fabric environment, be that having more control through Service Fabric Clusters in Azure, running on-premises with Service Fabric Standalone, or letting Azure fully manage the infrastructure and orchestration through Service Fabric Mesh. This release of Service Fabric will also have many customer-requested enhancements including secret management and isolated networks.

Manage Service Fabric on-premises clusters through Azure

As the world demands hybrid flexibility, Service Fabric offers hybrid microservices platform, giving developers the option to deploy on-premises. It’s free and supported by Microsoft. Now, we’re making it even easier to create and manage these standalone clusters running anywhere.

We are working on supporting the creation and management of Service Fabric Standalone clusters through Azure (Portal and the CLI) together with other Service Fabric deployments, enabling hybrid cluster deployments across on-premises, Azure or even other clouds. Furthermore, we’ll be adding Linux support (Ubuntu & RHEL) to the Service Fabric Standalone offering.

Resilient IoT Edge with Service Fabric

Building on the on-premises support of Service Fabric, we’re working on extending Service Fabric support to IoT Edge devices. You can use Service Fabric deployed on IoT edge devices to create local clusters. Service Fabric powers highly reliable IoT edge applications which can then be managed through Azure IoT Hub.You can see a demo of this exciting capability and more at Mark Russinovich’s //Build session - Inside Azure Datacenter Architecture talk.

Come and meet us

We’d love to hear from you. If you are at //Build, visit the Service Fabric booth in the Expo hall, give us feedback, have a design discussion, or see some of our cool demos. You can also search “Service Fabric” and find our session stream or recordings. For example, you will learn:

• More about Azure Server Fabric Mesh from BRK2111 Azure Service Fabric: The road ahead for microservices.
• How we enable modernization scenarios through BRK2102 App Modernization with Microsoft Azure, BRK2149 Modernize your Windows Server applications with containers and BRK3810 Modernizing existing .NET applications with Windows Containers and Azure cloud.
• What you can build with Service Fabric directly from our customers through THR2034 Accenture: Modernize applications and reduce TCO with Windows containers on Service Fabric, THR2011 How Honeywell migrated their smart thermostat application to Service Fabric and THR2513 ASOS.com: Improving cloud utilization with Service Fabric.

We invite you to reimagine the microservices platform together with us by joining our open source project and sign up for the private preview of Service Fabric Mesh.

Today at //Build 2018, we are excited to announce the preview of ML.NET, a cross-platform, open source machine learning framework. ML.NET will allow .NET developers to develop their own models and infuse custom ML into their applications without prior expertise in developing or tuning machine learning models.

ML.NET was originally developed in Microsoft Research and evolved into a significant framework over the last decade; it is used across many product groups in Microsoft like Windows, Bing, Azure, and more .

With this first preview release, ML.NET enables ML tasks like classification (e.g. text categorization and sentiment analysis) and regression (e.g. forecasting and price prediction). Along with these ML capabilities, this first release of ML.NET also brings the first draft of .NET APIs for training models, using models for predictions, as well as the core components of this framework, such as learning algorithms, transforms, and core ML data structures.

ML.NET is first and foremost a framework, which means that it can be extended to add popular ML Libraries like TensorFlow, Accord.NET, and CNTK. We are committed to bringing the full experience of ML.NET’s internal capabilities to ML.NET in open source.

To sum it all up, ML.NET is our commitment to make ML great in .NET.

Please come and join us over on GitHub and help shape the future of ML in .NET:

https://github.com/dotnet/machinelearning

Over time, ML.NET will enable other ML scenarios like recommendation systems, anomaly detection, and other approaches, like deep learning, by leveraging popular deep learning libraries like TensorFlow, Caffe2, and CNTK, and general machine learning libraries like Accord.NET.

ML.NET also complements the experience that Azure Machine Learning and Cognitive Services provides by allowing for a code-first approach, supports app-local deployment and the ability to build your own models.

The rest of this blog post provides more details about ML.NET; feel free to jump to the one that interests you the most.

• ML.NET Core Components
• Sentiment Classification with ML.NET
• The Road Ahead
• Help shape ML.NET for your needs

ML.NET Core Components

ML.NET is being launched as a part of the .NET Foundation and the repo today contains the .NET C# API(s) for both model training and consumption, along with a variety of transforms and learners required for many popular ML tasks like regression and classification.

ML.NET is aimed at providing the E2E workflow for infusing ML into .NET apps across pre-processing, feature engineering, modeling, evaluation, and operationalization.

ML.NET comes with support for the types and runtime needed for all aspects of machine learning, including core data types, extensible pipelines, high performance math, data structures for heterogeneous data, tooling support, and more.

The table below describes the entire list of components that are being released as a part of ML.NET 0.1.

We aim to make ML.NET’s APIs generic, such that other frameworks like CNTK, Accord.NET, TensorFlow and other libraries can become usable through one shared API.

Getting Started Installation

To get started with ML.NET, install the ML.NET NuGet from the CLI using:

dotnet add package Microsoft.ML

From package manager:

Install-Package Microsoft.ML

You can build the framework directly from https://github.com/dotnet/machinelearning.

Sentiment Classification with ML.NET

Train your own model

Here is a simple snippet to train a model for sentiment classification (full snippet of code can be found here).

var pipeline = new LearningPipeline();

pipeline.Add(new TextLoader<SentimentData>(dataPath, separator: ","));

pipeline.Add(new TextFeaturizer("Features", "SentimentText"));

pipeline.Add(new FastTreeBinaryClassifier());

pipeline.Add(new PredictedLabelColumnOriginalValueConverter(PredictedLabelColumn = "PredictedLabel"));

var model = pipeline.Train<SentimentData, SentimentPrediction>();

Let’s go through this in a bit more detail. We create a LearningPipeline which will encapsulate the data loading, data processing/featurization, and learning algorithm. These are the steps required to train a machine learning model which allows us to take the input data and output a prediction.

The first part of the pipeline is the TextLoader, which loads the data from our training file into our pipeline. We then apply a TextFeaturizer to convert the SentimentText column into a numeric vector called Features which can be used by the machine learning algorithm (as it cannot take text input). This is our preprocessing/featurization step.

FastTreeBinaryClassifier is a decision tree learner we will use in this pipeline. Like the featurization step, trying out different learners available in ML.NET and changing their parameters may enable identifying better results. PredictedLabelColumnOriginalValueConverter converts the model’s predicted labels back to their original value/format.

pipeline.Train<SentimentData, SentimentPrediction>() trains the pipeline (loads the data, trains the featurizer and learner). The experiment is not executed until this happens.

Use the trained model for predictions

SentimentData data = new SentimentData
{
    SentimentText = "Today is a great day!"
};

SentimentPrediction prediction = model.Predict(data);

Console.WriteLine("prediction: " + prediction.Sentiment);

To get a prediction, we use model.Predict() on new data. Note that the input data is a string and the model includes the featurization, so our pipeline stays in sync during both training and prediction. We didn’t have to write preprocessing/featurization code specifically for predictions.

For more scenarios for getting started please refer to the documentation walkthroughs which go over sentiment analysis and taxi fare prediction in more detail.

The Road Ahead

There are many capabilities we aspire to add to ML.NET, but we would love to understand what will best fit your needs. The current areas we are exploring are:

• Additional ML Tasks and Scenarios
• Deep Learning with TensorFlow & CNTK
• ONNX support
• Scale-out on Azure
• Better GUI to simplify ML tasks
• Integration with VS Tools for AI
• Language Innovation for .NET

Help shape ML.NET for your needs

Take it for a spin, build something with it, and tell us what ML.NET should be better at. File a couple of issues and suggestions on GitHub and help shape ML.NET for your needs.

https://github.com/dotnet/machinelearning

If you prefer reaching out to us directly, you can do so by providing your details through this very short survey.

Today at Red Hat Summit 2018 in San Francisco, Microsoft and Red Hat will jointly demonstrate our OpenShift on Azure offering, the first fully managed and easiest to use version of OpenShift in the cloud. 

Since last year’s announcement about OpenShift Dedicated on Azure, based on customer feedback, Microsoft and Red Hat have created an offering that provides much more to customers than the original concept. It will be both fully managed and engineered to make it easier and quicker to use on Azure.

What do we mean by fully managed? OpenShift on Azure will be jointly engineered, operated, and supported by both Red Hat and Microsoft. As a fully managed service, it will be kept up-to-date, with a single unified bill, integrated support experience, and in all respects a native Azure service. Our customers told us that this “one throat to choke” was incredibly important and missing from other cloud-based OpenShift offerings, so we’re happy to be able to meet that need.

While customers can use OpenShift in many cloud environments today, the newly announced OpenShift on Azure makes it easier to set up and use with native Azure integration and leveraging the same Kubernetes engine that powers Azure Kubernetes Service, making it easier to scale clusters.

If you want to create a new OpenShift cluster, you don’t need to create a service request and wait a few hours for your nodes to appear (as you might experience on other clouds). Instead, you can use the Azure CLI to execute something like:

az openshift create -n oscluster -g osrg `
	–node-vm-size Standard_DS4_v3`
	--l eastus

Within a few minutes you’ll have a new cluster, more quickly and easily than you’ll get with other public cloud offerings available right now.

Open Service Broker for Azure (OSBA) also works with OpenShift for Azure (as well as Azure Stack), which automatically discovers and enumerates Azure services you can use, such as Cosmos DB, Azure KeyVault, and more. OSBA adds value to your OpenShift on Azure deployments by allowing you to easily integrate your other Azure investments.  It’s another great ease of use feature to get you up and running quickly, as well connect to other projects you may already have or plan to build on Azure.

To add even more goodness, when you combine all of this with the newly-announced Azure Stack and Windows Container support for on-premises OpenShift Container Platform, it’s a great fit for enterprise customers looking for a hybrid cloud container platform designed for both RHEL and Windows. Learn how to deploy OpenShift Container Platform on Azure Stack today.  

If you’re interested in trying out the new fully-managed OpenShift on Azure, please submit your contact details and we’ll reach out to you as soon as we announce the public preview.

Azure Stream Analytics is a serverless PaaS service in Azure to run real-time analytics on fast moving streams of data. Today, we are excited to announce several new features in Azure Stream Analytics.

In public preview

Session window

Native support for windowing functions is a key capability in Azure Stream Analytics that helps developers author complex stream processing logic on temporal windows. Historically, Stream Analytics offered Tumbling, Hopping and Sliding windows to perform temporal operations on streaming data. Today, we announce a brand new window type known as session window. Unlike the three existing window types, a session window creates dynamic temporal windows of variable sizes based on the batches of incoming data. It therefore allows users to filter out periods of time where there is no data. With three main parameters: timeout, maximum duration and partitioning key (optional), it helps developers easily build solutions for scenarios such as clickstream analytics, connected car telemetry and many more.

Example of a session window with a 5 minutes timeout

In private preview

To join any or all of these private previews below, please sign-up.

C# custom code support for Stream Analytics jobs on IoT Edge

Last year we introduced JavaScript User-Defined functions. Since then, we heard from many customers that they wanted to use several other languages for extensibility. Today we are pleased to announce the support of C# custom code in Azure Stream Analytics for IoT Edge. With Visual Studio support for query authoring and ease of deployment provided by IoT Edge, it will enable users to author rich streaming pipelines. In addition to the simplicity of our SQL language, this will enable users to leverage existing code and libraries, or develop new logic that will run directly in the streaming engine.

Blob output partitioning by custom attribute

It is now possible to partition your Azure Stream Analytics output to Blob storage based on any column in the query. Previously, only {date} and {time} partitioning were supported. This feature is designed to greatly improve downstream data-processing workflows by allowing more fine-grained control over the blob output. The partition key can be a column from the input stream or it may be a field in the query itself. For instance, one could simply set the Path Prefix field in Blob output to {client_id} in a real-time application for customer intelligence.

Updated Built-In ML models for Anomaly Detection

This feature has been in public preview for several months. Acting on valuable customer feedback we are adding ML model support for ‘spike’ and ‘dip’ detection in addition to currently available Bi-directional, Slow positive and Slow negative trends detection. We are also improving anomaly scores normalization to help customers interpret the results better.

Level change anomalies indicated by red dots and spike anomalies indicated by red arrows

Positive trend change anomaly

Keep the feedback and ideas coming

Azure Stream Analytics team is highly committed to listening to your feedback and let the user voice dictate our future investments. We welcome you to join the conversation and make your voice heard via our UserVoice.

Today, at Build 2018, we announced a preview of the Google Android emulator that’s compatible with Hyper-V, available on the Windows 10 April 2018 Update. This enables developers with Hyper-V enabled on their machines to use a hardware accelerated Android emulator, without needing to switch to Intel’s HAXM hypervisor. Amazing work was done by the Windows Hyper-V team, with help from the Xamarin team, to make to this happen.

Today’s preview means you can use Google’s Android emulator side-by-side with other Hyper-V based technologies, including Hyper-V VMs, Docker tooling, the HoloLens emulator, and more. This means that any Android developer on Windows, who also uses Hyper-V, can use a fast Android emulator that will always support the latest Android APIs, works with Google Play Services out of the box, and works with all features in the Android emulator, including camera, geolocation, and Quick Boot.

Try the preview

The Windows Hypervisor Platform was introduced in the Windows 10 April 2018 Update and enables third-party virtualization stacks to utilize the Windows Hypervisor for hardware acceleration. If you are using Hyper-V, this stack replaces Intel HAXM as the hypervisor for the Android emulator.

Support for using the Windows Hypervisor as an accelerator for the Android emulator is currently in preview and requires the Windows 10 April 2018 Update. Here are the steps to get it installed.

1. Enable Hyper-V and the Windows Hypervisor Platform

Open Turn Windows features on or off and select Hyper-V and the Windows Hypervisor Platform checkboxes. For these features to take effect, you will need to restart your machine.

2. Install the Visual Studio Tools for Xamarin preview

To enable IDE support for the Android emulator, such as debugging, you must install an updated preview of the Visual Studio Tools for Xamarin. First, ensure you have Visual Studio 2017 version 15.8 Preview 1 or higher with the Mobile development with .NET (Xamarin) workload installed.

Download and open the preview installer. Click Install.

3. Update to Android Emulator 27.2.7 or above

In Visual Studio, select Tools > Options > Android > Android SDK Manager. Click the Tools tab, select the Android Emulator component, and select Apply Changes.

4. Start debugging!

Now when you debug your Android apps, you can use the latest Android SDKs in a fast emulator, right from Visual Studio alongside Hyper-V based technologies like Docker.

Share your feedback

We need your help to make using the Google Android emulator with Hyper-V an amazing experience. Be sure to share your feedback in Visual Studio by going to Help > Send Feedback > Report a Problem if you experience any problems or strange behavior. Please provide the following information in your bug report:

• Android emulator log – In Visual Studio, open the Output window and select the Debug output pane.
• Android emulator configuration file – In File Explorer, navigate to %HOMEPATH%.androidavd and attach the configuration settings file (.ini) for the Android emulator.
• System Information – Open System Information and click File > Export.

For more information on configuring the Hyper-V emulator, and for a listing of known issues, visit our documentation.

Miguel

Miguel de Icaza, Distinguished Engineer, Mobile Developer Tools @migueldeicaza Miguel is a Distinguished Engineer at Microsoft, focused on the mobile platform and creating delightful developer tools. With Nat Friedman, he co-founded both Xamarin in 2011 and Ximian in 1999. Before that, Miguel co-founded the GNOME project in 1997 and has directed the Mono project since its creation in 2001, including multiple Mono releases at Novell. Miguel has received the Free Software Foundation 1999 Free Software Award, the MIT Technology Review Innovator of the Year Award in 1999, and was named one of Time Magazine’s 100 innovators for the new century in September 2000.

The topic for my talk at the Microsoft Build conference yesterday was "Migrating Existing Open Source Machine Learning to Azure". The idea behind the talk was to show how you can take the open-source tools and workflows you already use for machine learning and data science, and easily transition them to the Azure cloud to take advantage of its capacity and scale. The theme for the talk was "no surprises", and other than the Azure-specific elements I tried to stick to standard OSS tools rather than Microsoft-specific things, to make the process as familiar as possible.

In the talk I covered:

• Using Visual Studio Code as a cross-platform, open-source editor and interface to Azure services
• Using the Azure CLI to script the deployment, functions, and deletion of resources in the Azure cloud
• Using the range of data science and machine learning tools included in the Data Science Virtual Machine on Ubuntu Linux
• Using Python and Tensorflow to train a deep neural network on a GPU cluster with Azure Batch AI
• Running sparklyr with RSTudio on a Spark cluster using aztk

It's not quite the same without the demos (and there's no recording available just yet), but you may find the notes and references in the slides below useful.

At Build 2018, we announced the public preview of Private Offers on Azure Marketplace for single virtual machine offers, enabling publishers to create SKUs that are only visible to targeted customers. Azure Marketplace publishers are now able to create these private offers via the Cloud Partner Portal.

Scenarios

Private offers unlock the ability for publishers to create exclusive offers for their closest customers and offer customized software and terms to them. These customized terms enable publishers to light up a variety of scenarios.

• Private Offers can provide specialized pricing such as discounts, long term pricing, and bulk software deals to targeted customers.
• Publishers can broaden the audience for the private offers as they make updates, thereby allowing them to run limited BETA releases. These releases can then be made public later with a few mouse-clicks.
• Special terms and offers can be entered into these offers enabling publishers to offer software with special agreements which must be agreed to while deploying software.

Creating Private Offers and SKUs

For existing offers, publishers can easily create new private variations only visible to and purchasable by the targeted customers by creating new SKUs and marking them as private. Private SKUs must use a new SKU Id, however they may reuse the images already published for a public SKU. This allows publishers to create multiple private SKUs for a public SKU without having to submit multiple images. Any updates to the offer can be made by updating one image and the images across all the public and private SKUs will be updated seamlessly.

Such offers will have both public SKUs and one or more private SKUs only visible to targeted customers. Depending upon the SKU Id referred during the deployment, the disk is deployed and the right prices are charged to the customers. Publishers also have the ability to alter the terms and description shown for these items during deployment.

For new private offers or SKUs which are only available privately, publishers can go about creating their offers as they would today and additionally marking the SKUs as private. The offers that only have private SKUs will not have a publicly visible version. These SKUs will not be visible on AzureMarketplace.com or the Azure portal.

At launch, we are giving publishers the ability to target customers using Subscription Ids. Publishers may enter individual subscription Ids or upload a CSV of subscription Ids which they would like to have access to the private offers. We plan to add more options around targeting customers including using tenant Ids and management groups in the future.

Deploying Private Offers

The experience of deploying private offers for the end customers remains the same as any other public offer. Upon viewing the catalogue on the Azure portal, customers will be prompted that they have private offers available to them:

Private Offers will also appear in search results and be deployable via command line and ARM Templates like any other offers. Just look out for the “Private” badge. To learn more about the new capabilities available to our partners, please visit our documentation page. If you would like to begin selling on Azure Marketplace and take advantage of these new capabilities, you can start on the Azure Marketplace webpage.

Feedback

We are excited to be making these new capabilities available to our partners and as always, we appreciate every bit of feedback. Feel free to use the smile/frown button on the Cloud Partner Portal to send across feedback about this feature (or anything else).

We’re excited to share updates about changes to F# and F# tools which shipped with the Visual Studio 2017 version 15.7 release. Let’s dive in!

Type Providers now support .NET Standard

For those who aren’t familiar with Type Providers, they are a feature of F# which allow you to get IntelliSense for data. When pointed at a data source, a Type Provider can produce an object model for that data. This object model is read by the F# compiler, which can then be used to power IntelliSense.

Type Providers can now be .NET Standard components. What this means is that you can use Type Providers in .NET Core apps, .NET Standard libraries, and .NET Framework apps without depending on specific packages for each target!

One example Type provider targeting .NET Standard is the HtmlProvider from FSharp.Data. Getting started is very easy in Visual Studio:

1. File | New Project
2. Select .NET Core application (or .NET Standard Class Library)
3. Add a NuGet package reference to FSharp.Core 3.0.0-beta (if you use the NuGet UI, check “Incude Prerelease”)

Type Providers are extremely useful for data access, data exploration, and more. For example, here is how you can easily find information about the filmography of Donald Duck. The code sample is very simple:

Note that IntelliSense names have been generated based on the actual HTML data being read! When run, the application prints out all of the data selected:

Although the above screenshots show Windows and Visual Studio, you can use Type Providers on any OS where .NET Core runs, and with any editor tooling you like.

We are very excited about this and look forward to the coming months when all of the Type Providers in the F# ecosystem upgrade to support .NET Standard.

ASP.NET Core, Docker, and Azure tooling support

Starting with version 15.7 of Visual Studio 2017, F# officially supports creating ASP.NET Core projects via the same UI that C# supports. Additionally, all tooling for Docker, CI/CD with Visual Studio Team Services, and publishing to Azure App Service is supported.

When you use File | New Project to create a new F# project, you’ll notice a new tab called Web under Visual F#. The template there is also present under .NET Core:

When you create a project with this template, it will launch the ASP.NET dialog with F# template options, including scaffolding Docker support:

You can always add Docker support later with Right Click > Add > Docker Support on the project node in the UI.

This will work for all F# projects, not just ASP.NET ones:

Additionally, if you are inclined to use the Visual Studio UI to publish applications or set up CI/CD with Visual Studio Team Services, you can do so with any F# project which uses the Microsoft.NET.Sdk.Web attribute.

For example, you can add Docker support to an existing Giraffe project and use the UI to publish it to a container registry of your choosing.

1. Right-click the project node and select Add > Docker Support.
2. Rick-click the project node and select Publish.
3. Select the Container Registry tab.
4. Select the registry you prefer (Azure Container Registry, Docker Hub, or Custom).
5. Fill out the form data and publish to a container registry!

We’re very excited about this tooling support, especially because it makes it so much easier to get started with F# for server and cloud programming in Visual Studio.

Performance improvements

The 15.7 update for Visual Studio 2017 comes with significant performance and responsiveness improvements. This work involved major contributions from Microsoft Mobile Tools (who provide support for F# in Xamarin and Visual Studio for Mac) and the F# community.

Reduction in data structure sizes

Visual Studio uses the F# Compiler Service, which is an API that exposes different layers of the F# compiler, including some of its data structures. What’s interesting about this is that performance characteristics of these data structures and functions are different when compiling F# code versus using F# tooling.

Many data structures used by the F# Compiler Service contained data that was rarely used and were kept in memory for a longer time than necessary. The data structures still exist (otherwise needless re-computations are done), but the size of the data structures has been reduced by splitting them up into “necessary” and “optional” data.

What this means is that in many situations, usage of the tools will consume less memory that before because the optional data in these data structures won’t be filled. There can still be some situations where optional data is computed and stored in memory, but generally speaking, usage patterns in the F# tools will require less memory.

This work was entirely a collaboration between Microsoft and the F# community after a series of discussions about the kinds of data structures which could be reduced in size. In particular, one of our long-time contributors, Avi Avni, contributed significant work. We’re extremely grateful for his contributions and are excited to continue working with him.

Moving metadata into virtual memory

One of the largest contributors to memory usage for F# tooling has been in what is called a ByteFile, which is a data structure that holds data in memory when it is read from referenced assemblies. If you are working in a project with a significant amount of dll references (project to project references, NuGet package references, etc.), then this could significantly increase memory usage in previous Visual Studio releases. This increased memory usage could reach a threshold in large solutions where the F# compiler service entered a “loop of doom”: caches were flushed, then filled, then flushed, then filled . . . all while the GC churned endlessly, rendering Visual Studio unusable.

Starting with the 15.7 update, we now store this data in virtual memory, backed by the Visual Studio Metadata Reference Manager that C# and VB use. This significantly reduces memory usage over time for large F# projects in Visual Studio, or projects which read a lot of data from assembly references. As metadata is read into virtual memory and used, memory usage will increase. But rather than stay in memory indefinitely, the data will be written to the backing memory-mapped file and incur a significant reduction in memory usage after some time. When using the 15.7 release against the Visual F# compiler and tools codebase, we observe significant memory reductions and no longer experience a “loop of doom”. We hope that this can be true for the many large F# codebases out there as well.

Adding a priority to document diagnostic analyzers

With Visual Studio 2017, F# tools use a Roslyn mechanism to analyze documents when they change. There are multiple analyzers which run for F#, depending on what you have turned on:

• Unused open statement analysis
• Unused declaration analysis
• Name simplification analysis
• Error diagnostic analysis

In past releases, these were run serially and in an arbitrary order. This means that unused open statement analysis may run before error diagnostics, thus forcing you to wait longer for an error to appear. We now assign a priority to each analyzer, with error diagnostics set at the highest priority. This means that error messages will appear consistently from a timing perspective. We have also made the unused opens analyzer significant faster than in previous releases.

Additionally, the Unused open statement analyzer has been modified to cache results more efficiently.

We’re quite happy with this change, as it addresses an issue with editor responsiveness that people have been experiencing ever since the release of Visual Studio 2017.

Conclusion

Overall, the 15.7 release of Visual Studio 2017 represents one of the largest performance improvements to F# tooling in Visual Studio in a long time. We are very excited about this because it is the number one issue people have when they use F# for large solutions. We’re looking forward to spending more time on tooling performance in the next year, and doing so not only for Visual Studio, but in the F# Compiler and F# Compiler Service so that all F# tooling in any editor can benefit.

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

The Preview SDK can be downloaded from developer section on Windows Insider.

For feedback and updates to the known issues, please see the developer forum. For new developer feature requests, head over to our Windows Platform UserVoice.

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.
• This build of the Windows SDK will install on Windows 10 Insider Preview and supported Windows operating systems.

Known Issues

The contract Windows.System.SystemManagementContract is not included in this release. In order to access the following APIs, please use a previous Windows IoT extension SDK with your project.

This bug will be fixed in a future preview build of the SDK.

The following APIs are affected by this bug:

namespace Windows.Services.Cortana {
  public sealed class CortanaSettings     
}
namespace Windows.System {
  public enum AutoUpdateTimeZoneStatus
  public static class DateTimeSettings
  public enum PowerState
  public static class ProcessLauncher
  public sealed class ProcessLauncherOptions
  public sealed class ProcessLauncherResult
  public enum ShutdownKind
  public static class ShutdownManager
  public struct SystemManagementContract
  public static class TimeZoneSettings
}

What’s New:

MC.EXE

We’ve made some important changes to the C/C++ ETW code generation of mc.exe (Message Compiler):

The “-mof” parameter is deprecated. This parameter instructs MC.exe to generate ETW code that is compatible with Windows XP and earlier. Support for the “-mof” parameter will be removed in a future version of mc.exe.

As long as the “-mof” parameter is not used, the generated C/C++ header is now compatible with both kernel-mode and user-mode, regardless of whether “-km” or “-um” was specified on the command line. The header will use the _ETW_KM_ macro to automatically determine whether it is being compiled for kernel-mode or user-mode and will call the appropriate ETW APIs for each mode.

• The only remaining difference between “-km” and “-um” is that the EventWrite[EventName] macros generated with “-km” have an Activity ID parameter while the EventWrite[EventName] macros generated with “-um” do not have an Activity ID parameter.

The EventWrite[EventName] macros now default to calling EventWriteTransfer (user mode) or EtwWriteTransfer (kernel mode). Previously, the EventWrite[EventName] macros defaulted to calling EventWrite (user mode) or EtwWrite (kernel mode).

• The generated header now supports several customization macros. For example, you can set the MCGEN_EVENTWRITETRANSFER macro if you need the generated macros to call something other than EventWriteTransfer.
• The manifest supports new attributes.
  • Event “name”: non-localized event name.
  • Event “attributes”: additional key-value metadata for an event such as filename, line number, component name, function name.
  • Event “tags”: 28-bit value with user-defined semantics (per-event).
  • Field “tags”: 28-bit value with user-defined semantics (per-field – can be applied to “data” or “struct” elements).
• You can now define “provider traits” in the manifest (e.g. provider group). If provider traits are used in the manifest, the EventRegister[ProviderName] macro will automatically register them.
• MC will now report an error if a localized message file is missing a string. (Previously MC would silently generate a corrupt message resource.)
• MC can now generate Unicode (utf-8 or utf-16) output with the “-cp utf-8” or “-cp utf-16” parameters.

API Updates and Additions

When targeting new APIs, consider writing your app to be adaptive in order to run correctly on the widest number of Windows 10 devices. Please see Dynamically detecting features with API contracts (10 by 10) for more information.

The following APIs have been added to the platform since the release of 17134.

 namespace Windows.ApplicationModel {
  public sealed class AppInstallerFileInfo
  public sealed class LimitedAccessFeatureRequestResult
  public static class LimitedAccessFeatures
  public enum LimitedAccessFeatureStatus
  public sealed class Package {
    IAsyncOperation<PackageUpdateAvailabilityResult> CheckUpdateAvailabilityAsync();
    AppInstallerFileInfo GetAppInstallerFileInfo();
  }
  public enum PackageUpdateAvailability
  public sealed class PackageUpdateAvailabilityResult
}
namespace Windows.ApplicationModel.Calls {
  public sealed class VoipCallCoordinator {
    IAsyncOperation<VoipPhoneCallResourceReservationStatus> ReserveCallResourcesAsync();
  }
}
namespace Windows.ApplicationModel.Store.Preview.InstallControl {
  public enum AppInstallationToastNotificationMode
  public sealed class AppInstallItem {
    AppInstallationToastNotificationMode CompletedInstallToastNotificationMode { get; set; }
    AppInstallationToastNotificationMode InstallInProgressToastNotificationMode { get; set; }
    bool PinToDesktopAfterInstall { get; set; }
    bool PinToStartAfterInstall { get; set; }
    bool PinToTaskbarAfterInstall { get; set; }
  }
  public sealed class AppInstallManager {
    bool CanInstallForAllUsers { get; }
  }
  public sealed class AppInstallOptions {
    AppInstallationToastNotificationMode CompletedInstallToastNotificationMode { get; set; }
    bool InstallForAllUsers { get; set; }
    AppInstallationToastNotificationMode InstallInProgressToastNotificationMode { get; set; }
    bool PinToDesktopAfterInstall { get; set; }
    bool PinToStartAfterInstall { get; set; }
    bool PinToTaskbarAfterInstall { get; set; }
    bool StageButDoNotInstall { get; set; }
  }
  public sealed class AppUpdateOptions {
    bool AutomaticallyDownloadAndInstallUpdateIfFound { get; set; }
  }
}
namespace Windows.Devices.Enumeration {
  public sealed class DeviceInformationPairing {
    public static bool TryRegisterForAllInboundPairingRequestsWithProtectionLevel(DevicePairingKinds pairingKindsSupported, DevicePairingProtectionLevel minProtectionLevel);
  }
}
namespace Windows.Devices.Lights {
  public sealed class LampArray
  public enum LampArrayKind
  public sealed class LampInfo
  public enum LampPurpose : uint
}
namespace Windows.Devices.Sensors {
  public sealed class SimpleOrientationSensor {
    public static IAsyncOperation<SimpleOrientationSensor> FromIdAsync(string deviceId);
    public static string GetDeviceSelector();
  }
}
namespace Windows.Devices.SmartCards {
  public static class KnownSmartCardAppletIds
  public sealed class SmartCardAppletIdGroup {
    string Description { get; set; }
    IRandomAccessStreamReference Logo { get; set; }
    ValueSet Properties { get; }
    bool SecureUserAuthenticationRequired { get; set; }
  }
  public sealed class SmartCardAppletIdGroupRegistration {
    string SmartCardReaderId { get; }
    IAsyncAction SetPropertiesAsync(ValueSet props);
  }
}
namespace Windows.Devices.WiFi {
  public enum WiFiPhyKind {
    He = 10,
  }
}
namespace Windows.Media.Core {
  public sealed class MediaStreamSample {
    public static MediaStreamSample CreateFromSurface(IDirect3DSurface surface, TimeSpan timestamp);
  }
}
namespace Windows.Media.Devices.Core {
  public sealed class CameraIntrinsics {
    public CameraIntrinsics(Vector2 focalLength, Vector2 principalPoint, Vector3 radialDistortion, Vector2 tangentialDistortion, uint imageWidth, uint imageHeight);
  }
}
namespace Windows.Media.Streaming.Adaptive {
  public enum AdaptiveMediaSourceResourceType {
    MediaSegmentIndex = 5,
  }
}
namespace Windows.Security.Authentication.Web.Provider {
  public sealed class WebAccountProviderInvalidateCacheOperation : IWebAccountProviderBaseReportOperation, IWebAccountProviderOperation
  public enum WebAccountProviderOperationKind {
    InvalidateCache = 7,
  }
  public sealed class WebProviderTokenRequest {
    string Id { get; }
  }
}
namespace Windows.Security.DataProtection {
  public enum UserDataAvailability
  public sealed class UserDataAvailabilityStateChangedEventArgs
  public sealed class UserDataBufferUnprotectResult
  public enum UserDataBufferUnprotectStatus
  public sealed class UserDataProtectionManager
  public sealed class UserDataStorageItemProtectionInfo
  public enum UserDataStorageItemProtectionStatus
}
namespace Windows.Services.Store {
  public sealed class StoreContext {
    IAsyncOperation<StoreRateAndReviewResult> RequestRateAndReviewAppAsync();
  }
  public sealed class StoreRateAndReviewResult
  public enum StoreRateAndReviewStatus
}
namespace Windows.Storage.Provider {
  public enum StorageProviderHydrationPolicyModifier : uint {
    AutoDehydrationAllowed = (uint)4,
  }
}
namespace Windows.System {
  public sealed class LauncherUIOptions {
    ViewGrouping GroupingPreference { get; set; }
  }
namespace Windows.UI.Composition {
  public enum CompositionBatchTypes : uint {
    AllAnimations = (uint)5,
    InfiniteAnimation = (uint)4,
  }
  public sealed class CompositionGeometricClip : CompositionClip
  public sealed class Compositor : IClosable {
    CompositionGeometricClip CreateGeometricClip();
  }
}
namespace Windows.UI.Core {
  public sealed class SystemNavigationManager {
    bool DoesBackButtonReduceViewBounds { get; }
  }
}
namespace Windows.UI.Notifications {
  public sealed class ScheduledToastNotification {
    public ScheduledToastNotification(DateTime deliveryTime);
    IAdaptiveCard AdaptiveCard { get; set; }
  }
  public sealed class ToastNotification {
    public ToastNotification();
    IAdaptiveCard AdaptiveCard { get; set; }
  }
}
namespace Windows.UI.Shell {
  public sealed class TaskbarManager {
    IAsyncOperation<bool> IsSecondaryTilePinnedAsync(string tileId);
    IAsyncOperation<bool> RequestPinSecondaryTileAsync(SecondaryTile secondaryTile);
    IAsyncOperation<bool> TryUnpinSecondaryTileAsync(string tileId);
  }
}
namespace Windows.UI.StartScreen {
  public sealed class StartScreenManager {
    IAsyncOperation<bool> ContainsSecondaryTileAsync(string tileId);
    IAsyncOperation<bool> TryRemoveSecondaryTileAsync(string tileId);
  }
}
namespace Windows.UI.ViewManagement {
  public sealed class ApplicationView {
    bool IsTabGroupingSupported { get; }
  }
  public enum ViewGrouping
  public sealed class ViewModePreferences {
    ViewGrouping GroupingPreference { get; set; }
  }
}
namespace Windows.UI.ViewManagement.Core {
  public sealed class CoreInputView {
    bool TryHide();
    bool TryShow();
    bool TryShow(CoreInputViewKind type);
  }
  public enum CoreInputViewKind
}
namespace Windows.UI.Xaml.Controls {
  public class NavigationView : ContentControl {
    bool IsTopNavigationForcedHidden { get; set; }
    NavigationViewOrientation Orientation { get; set; }
    UIElement TopNavigationContentOverlayArea { get; set; }
    UIElement TopNavigationLeftHeader { get; set; }
    UIElement TopNavigationMiddleHeader { get; set; }
    UIElement TopNavigationRightHeader { get; set; }
  }
  public enum NavigationViewOrientation
  public sealed class PasswordBox : Control {
    bool CanPasteClipboardContent { get; }
    public static DependencyProperty CanPasteClipboardContentProperty { get; }
    void PasteFromClipboard();
  }
  public class RichEditBox : Control {
    RichEditTextDocument RichEditDocument { get; }
  }
  public sealed class RichTextBlock : FrameworkElement {
    void CopySelectionToClipboard();
  }
  public class SplitButton : ContentControl
  public sealed class SplitButtonClickEventArgs
  public enum SplitButtonOrientation
  public sealed class TextBlock : FrameworkElement {
    void CopySelectionToClipboard();
  }
  public class TextBox : Control {
    bool CanPasteClipboardContent { get; }
    public static DependencyProperty CanPasteClipboardContentProperty { get; }
    bool CanRedo { get; }
    public static DependencyProperty CanRedoProperty { get; }
    bool CanUndo { get; }
    public static DependencyProperty CanUndoProperty { get; }
    void CopySelectionToClipboard();
    void CutSelectionToClipboard();
    void PasteFromClipboard();
    void Redo();
    void Undo();
  }
  public sealed class WebView : FrameworkElement {
    event TypedEventHandler<WebView, WebViewWebResourceRequestedEventArgs> WebResourceRequested;
  }
  public sealed class WebViewWebResourceRequestedEventArgs
}
namespace Windows.UI.Xaml.Controls.Primitives {
  public class FlyoutBase : DependencyObject {
    FlyoutShowMode ShowMode { get; set; }
    public static DependencyProperty ShowModeProperty { get; }
    public static DependencyProperty TargetProperty { get; }
    void Show(FlyoutShowOptions showOptions);
  }
  public enum FlyoutPlacementMode {
    BottomLeftJustified = 7,
    BottomRightJustified = 8,
    LeftBottomJustified = 10,
    LeftTopJustified = 9,
    RightBottomJustified = 12,
    RightTopJustified = 11,
    TopLeftJustified = 5,
    TopRightJustified = 6,
  }
  public enum FlyoutShowMode
  public sealed class FlyoutShowOptions : DependencyObject
}
namespace Windows.UI.Xaml.Hosting {
  public sealed class XamlBridge : IClosable
}
namespace Windows.UI.Xaml.Markup {
  public sealed class FullXamlMetadataProviderAttribute : Attribute
}
 

The post Windows 10 SDK Preview Build 17661 now available! appeared first on Windows Developer Blog.

Last year in the Windows 10 Fall Creators Update, we introduced Eye Control, an experience that allows customers to control Windows using only their eyes. We continue to design with individuals like Steve Gleason in mind, and always challenge ourselves to build products that create positive change. We understand, however, that fulfilling our mission statement – “to empower every person and organization on the planet to achieve more” – goes beyond the product alone. It starts with something more foundational: building a platform to empower all developers to create products and experiences that can help improve people’s lives and make a positive impact.

Today, we are excited to share the next step in our eye tracking journey. In addition to sharing improvements to Eye Control and broader eye tracker hardware support, we are announcing Windows eye tracking APIs and open-source code to enable app developers to build more accessible and immersive app experiences with eye tracking.

Let’s dive into the details.

New features for Eye Control

Since the launch of Eye Control, we have continued to work with Microsoft Research and people living with ALS (amyotrophic lateral sclerosis) or MND. We’ve listened to customer feedback to help make the product better for people with ALS, and for people everywhere who can benefit from using their eyes to control Windows. This feedback has influenced the next set of features we have added to Eye Control, advancing another step towards being in full control of your PC using only your eyes. Here are the three areas we are updating based on this feedback and collaboration:

• Navigate more easily: We have added more ways to better control the mouse, like the ability to scroll any app or website, as well as the ability to more quickly click content.
• Get there quick: Accelerate to common tasks with quick access to Start, Task View, device calibration, and Eye Control settings, all quickly accessible from the Eye Control launchpad.
• Pause when you need to: Pause the launchpad when watching a movie, reading, or taking a break, to help avoid accidental interactions with your eyes

Eye Control launchpad in Windows 10 April 2018 Update

Eye Control is still in preview, and your feedback can help make it better. If you have feedback on how we can improve our products and services, you can use the Accessibility User Voice Forum or the Windows Feedback Hub. For help with Eye Control, contact the Disability Answer Desk.

Broader eye tracking hardware support

Last year, we announced our collaboration with Tobii to bring eye tracking hardware support to Windows on their range of accessibility and gaming eye trackers. Today, we are announcing our second eye tracking partner, EyeTech, to bring support to Windows as well.

Our goal is to support a breadth of eye tracking hardware on Windows, so customers can pick the device that works best for their needs and preferences. All of these eye tracking devices will work with Eye Control and the Windows eye tracking APIs so developers can build an app once and have it work with all supported hardware. We are continuing to work with the hardware ecosystem and hope to have additional partners to announce later this year. We look forward to seeing more eye tracker vendors bring broader hardware support to customers.

Introducing new Windows eye tracking APIs

On top of the Eye Control improvements and broader eye tracking hardware support, we are excited to introduce new platform tools to empower all developers to be a part of the eye tracking journey.

The Windows 10 April 2018 Update includes Windows eye tracking APIs – the same set of APIs we use to build Eye Control. These APIs provide a stream of eye tracking data that indicates where the user is looking within the bounds of the application’s window. We are also releasing an open-source Gaze Interaction Library in the Windows Community Toolkit to make it even easier to integrate gaze interactions into your UWP apps. We are starting to collaborate with partners like Tobii and EyeTech on this open-source library, and we welcome contributions from the eye tracking developer community.

We are already starting to see partners put our Windows APIs into action for accessibility apps. One great example is Snap + Core First by Tobii Dynavox, a symbol-based communication app to help more people easily communicate. We are also seeing eye tracking interactions create richer and more immersive gaming experiences. And with the support of UWP integration with Unity, you can leverage these APIs in your new or existing UWP Unity game.

With the release of these APIs, we are making sure customers are in control of their privacy. The first time an app needs to access a customer’s eye tracker, it requests their permission. Additionally, an app can only get access to eye tracking data that is within the app.  Remember, if your app collects, stores or transfers eye tracking data, you must describe this in your app’s privacy statement. You can learn more about how we handle privacy on our eye tracking privacy page.

Start developing!

We look forward to working with developers to enable a rich ecosystem of apps and experiences with eye tracking, and are excited to see what you all create. Here are some resources to help get started:

Documentation

• Walkthrough of the Windows eye tracking APIs
• Walkthrough of the Gaze Interaction Library
• Getting started with UWP & Unity

API Reference / Code

• Windows eye tracking APIs
• Gaze Interaction Library on GitHub

We will be at Build showcasing these APIs, eye tracking hardware, Eye Control, and apps & experiences. If you are attending Build, please come find our booth to talk to us and learn more! For more on this and accessibility @ Microsoft in general, please check out www.microsoft.com/accessibility.

The post How to create accessible apps and immersive game experiences with new eye tracking APIs appeared first on Windows Developer Blog.

Today, we are releasing the May 2018 Security and Quality Rollup.

Security

CVE-2018-1039 – Windows Security Feature Bypass Vulnerability

A security feature bypass vulnerability exists in Windows which could allow an attacker to bypass Device Guard. An attacker who successfully exploited this vulnerability could circumvent a User Mode Code Integrity (UMCI) policy on the machine. To exploit the vulnerability, an attacker would first have to access the local machine, and then run a malicious program. The update addresses the vulnerability by correcting how Windows validates User Mode Code Integrity policies

CVE-2018-1039

CVE-2018-0765 – .NET and .NET Core Denial Of Service Vulnerability

A Denial of Service vulnerability exists when .NET, and .NET core, improperly process XML documents. An attacker who successfully exploited this vulnerability could cause a denial of service against a .NET application. A remote unauthenticated attacker could exploit this vulnerability by issuing specially crafted requests to a .NET(or .NET core) application.

The update addresses the vulnerability by correcting how a .NET, and .NET core, applications handles XML document processing.

CVE-2018-0765

Quality and Reliability

This release contains no new following quality and reliability improvements.

Getting the Update

The Security and Quality Rollup is available via Windows Update, Windows Server Update Services, Microsoft Update Catalog, and Docker.

Microsoft Update Catalog

You can get the update via the Microsoft Update Catalog. For Windows 10, .NET Framework updates are part of the Windows 10 Monthly Rollup.

The following table is for Windows 10 and Windows Server 2016+.

The following table is for earlier Windows and Windows versions.

Docker Images

We are updating the following .NET Framework Docker images for today’s release:

• microsoft/aspnet
• microsoft/dotnet-framework
• microsoft/dotnet-framework-samples

Note: Look at the “Tags” view in each repository to see the updated Docker image tags.

Previous Monthly Rollups

The last few .NET Framework Monthly updates are listed below for your convenience:

• February 2018 Security and Quality Rollup
• January 2018 Preview of Quality Rollup
• January 2018 Security and Quality Rollup
• November 2017 Security and Quality Rollup