Today, we are sharing the general availability of Microsoft Azure Backup’s solution for SAP HANA databases in the UK South region.
Azure Backup is Azure's native backup solution, which is BackIntcertified by SAP. This offering aligns with Azure Backup’s mantra of zero-infrastructure backups, eliminating the need to deploy and manage backup infrastructure. You can now seamlessly backup and restore SAP HANA databases running on Microsoft Azure Virtual Machines (VM) — M series Virtual Machine is also supported, and leverage enterprise management capabilities that Azure Backup provides.
Benefits
15-minute Recovery Point Objective (RPO): Recovery of critical data of up to 15 minutes is possible.
One-click, point-in-time restores: Easy to restore production data on SAP HANA databases to alternate servers. Chaining of backups and catalogs to perform restores is all managed by Azure behind the scenes.
Long-term retention: For rigorous compliance and audit needs, you can retain your backups for years, based on the retention duration, beyond which the recovery points will be pruned automatically by the built-in lifecycle management capability.
Backup Management from Azure:Use Azure Backup’s management and monitoring capabilities for improved management experience.
Watch this space for more updates on GA rollout to other regions. We are currently in preview in these Azure geos.
Getting started
We are working on making the SAP HANA backup experience even better. Find out the scenarios we support today.
Over a million on-premises SQL Server databases have moved to Azure, representing a massive shift in where customers are collecting, storing, and analyzing their data.
Modernizing your databases provides the opportunity to transform your data architecture. SQL Server on Azure Virtual Machines allows you to maintain control over your database and operating system while still benefiting from cloud flexibility and scale. For some, this represents a step in the journey to a fully-managed database, while others choose this deployment option for compatibility with on-premises workloads such as SQL Server Reporting Services.
Whatever the reason, migrating SQL workloads to Azure Virtual Machines is a popular option. Azure customers benefit from our unique built-in security and manageability capabilities, which automate tasks like patching and backups. In addition to providing these unparalleled innovations, it is important to provide customers with the best price-performance possible. Once again, SQL Server on Azure Virtual Machines comes out on top.
SQL Server on Azure leads in price-performance
GigaOm, an independent research firm, recently published a study comparing throughput performance between SQL Server on Azure Virtual Machines and SQL Server on AWS EC2. Azure emerged as the clear leader across both Windows and Linux for mission-critical workloads, up to3.4 times faster and up to 87 percent less expensive than AWS EC2.1
The images above are performance and price-performance comparisons from the GigaOm report. The performance metric is throughput (transactions per second, tps); higher performance is better. The price-performance metric is three-year pricing divided by throughput (transactions per second, tps), lower price-performance is better.
With Azure Ultra Disk, GigaOm was able to achieve 80,000 input or output per second (IOPS) per single disk, maxing out the virtual machine’s throughput limit, and well exceeding the capabilities of AWS provisioned IOPS.2
A key reason why Azure price-performance is superior to AWS is Azure BlobCache, whichprovides free reads. Given that most online transaction processing (OLTP) workloads today come with a ten-to-one read-to-write ratio, this provides customers with significant savings.
Unmatched innovation from the team that brought SQL Server to the world
With a proven track record over 25 years, the engineering team behind SQL Server continues to drive security and innovation to meet our customers’ changing needs. Whether executing on-premises, in the cloud, or on the edge, the result is the most comprehensive, consistent, and secure solution for your data.
Migrate from SQL Server on-premises to SQL Server 2019 in Azure Virtual Machines today. Get started with preconfigured Azure SQL Virtual Machine images on Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu, and Windows in minutes. Take advantage of the Azure Hybrid Benefit to reuse your existing on-premises Windows server and SQL Server licenses in Azure for significant savings.
1Price-performance claims based on data from a study commissioned by Microsoft and conducted by GigaOm in October 2019. The study compared price performance between SQL Server 2017 Enterprise Edition on Windows Server 2016 Datacenter edition in Azure E64s_v3 instance type with 4x P30 1TB Storage Pool data (Read-Only Cache) + 1x P20 0.5TB log (No Cache) and the SQL Server 2017 Enterprise Edition on Windows Server 2016 Datacenter edition in AWS EC2 r4.16xlarge instance type with 1x 4TB gp2 data + 1x 1TB gp2 log. Benchmark data is taken from a GigaOm Analytic Field Test derived from a recognized industry standard, TPC Benchmark™ E (TPC-E). The Field Test does not implement the full TPC-E benchmark and as such is not comparable to any published TPC-E benchmarks. The Field Test is based on a mixture of read-only and update intensive transactions that simulate activities found in complex OLTP application environments. Price-performance is calculated by GigaOm as the cost of running the cloud platform continuously for three years divided by transactions per second throughput. Prices are based on publicly available US pricing in West US for SQL Server on Azure Virtual Machines and Northern California for AWS EC2 as of October 2019. The pricing incorporates three-year reservations for Azure and AWS compute pricing, and Azure Hybrid Benefit for SQL Server and Azure Hybrid Benefit for Windows Server and License Mobility for SQL Server in AWS, excluding Software Assurance costs. Price-performance results are based upon the configurations detailed in the GigaOm Analytic Field Test. Actual results and prices may vary based on configuration and region.
2Claims based on data from a study commissioned by Microsoft and conducted by GigaOm in October 2019. The study compared price-performance between SQL Server 2017 Enterprise Edition on Windows Server 2016 Datacenter edition in Azure E64s_v3 instance type with 1x Ultra 1.5TB with 650MB per sec throughput and the SQL Server 2017 Enterprise Edition on Windows Server 2016 Datacenter edition in AWS EC2 r4.16xlarge instance type with 1x 1.5TB io1 provisioned log + data. Benchmark data is taken from a GigaOm Analytic Field Test derived from a recognized industry standard, TPC Benchmark™ E (TPC-E). The Field Test does not implement the full TPC-E benchmark and as such is not comparable to any published TPC-E benchmarks. The Field Test is based on a mixture of read-only and update intensive transactions that simulate activities found in complex OLTP application environments. Price-performance is calculated by GigaOm as the cost of running the cloud platform continuously for three years divided by transactions per second throughput. Prices are based on publicly available US pricing in north Europe for SQL Server on Azure Virtual Machines and Ireland for AWS EC2 as of October 2019. Price-performance results are based upon the configurations detailed in the GigaOm Analytic Field Test. Actual results and prices may vary based on configuration and region.
Today, we’re excited to announce some improvements to our tracking prevention feature that have started rolling out with Microsoft Edge 79. In our last blog post about tracking prevention in Microsoft Edge, we mentioned that we are experimenting with ways that our Balanced mode can be further improved to provide even greater privacy protections by default without breaking sites. We are looking to strike a balance between two goals:
Blocking more types of trackers – Microsoft Edge’s tracking prevention feature is powered by Disconnect’s tracking protection lists. We wanted to build off our initial implementation of tracking prevention in Microsoft Edge 78 and maximize the protections we offered by default by exploring blocking other categories of trackers (such as those in the Content category) in Balanced mode. These changes resulted in Microsoft Edge 79 blocking ~25% more trackers than Microsoft Edge 78.
Maintaining compatibility on the web – We knew that blocking more categories of trackers (especially those in the Content category) had the potential to break certain web workflows such as federated login or embedded social media content.
We learned through experimentation that it is possible to manage these tradeoffs by relaxing tracking prevention for organizations with which a user has established a relationship. To determine this list, we built on-device logic that combines users’ personal site engagement scores with the observation that some organizations own multiple domains that they use to deploy functionality across the web. It’s worth mentioning that this compatibility mitigation only applies to Balanced mode; Strict mode will continue to block the largest set of trackers without any mitigations.
Site engagement
The Chromium project’s site engagement score is a measure of how engaged a specific user is with a specific site. Site engagement scores can range from 0 (meaning a user has no relationship with a site) to 100 (meaning that a user is extremely engaged with a site). Activities such as browsing to a site repeatedly/over several days, spending time interacting with a site, and playing media on a site all cause site engagement scores to increase, whereas not visiting a site causes site engagement scores to decay exponentially over time. You can view your own site engagement scores by navigating to edge://site-engagement.
It’s also worth noting that site engagement scores are computed on your device and never leave it. This means that they are not synced across your devices or sent to Microsoft at any time.
Through local experimentation, we found that a site engagement score of 4.1 was a suitable threshold to define a site that a user has an active relationship with. While this value is subject to change based on user feedback and future experiments, it was selected as an initial value for two reasons:
It is low enough to ensure successful interactions with a site that a user has not previously had a history of engagement with.
It is high enough to ensure that sites a user visits infrequently will drop off the list relatively quickly.
While site engagement helps signal which sites are important to individual users, allowing third party storage access/resource loads from only these sites would not consider the fact that organizations can serve content that users care about from multiple domains, which can still result in site breakages.
Combining site engagement with organizations
In our last blog post about tracking prevention, we introduced the concept of an organization, that is, a single company that can own multiple domains related to their business (such as Org1 owning “org1.test” and “org1-cdn.test”). We also shared that in order to keep sites working smoothly, our tracking prevention implementation groups such domains together and exempts storage/resource blocks when a domain in one organization requests resources from another domain in that same organization.
In order to keep sites that users engage with working as expected while also increasing the types of trackers that we block by default, we combined the concept of an organization together with site engagement to create a new mitigation. This mitigation takes effect whenever a user has established an ongoing relationship with a given site (currently defined by a site engagement score of 4.1 or greater). For example, consider the following organization which owns two domains:
Social Org
social.example
social-videos.example
A user will be considered to have a relationship with Social Org if they have established a site engagement score of at least 4.1 with any one of its domains.
If another site, content-embedder.example, includes third-party content (say an embedded video from social-videos.example) from any of Social Org’s domains that would normally be restricted by tracking prevention, it will be temporarily allowed as long as the user’s site engagement score with Social Org’s domains is maintained above the threshold.
If a site does not belong to an organization, a user will need to establish a site engagement score of at least 4.1 with it directly before any storage access/resource load blocks imposed by tracking prevention will be lifted.
What does this mean?
By exempting sites and organizations that you have an ongoing and established relationship with from tracking prevention, we can ensure that the web services and applications you care about continue to work as you expect across the web. Leveraging site engagement also allows us to only unblock content that is likely to be important to you and reflects your current needs. This ensures that actions such as briefly visiting a site or seeing a popup aren’t enough to unblock content by themselves. If content does get unblocked due to you interacting with a site, it is always unblocked in a temporary manner that is proportional to how highly engaged you are with that site/its parent organization. By combining these exemptions with more strict blocking of trackers by default, we can provide higher levels of protection while still maintaining compatibility on the ever-evolving set of sites that you engage with.
It’s worth noting that tracking prevention, when enabled, will always block storage access and resource loads for sites that fall into the Fingerprinting or Cryptomining categories on Disconnect’s tracking protection lists. We will also not apply the site engagement-based mitigation outlined above for our most privacy-minded users who opt into tracking prevention’s Strict mode.
Putting everything together: What’s changed?
The best way to learn what’s changed with tracking prevention in Microsoft Edge 79 is to take a look at the table below:
Along the top are the categories of trackers as defined by Disconnect’s tracking protection list categories.
Along the left side are comparisons of the improvements made to our tracking prevention feature broken down into Basic, Balanced, and Strict.
The letter “S” in a cell denotes that storage access is blocked.
The letter “B” in a cell denotes that both storage access and resource loads (i.e. network requests) are blocked.
A “-“ in a cell denotes that no block will be applied to either storage access or resource loads.
The “Same-Org Mitigation” refers to the first mitigation that we introduced in our previous blog post and recapped above.
The “Org Engagement Mitigation” refers to the second mitigation based on site engagement that we introduced earlier in this post.
Advertising
Analytics
Content
Cryptomining
Fingerprinting
Social
Other
Same Org Mitigation
Org Engagement Mitigation
Basic
Microsoft Edge 78
–
–
–
B
B
–
–
Enabled
Not impl.
Microsoft Edge 79
–
–
–
B
B
–
–
Enabled
N/A
Balanced
Microsoft Edge 78
S
–
–
B
B
S
–
Enabled
Not impl.
Microsoft Edge 79
S
–
S
B
B
S
S
Enabled
Enabled1
Strict2
Microsoft Edge 78
B
B
–
B
B
B
B
Enabled
Not impl.
Microsoft Edge 79
B
B
S
B
B
B
B
Enabled
Disabled
Does not apply to Cryptomining or Fingerprinting categories.
Strict mode blocks more resource loads than Balanced. This can result in Strict mode appearing to block less tracking requests than Balanced since the trackers making the requests are never even loaded to begin with.
With our recent updates in Microsoft Edge 79, we have seen, on average, 25% more trackers blocked in Balanced mode. Close monitoring of user feedback and engagement time also showed no signs of negative compatibility impact, suggesting that the org engagement mitigation is effective at minimizing breakage on sites that users actively engage with. While this does mean that top sites have the org engagement mitigation applied more often, we believe this is an acceptable tradeoff versus compatibility, especially as more top sites are starting to give users mechanisms to transparently view, control, and delete their data.
As with all our features, we’ll continue to monitor telemetry and user feedback channels to learn more and continually improve tracking prevention in future releases. We are also exploring additional compatibility mitigations such as the Storage Access API, which we intend to experiment with in a future version of Microsoft Edge.
InPrivate Changes
In our previous blog post, we mentioned that users browsing in InPrivate will automatically get Strict mode protections. By listening to the feedback our users provided, we found that this led to unexpected behavior (such as causing sites that worked in a normal browsing window to fail to load InPrivate) and broke some important use cases. That’s why in Microsoft Edge 79, your current tracking prevention settings will be carried over to InPrivate sessions.
We are currently experimenting in our Canary and Dev channels with a switch at the bottom of our settings panel (which you can reach by navigating to edge://settings/privacy) that will allow you to re-enable Strict mode protections InPrivate by default:
See blocked trackers
We’ve also made it easier for you to view the trackers that Microsoft Edge has blocked for you. Navigate to edge://settings/privacy/blockedTrackers to test out this new experience today!
Send us feedback
We’d love to hear your thoughts on our next iteration of tracking prevention. If something looks broken, or if you have feedback to share on these changes, we’d love to hear from you. Please send us feedback using the “smiley face” in the top right corner of the browser.
Send feedback at any time with the Send a Smile button in Microsoft Edge
As always, thanks for being a part of this journey towards a more private web!
– Scott Low, Senior Program Manager
– Brandon Maslen, Senior Software Engineer
This post was co-authored by Omar Aftab, Partner Director of Program Management, Power Virtual Agents.
Conversational artificial intelligence (AI) is enabling organizations to improve their business in areas like customer service and employee engagement by automating some of the most commonly requested services, which frees up employees to take on more value-adding activities. While the benefits of conversational AI are well established, determining who in an organization should build these solutions is not always clear.
As is true of many applications, conversational AI solutions (or bots) can be built using software-as-a-service (SaaS) or platform-as-a-service (PaaS) offerings. Consequently, organizations are forced to decide between empowering business users who are closest to the business problems or empowering developers with coding experience to have full control over how these solutions are built, without many options to bridge the gap and allow for collaboration between the two. However, with the integration of Bot Framework Skills into Microsoft Power Virtual Agents (a graphical interface offering for business users creating bots, now generally available), Microsoft uniquely empowers both business users and developers to collaborate seamlessly in building conversational AI solutions.
In the bot building journey, bot builders across the organization should not work in siloes. If a business user is building a bot but wants to add a nuanced scenario, they should be able to collaborate with a developer who can customize the bot further. Similarly, developers building a bot can also leverage bots that have been built by business users as a skill.
Microsoft offers an end-to-end, no-cliffs bot building experience with Power Virtual Agents and Bot Framework.
Power Virtual Agents provides a no-code experience for bot development – ideal for business users and domain experts to easily build a bot, without having to worry about the technical aspects of bot development.
Bot Framework is an open-source SDK and tools purpose-built for bot development – ideal for developers who want to build a bot using a code experience and want full control of technical aspects of bot development, including language model ownership, and visual design. Additionally, Azure Bot Service allows developers to host and deploy their bots to popular channels like Teams and other messaging platforms where users will interact with the bot.
Bot Framework Skills offering a no-cliffs bot building experience – no matter your starting point. With Bot Framework Skills, Power Virtual Agents users have a no-cliff bot building experience because they can collaborate with Bot Framework developers to extend their bots with custom capabilities. Equally important, Bot Framework developers can extend their bot as a skill and allow subject matter experts to update bot conversations.
For example, suppose an organization is creating a travel bot using Power Virtual Agents. The business users build out the dialogs with a UI-based experience that allows the bot to handle customers’ intents, such as Check miles and rewards, Check flight status, Update account information, and Book a flight.
However, what if someone in the organization has already built a Book a Flight skill with custom language models using Bot Framework and Language Understanding service as illustrated below?
In this scenario, business experts can collaborate with the developer who has built this flight booking skill by selecting it as an action in Power Virtual Agents.
As conversational AI adoption continues to grow, we believe it is important for organizations to take an interdisciplinary team approach to bot development. For this reason, Microsoft offers an end-to-end, no-cliffs bot building experience that empowers business subject matter experts and developers alike to collaborate.
Many customers have questions when it comes to managing cloud operations. How can I implement real-time cloud governance at scale? What’s the best way to monitor my cloud workloads? How can I get help when I need it?
Azure offers a great deal of guidance when it comes to optimizing your cloud operations. At the organizational level, the Microsoft Cloud Adoption Framework for Azure can help you design and implement your approach to management and governance in the cloud. At the cloud resource level, Azure Advisor provides personalized recommendations to help you optimize your Azure workloads for a variety of objectives—including cost savings, security, performance, and availability—based on your usage and configurations.
Recently, Advisor introduced a new recommendation category—operational excellence—to help you follow best practices for process and workflow efficiency, resource manageability, and deployment.
Introducing a new Azure Advisor recommendation category: operational excellence
Azure Advisor now offers a new category of recommendations—operational excellence—to help you optimize your cloud process and workflow efficiency, resource manageability, and deployment practices. You can get these recommendations from Advisor in the operational excellence tab of the Advisor dashboard. They’re also available via Advisor’s CLI and API.
The operational excellence category is launching with nine recommendations, and more on the way. Examples include creating Azure Service Health alerts to be notified when Azure service issues affect you; repairing invalid log alert rules; and following best practices using Azure policy, such as tag management, geo-compliance requirements, and specifying permitted virtual machine (VM) SKUs for deployment. Together, these recommendations will help you optimize your cloud operations practices.
New operational excellence recommendations
Here’s a quick round-up of the new operational excellence recommendations in Advisor at launch:
Create Azure Service Health alerts to be notified when Azure service issues affect you.
Design your storage accounts to prevent hitting the maximum subscription limit.
Ensure you have access to Azure cloud experts when you need it.
Repair invalid log alert rules.
Follow best practices using Azure Policy, including tag management, geo-compliance requirements, and VM audits for managed disks.
For more detailed information on Advisor’s operational excellence recommendations, refer to our documentation. Be sure to check back regularly, as we’re constantly adding new recommendations.
Review your operational excellence recommendations today
Visit Advisor in the Azure portal here to start optimizing your cloud workloads for operational excellence. For more in-depth guidance, visit our documentation. Let us know if you have a suggestion for Advisor by submitting an idea here.
Since the general availability of Azure Data Lake Storage Gen2 in February 2019, customers have been getting insights at cloud scale faster than ever before. Integration to analytics engines is critical for their analytics workloads and equally important is the ability to programmatically ingest, manage, and analyze data. This ability is critical for key areas of enterprise data lakes such as data ingestion, event-driven big data platforms, machine learning, and advanced analytics. Programmatic access is possible today using Azure Data Lake Storage Gen2 REST APIs or Blob REST APIs. In addition, customers can enable continuous integration and continuous delivery (CI/CD) pipelines using Blob PowerShell and CLI capabilities via multi-protocol access. As part of the journey to enable our developer ecosystem, our goal is to make customer application development easier than ever before.
We are excited to announce the public preview of .NET SDK, Python SDK, Java SDK, PowerShell, and CLI for filesystem operations for Azure Data Lake Storage Gen2. Customers who are used to the familiar filesystem programming model can now implement this model using .NET, Python, and Java SDKs. Customers can also now incorporate these filesystem operations into their CI/CD pipelines using PowerShell and CLI, thereby enriching CI/CD pipeline automation for big data workloads on Azure Data Lake Storage Gen2. As part of this preview, the SDKs, PowerShell, and CLI include support for CRUD operations for filesystems, directories, files, and permissions through filesystem semantics for Azure Data Lake Storage Gen2.
Detailed reference documentation for all these filesystem semantics are provided in the links below. These links will also help you get started and provide feedback.
This public preview is available globally in all regions. Your participation and feedback are critical to help us enrich your development experience. Join us in our journey.
When workers have a modern workplace experience that is connected, flexible, and empowering, it sends a clear signal that they’re valued and they work for a forward-leaning organization. Learn how data from Qualtrics helped a few organizations quantify employee sentiment and demonstrate the value of the modern workplace.
We’re excited to announce the release of .NET Core 3.1. It’s really just a small set of fixes and refinements over .NET Core 3.0, which we released just over two months ago. The most important feature is that .NET Core 3.1 is an long-term supported (LTS) release and will be supported for three years. As we’ve done in the past, we wanted to take our time before releasing the next LTS release. The extra two months (after .NET Core 3.0) allowed us to select and implement the right set of improvements over what was already a very stable base. .NET Core 3.1 is now ready to be used wherever your imagination or business need takes it.
ASP.NET Core and EF Core are also being released today.
Visual Studio 2019 16.4 was also released today and includes .NET Core 3.1. It is a required update to use .NET Core 3.1 with Visual Studio. For Visual Studio 2019 users, we recommend simply updating Visual Studio to 16.4 and instead of separately downloading .NET Core 3.1.
Visual Studio for Mac also supports and includes .NET Core 3.1, in the Visual Studio for Mac 8.4 Preview channel. You will need to opt into the Preview channel to use .NET Core 3.1.
Release notes:
.NET Core 3.0 release notes
.NET Core 2.2 -> 3.0 API diff
.NET Core 3.0 contributor list
GitHub release
GitHub issue for .NET Core 3.0 issues
The changes in .NET Core 3.1 were primarily focussed on Blazor and Windows Desktop, the two new and large additions in .NET Core 3.0. This includes support for C++/CLI, which has been a regular request for developers targeting Windows.
Before we take a look at what’s new in .NET Core 3.1, let’s take a quick look at the key improvements in .NET Core 3.0, which is the bulk of what’s important to consider for .NET Core 3.1.
Recap of .NET Core 3.0 Improvements
The following key improvements were delivered in .NET Core 3.0. We’ve already heard from developers of big sites that it is working super well for them.
.NET Core 3.0 is already battle-tested by being hosted for months at dot.net and on Bing.com. Many other Microsoft teams will soon be deploying large workloads on .NET Core 3.1 in production.
C# 8 add async streams, range/index, more patterns, and nullable reference types. Nullable enables you to directly target the flaws in code that lead to NullReferenceException. The lowest layer of the framework libraries has been annotated, so that you know when to expect null.
F# 4.7 focuses on making some thing easier with implicit yield expressions and some syntax relaxations. It also includes support for LangVersion, and ships with nameof and opening of static classes in preview. The F# Core Library now also targets .NET Standard 2.0. You can read more at Announcing F# 4.7.
.NET Standard 2.1 increases the set of types you can use in code that can be used woth both .NET Core and Xamarin. .NET Standard 2.1 includes types since .NET Core 2.1.
Windows Desktop apps are now supported with .NET Core, for both Windows Forms and WPF (and open source). The WPF designer is part of Visual Studio 2019. The Windows Forms designer is in preview and available as a download.
.NET Core apps now have executables by default. In past releases, apps needed to be launched via the dotnet command, like dotnet myapp.dll. Apps can now be launched with an app-specific executable, like myapp or ./myapp, depending on the operating system.
High performance JSON APIs have been added, for reader/writer, object model and serialization scenarios. These APIs were built from scratch on top of Span<T> and use UTF8 under the covers instead of UTF16 (like string). These APIs minimize allocations, resulting in faster performance, and much less work for the garbage collector. See Try the new System.Text.Json APIs.
The garbage collector uses less memory by default, often a lot less. This improvement is very beneficial for scenarios where many applications are hosted on the same server. The garbage collector has also been updated to make better use of large numbers of cores, on machines with >64 cores. See Making CPU configuration better for GC on machines with > 64 CPUs.
Raspberry Pi and ARM chips are now supported to enable IoT development, including with the remote Visual Studio debugger. You can deploy apps that listen to sensors, and print messages or images on a display, all using the new GPIO APIs. ASP.NET can be used to expose data as an API or as a site that enables configuring an IoT device.
Platform support
.NET Core 3.1 is supported on the following operating systems:
Alpine: 3.9+
Debian: 9+
openSUSE: 42.3+
Fedora: 26+
Ubuntu: 16.04+
RHEL: 6+
SLES: 12+
macOS: 10.13+
Windows Client: 7, 8.1, 10 (1607+)
Windows Server: 2012 R2 SP1+
Note: Windows Forms and WPF apps are only functional and supported on Windows.
Chip support follows:
x64 on Windows, macOS, and Linux
x86 on Windows
ARM32 on Windows and Linux
ARM64 on Linux (kernel 4.14+)
Note: Please ensure that .NET Core 3.1 ARM64 deployments use Linux kernel 4.14 version or later. For example, Ubuntu 18.04 satisfies this requirement, but 16.04 does not.
Windows Forms Controls Removal
The following Windows Forms controls have been removed from .NET Core 3.1:
DataGrid
ToolBar
ContextMenu
Menu
MainMenu
MenuItem
These controls were replaced with more powerful controls in .NET Framework 2.0, back in 2005. They have not been available by default in the Visual Studio Designer Toolbox for many years. As a result, we decided to remove these controls and focus only on the new ones.
Yes, this is an unfortunate breaking change. You will see build breaks if you are using the controls we removed in your applications. Also, if you open .NET Core 3.0 applications in the latest versions of the .NET Core Windows Forms designer, you will see errors if you are using these controls.
We recommend you update your applications to .NET Core 3.1 and move to the alternative controls. Replacing the controls is a straight-forward process, essentially “find and replace”.
First, we should have made these changes before we released .NET Core 3.0, and we appologize for that. We try to avoid late changes, and even more for breaking changes, and it pains us to make this one.
As we got further into the Windows Forms designer project, we realized that these controls were not aligned with creating modern applications and should never have been part of the .NET Core port of Windows Forms. We also saw that they would require more time from us to support than made sense.
Our goal is to continue to improve Windows Forms for high DPI, accessibility, and reliability, and this late change was required to enable us to focus on delivering that.
C++/CLI
We added support for creating C++/CLI (AKA “managed C++”) components that can be used with .NET Core 3.0+, in Visual Studio 2019 16.4. You need to install the “Desktop development with C++” workload and the “C++/CLI support” component in order to use C++/CLI.
This component adds a couple templates that you can use:
CLR Class Library (.NET Core)
CLR Empty Project (.NET Core)
If you cannot find them, just search for them in the New Project dialog.
C++/CLI is only enabled on Windows. You cannot use C++/CLI components targeted for .NET Framework with .NET Core or vice versa.
Closing
We recommend moving to .NET Core 3.1 as soon as you can. It is a great release (largely due to 3.0) that brings improvements to so many aspects of .NET Core. It is also a long term support (LTS) release, and will be supported for three years.
Life cycle update:
.NET Core 3.0 will reach end-of-life three months from today, on March 3, 2020.
.NET Core 2.2 will each end of life on December 23rd.
.NET Core 2.1 will be supported until August 2021 (it is also an LTS release).
The following .NET Core posts are recommended reading to learn more about what you get with .NET Core 3.1 and other projects we’ve been working on.
Here in Redmond, glimpses of holiday cheerare fillingour campus buildings as the season shifts to twinkling lights and frosty temperatures. The Visual Studio team is seizing this time as an opportunityto celebrate the comraderyneeded to respond to developer needs and suggestions. Equally, we are reflecting over what we can improve in the upcoming year as well as plan product features to deliver.
What is more notable is the generosity flowing within our various Microsoft locations. One primary means of meeting community needs is through our annual Giving Tree program. There are festive trees in every building decorated with ornaments of wish list items for a variety of charitable organizations. Teams and individuals are able to pick favorite tag item and gift them. To increase the impact, Microsoft matches the dollar amount for an additional gift to the charity! With giving in mind, we are anticipating this release of Visual Studio 2019 version 16.4 will fill your wish list item of a more stable, productivedevelopment environment.Since we started working on this release in August, we have implemented hundredsDeveloper Community suggestions and bug fixes. Let’s take a look at what you’ll find in this release.
We know GitHub integration brings value to your developer experience. Therefore, we are excited to announce a previous extension making its way into the Visual Studio 2019 product. The ability to have GitHub publishing done directly from Team Explorer has been a favorite because of its seamless communication with GitHub repositories. For this reason, local repositories can be synchronized by clicking the Publish to GitHub button on the Team Explorer Synchronization page. This functionality has been a high priority of our teams, so we are eager to hear what you think.
Publish to GitHub from Visual Studio 2019 v16.4
XAML Hot Reload for Xamarin.Forms
Next, XAML Hot Reload for Xamarin.Forms enables you to make changes to your XAML UI and see them reflected live without requiring another build and deploy. This feature significantly speeds up development to make it easier to build, experiment, and iterate on your user interface. Best of all is how much time you can save since you no longer have to rebuild your application for every tweak.
Because your application is compiled using XAML Hot Reload, it works with all libraries and third-party controls, and is available for iOS and Android. Consequently, it works on all valid deployment targets including simulators, emulators, and physical devices. In the event that you are more curious, check out the XAML Hot Reload for Xamarin.Forms documentation detailed by the team members themselves.
Container Tools window
Another addition that started out as an extension in the Visual Studio Marketplace is the Container Tools window. This new tool window enables you to list, inspect, stop, start, and remove Docker images and containers on a local machine. As a result, you can view folders and files in running containers and open a terminal window.
Container Tools Window in Visual Studio v16.4
XAML tooling improvements for WPF and UWP desktop developers
Furthermore, we are continuing to invest in productivity improvements for desktop developers building WPF and UWP applications. New features include IntelliSense support for XAML snippets, a “Just My XAML” filter for the Live Visual Tree, and a merge resource dictionary feature. Also included, is the ability to pop up the code editor view separate from the XAML designer.
Pinnable Properties Tool
We are continuing to improve debugging capabilities in this release. With this in mind, we are delighted to announce how identifying objects by their properties while debugging has just become easier and more discoverable with the new Pinnable Properties tool. In short, hover the cursor over a property you want to display in the debugger of the Watch, Autos, and Locals windows. Click the pin icon. Next, you will see the information you are looking for at the top of your display!
Pin Properties in Debugger shown in Visual Studio 2019 v16.4
Additionally, to help make debugging asynchronous code easier, we have added new features to Parallel Stacks for Tasks, a window that visualizes Tasks in .NET.
.NET Productivity
We added the new Go To Base command to navigate up the inheritance chain. The Go To Base command is available on the context (right-click) menu or you can type (Alt+Home) on the element you want to navigate through the inheritance hierarchy.
Go To Base Command shown in Visual Studio 2019 v16.4
Also, you can configure the severity level of a code style rule directly through the editor. Place your cursor on the error, warning, or suggestion and type (Ctrl+.) to open the Quick Actions and Refactorings menu. Next, select ‘Configure or Suppress issues’. Finally, select the rule and choose the severity level you would like to configure. This will update your existing EditorConfig with the rule’s new severity. If you do not currently have an .editorconfig file, one will be automatically generated.
Vertical Tabs in Preview
Ever find yourself needing to see more of your document tabs or more lines of code? Now you can take advantage of the horizontal real estate of your widescreen monitors by using vertical document tabs. To learn how to preview this feature, the details are in the vertical document tabs blog.
Vertical Tabs in Visual Studio 2019 v16.4
C++ Tooling
We have made three major improvements in the C++ development experience: the Clang-tidy integration in the editor, Address Sanitizer experimental support, and C++ Build Insights support for the MSVC compiler toolset. In addition to the improvements outlined below, this release also brings C++/CLI support in .NET Core 3.1 and several new enhancements to the CMake integration. These include debug target selection, overview pages and easier customization of environment variables.
Clang-tidy Integration
C++ Code Analysis now natively supports Clang-Tidy for both MSBuild and CMake projects, whether you’re using a Clang or MSVC toolset. clang-tidy checks can run as part of background code analysis, appear as in-editor warnings (squiggles), and display in the Error List.
Clang-Tidy integration in Visual Studio 2019 v16.4
Visual Studio 2019 v16.4 Experimental Address Sanitizer support in MSVC
C++ Build Insights
You also have access to a collection of ETW-based tools that allow you to analyze your C++ builds and make decisions tailored to your own build scenarios. Consequently, there should be improvements to your build times. To learn more, check out the first in a series of blogposts on this topic: Introducing C++ Build Insights.
C++ Build Insights Demonstration in Visual Studio 2019 v16.4
Visual Studio now supports “FIPS compliance mode”
Starting with version 16.4, Visual Studio 2019 now supports “FIPS 140-2 compliance mode” when developing apps and solutions for Windows, Azure, and .NET. As an important note, there are some scenarios which may not use FIPS 140-2 approved algorithms. These include developing apps or solutions for non-Microsoft platforms like Linux, iOS, or Android as well as third-party software included with Visual Studio or extensions that you choose to install. Finally, development for SharePoint solutions does not support FIPS 140-2 compliance mode.
To configure FIPS 140-2 compliance mode for Visual Studio, install .NET Framework 4.8 and enable the Windows group policy setting: “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.”
Extended support for Visual Studio 2019 version 16.4
Visual Studio 2019 version 16.4 is the second supported servicing baseline for Visual Studio 2019. Consequently, Enterprise and Professional customers needing to adopt a long term stable and secure development environment are encouraged to standardize on this version. As explained in more detail in our lifecycle and support policy, version 16.4 will be supported with fixes and security updates for one year after the release of the next servicing baseline.
In addition, now that version 16.4 is available, version 16.0, our last released servicing baseline, will be supported for an additional 12 months. It will go out of support in January 2021. Note as well, versions 16.1, 16.2, and 16.3 are no longer under support. These intermediary releases received servicing fixes only until the next minor update released.
You can acquire the latest most secure version of Visual Studio 2019 version 16.4 in the downloads section of my.visualstudio.com. For more information about Visual Studio supported baselines, please review the support policy for Visual Studio 2019.
End of Support reminders for prior versions of Visual Studio and Expression 4
The following products are nearing their end of support lifetime, which means that we will no longer be issuing security updates for these products. These dates are all available on the Microsoft Lifecycle Policy site.
Visual Studio 2010 suite of products – support ends on July 14, 2020
Expression 4 suite of products – support ends on Oct 13, 2020
Happy Developing into the New Year!
In whatever way you celebrate the season and the new year, we hope these features will keep you producing your best projects until the time comes to unplug and enjoy the festivities. We love to hear inspiring ideas of ways to improve Visual Studio 2019. Please take all questions and suggestions to Developer Community as this is where teams interact the most. Thank you for all you do to contribute to the community, and we wish you all of the best!
If you’re on Windows using Visual Studio, install Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1, so you don’t need to separately install it.
To upgrade an existing ASP.NET Core 3.0 RC1 project to 3.0:
Update all Microsoft.AspNetCore.* and Microsoft.Extensions.* package references to 3.1.0
That’s it! You should now be all set to use .NET Core 3.1!
Blazor WebAssembly update
Alongside this .NET Core 3.1 release, we’ve also released a Blazor WebAssembly update. Blazor WebAssembly is still in preview and is not part of the .NET Core 3.1 release. Blazor WebAssembly will ship as a stable release at a future date.
To install the latest Blazor WebAssembly template run the following command:
dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview4.19579.2
This release of Blazor WebAssembly includes a number of new features and improvements:
.NET Standard 2.1 support
Support for static assets in when publishing
iOS 13 support
Better linker errors
Attach to process debugging from Visual Studio
.NET Standard 2.1 support
Blazor WebAssembly apps now target .NET Standard 2.1 by default. Using .NET Standard 2.1 libraries from a Blazor WebAssembly app is now supported within the limits of the browser security sandbox.
Support for static assets in libraries when publishing
Standalone Blazor WebAssembly apps now support static assets from Razor class libraries both during development and when publishing. This applies to both standalone Blazor WebAssembly apps and ASP.NET Core hosted apps. Static assets are consumed from referenced libraries using the path prefix: _content/{LIBRARY NAME}/.
iOS 13 support
Blazor WebAssembly apps now work from iOS 13 based devices. The .NET IL interpreter now uses a non-recursive implementation to prevent exceeding the size of the stack on these devices.
Better linker errors
The IL linker is now integrated with Blazor WebAssembly projects such that linker are surfaced as build errors.
Attach to process debugging from Visual Studio
You can now debug Blazor WebAssembly apps from Visual Studio by attaching to the browser process. Currently this experience is very manual. In a future update, we expect to enable Visual Studio to handle all of the necessary wire-up to debug a Blazor WebAssembly app when you hit F5. Also, various features of the debugging experience (like viewing locals) are not yet enabled. This is something we will be working on over the next few months.
To debug a running Blazor WebAssembly app from Visual Studio:
Run the app without debugging (Ctrl-F5 instead of F5)
Open the Debug properties of the app and copy the HTTP app URL
Browse to the HTTP address (not the HTTPS address) of the app using a Chromium based browser (Edge Beta or Chrome).
With the browser in focus, press Shift-Alt-D and then follow the instructions to open a browser with remote debugging enabled
Close all other browser instances
In Visual Studio, select Debug > Attach to Process.
For the Connection type, select Chrome devtools protocol websocket (no authentication).
For the Connection target, paste in the HTTP address (not the HTTPS address) of the app and press Enter (don’t click “Find” – that does something else).
Select the browser process you want to debug and select Attach
In the Select Code Type dialog, select the code type for the specific browser you are attaching to (Edge or Chrome) and then select OK
Set a break point in your app (for example, in the IncrementCount method in the Counter component) and then use that part of the app to hit the breakpoint.
Give feedback
We hope you enjoy this release of ASP.NET Core in .NET Core 3.1! We are eager to hear about your experiences with this latest .NET Core release. Let us know what you think by filing issues on GitHub.
EF Core 3.1 is distributed exclusively as a set of NuGet packages. For example, to add the SQL Server provider to your project, you can use the following command using the dotnet tool:
When upgrading applications that target older versions of ASP.NET Core to 3.1, you may also have to add the EF Core packages as an explicit dependency.
Starting in 3.0 and continuing for 3.1, the dotnet ef command-line tool is no longer included in the .NET Core SDK. Before you can execute EF Core migration or scaffolding commands, you’ll have to install this package as either a global or local tool. To install the final version of our 3.1.0 tool as a global tool, use the following command:
It’s possible to use this new version of dotnet ef with projects that use older versions of the EF Core runtime. However, older versions of the tool will not work with EF Core 3.1.
What’s new in EF Core 3.1
The primary goal of EF Core 3.1 is to polish the features and scenarios we delivered in EF Core 3.0. EF Core 3.1 will be a long term support (LTS) release, supported for at least 3 years. To this end we have fixed over 150 issues for the 3.1 release, but there are no major new features to announce.
EF Core 3.1 reintroduces support for .NET Standard 2.0, rather than requiring .NET Standard 2.1 as was the case for EF Core 3.0. This means EF Core 3.1 will run on .NET Framework versions that support the standard.
What’s new in EF 6.4
Similar to EF Core, the primary goal of EF 6.4 is to polish the features and scenarios we delivered in EF 6.3. To this end we have fixed important issues found in EF 6.3 to create a more stable release.
What’s next
Planning for the EF Core “5.0” release (i.e. the one after 3.1) has started and we are making good progress. We will have something to share on GitHub soon.
Thank you
A big thank you to the following community contributors to EF Core and EF6 as part of this release.
Since the launch of Visual Studio 2019 we’ve released many new features for XAML developers working on WPF or UWP desktop applications. With this week’s release of Visual Studio 2019 version 16.4 and 16.5 Preview 1 we’d like to use this opportunity to do a recap of what’s new throughout the year. If you missed our previous releases or simply have not had a chance to catch-up, this blog post will be the one place where you can see every major improvement we’ve made throughout 2019.
XAML Live Debugging Tools:
XAML C# Edit & Continue is now known as XAML Hot Reload (v16.2): XAML C# edit & continue for WPF/UWP customers is now known as XAML Hot Reload, this new name is intended to be better aligned with how the feature actually works (since no pause is required after a XAML edit is made) and match the similar functionality in Xamarin.Forms.
XAML Hot Reload available/unavailable (v16.2): The in-app toolbar has been updated to indicate if XAML Hot Reload is available/unavailable and link to the related documentation. Before this improvement customers had no way to know if XAML Hot Reload was working without trying to first use the feature, which was leading to confusion.
In-app toolbar now themed (v16.2): The in-app toolbar is now styled according to the Visual Studio selected theme colors.
In-app toolbar now themed (v16.2)
In-app toolbar element selection behavior changes: We’ve updated the behavior of the in-app toolbar feature “Enable selection” for selecting elements within the running app. With this change the selector will stop selecting elements after you have selected your first element. This brings it in line with similar tools such as F12 browser tools and is based on customer feedback.
XAML Hot Reload now supports x:bind (UWP) – v16.0: XAML Hot Reload (previous called “XAML Edit & Continue”) now supports editing data bindings created with x:bind for paths containing public properties, element name, indexed property paths (collections), attached properties, and cast properties. Other changes are not supported. This enhancement is available to any app where the minimum and maximum versions target Windows 10 SDK version 1809 (build 10.0.17763) or higher.
XAML Hot Reload support added for WPF resource dictionaries changes (v16.3): XAML Hot Reload now supports updating WPF Resource Dictionaries for real-time updates in the application. Previously this feature was only available to Universal Windows Platform (UWP), but is now supported for WPF .NET Framework, WPF .NET Core and UWP apps. Supported actions include adding a new Resources section definition and adding, deleting and updating resources new/existing sections.
Just My XAML in Live Visual Tree: The Live Visual Tree is a feature that is available to both UWP and WPF developers when they run their application in debug mode and is part of the live editing tooling related to XAML Hot Reload. Previously the feature would display the full live visual tree of the attached running application with no filter possible to see just the XAML you’ve written in your app. This made for a very noisy experience and based on customer feedback we’ve added a new default called “Just My XAML” which will limit the tree to just controls you wrote in your application. While this is the new default it is still possible to go back to the previous behavior through either the button within the Live Visual Tree itself or through a new setting (found under: Options > Debugging > General > Enable Just My XAML).
Just My XAML in Live Visual Tree
In-app toolbar now movable (v16.3): The in-app toolbar has been enhanced so that it is movable within the running WPF/UWP application, enabling developers to drag it left or right within the app to unblock app UI. Note that position to which the toolbar is moved is not stored between sessions and will go back to the default position when your app is restarted.
In-app toolbar now movable (v16.3)
XAML Binding Failures panel (standalone VSIX early alpha preview): To help developers when data binding failures occur in their application, we’ve got a new feature in development that brings a dedicated XAML Binding Failures panel to visual studio. While this feature will eventually work for all XAML developers (WPF, UWP and Xamarin.Forms) in this first preview the new panel will make it easier to identify binding failures for those customers building WPF application.
XAML Binding Failures panel (standalone VSIX early alpha preview)
This feature means that developers will no longer have to use the output window to detect binding failures and make them more discoverable to newer developers.
This feature is still very early in development and not included in Visual Studio, if you wish to start testing it today you can do so by downloading our alpha VSIX.
XAML Designer
WPF Designer now fully available (GA) for WPF .NET Core Projects (v16.3): The XAML Designer for WPF .NET Core applications is now generally available (GA) to all customers without the need for preview feature flag. The XAML Designer for WPF .NET Core applications is slightly different in some behaviors and functionality then WPF .NET Framework Designer, please note this is by design. Given the difference we’d like to encourage customers to report any problems or limitations that you might be running into using Visual Studio feedback feature.
WPF Designer now fully available (GA) for WPF .NET Core Projects (v16.3)
XAML Designer zoom/position now defaults to Fit All (v16.4): Based on customer feedback we’ve reevaluated the default XAML Designer zoom behavior that occurs when you open a XAML window/page/control/etc. The previous experienced stored the zoom level and position for each file across Visual Studio sessions which caused confusion when customers were coming back to a file after some time had passed. Starting with this release we will only store the zoom level and position for the duration of the active session and go back to a “fit all” default once Visual Studio is restarted.
Create Data Binding Dialog (v16.4): Visual Studio has had a data binding dialog available to WPF .NET Framework developers from the right-click of the XAML Designer and Property Explorer, and this dialog was also previously available to UWP developers. In this release we’re bringing back this experience to UWP developers and adding support for WPF .NET Core applications. This feature is still in development and will continue to improve in the future to bring back feature parity with .NET Framework dialog capabilities.
XAML Designer Suggested Actions (v16.5 Preview): In this release we’ve made available a new preview featured called Suggested Actions that enables easy access to common properties when a control is selected within the XAML Designer. To use this feature first enable it through Options > Preview Features > XAML Suggested Actions. Once enabled click on a supported control and use the lightbulb to expand and interact with the Suggestion Actions UI. In this release supported controls include: Border, Button, Canvas, CheckBox, ComboBox, Grid, Image, Label, ListBox, ListView, StackPanel, TextBlock, TextBox. While in preview this feature is also only available for WPF .NET Core applications and doesn’t support extensibility, nor is it feature complete.
XAML Designer Suggested Actions (v16.5 Preview)
(Please note that this feature is under active development and might change significantly before final release, so your feedback is crucial, and we hope to hear from you through the Visual Studio feedback tool.)
XAML Editor
IntelliCode Support for XAML (v16.0): IntelliCode is an AI-assisted IntelliSense for multiple languages that predicts the most likely correct API for the developer to use instead of just an alphabetical list of members. IntelliCode supports languages such as C#, C++, XAML and others.
Improvements to #regions IntelliSense (v16.4): Starting with Visual Studio 2015 #region support has been available for WPF and UWP XAML developers and more recently for Xamarin.Forms. In this release we’ve fixed an IntelliSense bug, with this fix #regions will now show properly as you begin to type <!.
Snippets in XAML IntelliSense (v16.4): IntelliSense has been enhanced to support showing XAML snippets, this will work for both built-in snippets and any custom snippets that you add manually. Starting with this release we’re also including some out-of-the-box XAML snippets: #region, Column definition, Row definition, Setter and Tag.
Pop up XAML editor as a separate window from designer (v16.4): It is now possible to easily split the XAML Designer and its underlying XAML editor into separate windows using the new Pop up XAML button next to the XAML tab. When clicked the XAML designer will minimize its attached XAML tab and pop open a new window for just the XAML editor view. You can move this new window to any display or tab group in Visual Studio. Note that it is still possible to expand the original XAML view but regardless all XAML views of the same file will stay synchronized in real-time.
Pop up XAML editor as a separate window from designer (v16.4)
Displaying resources for referenced assemblies (v16.4): XAML IntelliSense has been updated to support displaying XAML resources from a referenced assembly (when source is not available) for WPF Framework and WPF .NET Core projects.
XAML Islands:
Improved XAML Island support (v16.4): We’ve added support for XAML Islands scenario for Windows Forms and WPF .NET Core 3 apps making it easier to add UWP XAML control into these applications. With these improvements a .NET Core 3 project can a reference to UWP project that contains custom UWP XAML controls. Those custom controls can be used by the WindowsXamlHost controls shipped within the Windows Community Toolkit v6 (Microsoft.Toolkit.Wpf.UI.XamlHost v6.0). You can also use the Windows Application Packaging project to generates MSIX for you .NET Core 3 with Islands. To learn how to get started visit our documentation.
Resources & Templates
Merge Resource Dictionary:It is now possible to easily merge an existing resource dictionary within your UWP/WPF project with any valid XAML file using the new feature available through the solution explorer. Simply open the XAML file in which you want to add the merge statement, then find the file you wish to merge in and right-click on it in solution explorer. In the context menu select the option “Merge Resource Dictionary Into Active Window”, which will add the right merge XAML with path.
Merge Resource Dictionary
Edit Template now works with controls from 3rd party controls: It is now possible to create a copy of a controls template even when it’s not part of your solution as source code. With this change the “Edit Template” feature will now be available and work as it does for 1st party elements where the source is available today. Note that this feature is applicable to both 3rd party control libraries and 1st party where source isn’t available.
Packaging and Signing
Signing Certificates for UWP apps (v16.3): Brought back the ability to create and import signing certificate files (.pfx) through the Manifest Designer. We’ve also introduced the ability to create and import signing certificates through the Packaging Wizard to streamline the signing process.
Signing Certificates for UWP apps (v16.3)
Related News
Recently there were also other announcements that are relevant to desktop developers, if you missed any of these here is a consolidated list for your consideration:
Visual Studio App Center now support .NET desktop applications including WinForms, WPF and UWP. This includes apps powered by .NET Framework or .NET Core and supported features include deployment, health monitoring (crash reporting) and real-time insights (custom telemetry). For full details check out their recent blog post.
Windows has announced WinUI 3, with both the alpha release and long-term roadmap announced. With WinUI 3 developers will be able to use the power of modern XAML to build both desktop and UWP applications powered by .NET Core or C++. To learn all the details see their roadmap.
Windows UI Library 2.3 is now available, which continues to add more controls for UWP developers. For all the details see their release notes.
Ignite 2019 XAML conference sessions are now available as free on-demand videos, if you missed Ignite this year their worth checking out.
Conclusion
These features are also just some of the things we’ve been working on, with many more still in development and we hope to share more information with you when their ready.
For now, please keep your feedback coming as many of the above items were created based on customer input, as your input is a critical part of how we improve Visual Studio.
Finally, you can also see demos for many of the above features in our latest Visual Studio Toolbox video:
Do you need rugged, compact-sized hyperconverged infrastructure (HCI) enabled servers to run your branch office and edge workloads? Do you want to modernize your applications and IoT functions with container technology? Do you want to leverage Azure's hybrid services such as backup, disaster recovery, update managment, monitoring, and security compliance?
Microsoft and Lenovo have teamed up to validate the Lenovo ThinkSystem SE350 for Microsoft's Azure Stack HCI program. The ThinkSystem SE350 was designed and built with the unique requirements of edge servers in mind. It is versatile enough to stretch the limitations of server locations, providing a variety of connectivity and security options and can be easily managed with Lenovo XClarity Controller. The ThinkSystem SE350 solution has a focus on smart connectivity, business security, and manageability for the harsh environment. To see all Lenovo servers validated for Azure Stack HCI, see the Azure Stack HCI catalog to learn more.
Lenovo ThinkSystem SE350:
The ThinkSystem SE350 is the latest workhorse for the edge. Designed and built with the unique requirements for edge servers in mind, it is versatile enough to stretch the limitations of server locations, providing a variety of connectivity and security options and is easily managed with Lenovo XClarity Controller. The ThinkSystem SE350 is a rugged compact-sized edge solution with a focus on smart connectivity, business security, and manageability for the harsh environment.
The ThinkSystem SE350 is an Intel® Xeon® D processor-based server, with a 1U height, half-width and short depth case that can go anywhere. Mount it on a wall, stack it on a shelf, or install it in a rack. This rugged edge server can handle anything from 0-55°C as well as full performance in high dust and vibration environments.
Information availability is another challenging issue for users at the edge, who require insight into their operations at all times to ensure they are making the right decisions. The ThinkSystem SE350 is designed to provide several connectivity options with wired and secure wireless Wi-Fi and LTE connection ability. This purpose-built compact server is reliable for a wide variety of edge and IoT workloads.
Microsoft Azure Stack HCI:
Azure Stack HCI solutions bring together highly virtualized compute, storage, and networking on industry-standard x86 servers and components. Combining resources in the same cluster makes it easier for you to deploy, manage, and scale. Manage with your choice of command-line automation or Windows Admin Center.
Achieve industry-leading virtual machine (VM) performance for your server applications with Hyper-V, the foundational hypervisor technology of the Microsoft cloud, and Storage Spaces Direct technology with built-in support for non-volatile memory express (NVMe), persistent memory, and remote direct memory access (RDMA) networking.
Help keep apps and data secure with shielded virtual machines, network micro-segmentation, and native encryption.
You can take advantage of cloud and on-premises working together with a hyper-converged infrastructure platform in the public cloud. Your team can start building cloud skills with built-in integration to Azure infrastructure management services:
Azure Site Recovery for high availability and disaster recovery as a service (DRaaS).
Azure Monitor, a centralized hub to track what’s happening across your applications, network, and infrastructure, with advanced analytics powered by artificial intelligence.
Cloud Witness, to use Azure as the lightweight tie-breaker for cluster quorum.
Azure Backup for offsite data protection and to protect against ransomware.
Azure Update Management for update assessment and update deployments for Windows Virtual Machines running in Azure and on-premises.
Azure Network Adapter to connect resources on-premises with your VMs in Azure via a point-to-site VPN.
Sync your file server with the cloud, using Azure File Sync.
Azure Arc for Servers to manage role-based access control, governance, and compliance policy from Azure Portal.
By deploying the Microsoft + Lenovo HCI solution, you can quickly solve your branch office and edge needs with high performance and resiliency while protecting your business assets by enabling the Azure hybrid services built into the Azure Stack HCI Branch office and edge solution.
A few months ago, I wrote a blog post about the DebuggerDisplay attribute. This is a managed attribute that lets you customize how you view objects in debugging windows by “favoriting” specific properties. Since that post, we’ve streamlined DebuggerDisplay’s behavior with Pinnable Properties, a new managed feature available for Visual Studio 16.4!
Native developers: Fear not, Pinnable Properties will also be available for C++ in a later update!
Pinning a property
How does the Pinnable Properties tool work?
The Pinnable Properties tool is located in DataTips and the Autos, Locals, and Watch windows at debug time. To use the tool, hover over a property and select the toggle-able pin icon that appears or select the “Pin Member as Favorite” option in the context menu. You will immediately see your selected members bubble to the top of your property list and appear in the Values column of any of the debugger inspection windows, replacing the default object type that is typically displayed. Now you can quickly identify and scan through your countless objects, greatly increasing your productivity.
Pinning properties in DataTips
The properties you pin will persist across all your future debugging sessions until you decide to unpin them. Also, you can filter unpinned properties and hide property names via the Watch window toolbar or a DataTip context menu.
Filter out unpinned properties
Toggle pinned property names
Why does the Pinnable Properties tool exist?
Your feedback determined that there was high demand for quickly identifying objects in debugger windows via specific properties. Though DebuggerDisplay and Natvis can accomplish this task, they have several drawbacks that we observed and learned from you and other developers, including:
having to modify your code to use the attribute
the inability to use the attribute dynamically at debug time
the lack of discoverability (I have been asked many times if DebuggerDisplay is a Visual Studio 2019 exclusive feature when it’s been out for many, many years now…)
We created the Pinnable Properties tool to reduce these issues and provide with you with an easier, more intuitive, and real-time method to customize your object inspection experience without having to modify your code or override your ToString() method.
Try out Pinnable Properties and give us even more feedback!
Pinnable Properties would not have been possible without your enthusiasm and feedback for improving the existing DebuggerDisplay and Natvis behavior. We encourage you to try it out and share your thoughts on how we can make this tool even better in the comments or via this survey!
We are happy to announce the new preview version of the .NET Core Windows Forms designer, which is available with the Visual Studio 16.5 Preview 1.
The big news is that the designer is now part of Visual Studio! This means that installing the .NET Core Windows Forms designer from a separate VSIX is no longer needed!
To use the designer:
You must be using Visual Studio 16.5 Preview 1 or a later version.
You need to enable the designer in Visual Studio. Go to Tools > Options > Environment > Preview Features and select the Use the preview Windows Forms designer for .NET Core apps option.
If you haven’t enabled the Windows Forms designer, you might notice a yellow bar in the upper part of your Visual Studio Preview suggesting you to enable it:
Selecting the Enable link takes you to the same place in Tools > Options > Environment > Preview Features where you can enable the Windows Forms .NET Core designer preview.
What’s new
In this preview version of the designer, we’ve improved reliability and enhanced performance, fixed many bugs, and added the following features:
Designer Actions for available controls, such as making a TextBox multiline or adding items to a CheckedListBox.
Improved Undo/Redo actions to prevent hangs or incomplete undos.
Scrollbars now appear when the form is larger than the visible document window and on Forms with the AutoScroll property set to True and controls outside the visible area of the form.
Added GroupBox and Panel container control support.
Copy-paste is supported between container controls.
Limited Component Tray support.
Local resources support.
Timer control support.
Features currently under development
Support for the following features is currently on our backlog and being actively addressed:
Localization of your own Windows Forms applications.
Data-related scenarios including data binding and data-related controls.
Document Outline Window.
The remaining container controls.
MenuStrip and ToolStrip are expected in the next preview.
Third-party controls and UserControls.
Inherited Forms and UserControls.
Tab Order.
Tools > Options page for the designer.
Upgrade to .NET Core 3.1
We recommend that you upgrade your applications to .NET Core 3.1 before using the Windows Forms .NET Core designer. Visual Studio may not perform as expected if your project is targeting an earlier version of .NET Core.
In .NET Core 3.1 a few outdated Windows Forms controls (DataGrid, ToolBar, ContextMenu, Menu, MainMenu, MenuItem, and their child components) were removed. These controls were replaced with newer and more powerful ones in .NET Framework 2.0 in 2005 and haven’t been available by default in the designer Toolbox. Moving forward with .NET Core, we had to cut them out of the runtime as well in order to maintain support for areas like high DPI, accessibility, and reliability. For more information please see the announcement blog post.
Under the hood of the new Windows Forms Core designer (or why it takes us so much time)
We know that you’ve noticed: although the Windows Forms .NET Core designer Preview has basic functionalities, it is not mature enough for providing the full Windows Forms experience and we need a little more time to get there. In this chapter we wanted to give you a glimpse into how we are implementing the designer for .NET Core and explain some of the time frames.
The concept
Visual Studio is based on .NET Framework. The Windows Forms Core designer however should enable users to create a visual design for .NET Core apps. If you’ve tried to “mix” .NET Framework and .NET Core projects, you probably know what the challenge is here: .NET Core assemblies cannot be integrated into .NET Framework projects. Because of this (and some other reasons that we don’t want to overwhelm you with), we came up with the following internal concept: whenever the .NET Core designer is started (for example, by double-clicking on a form), a second designer process starts under the hood almost independently of Visual Studio. And that process takes over the .NET Core design part, or better to say – it’s responsible for instantiating the .NET Core based objects that are then rendered on the monitor by the .NET Core process and not the Visual Studio process.
For example, when you drag a Button from the Toolbox onto a form – this action is handled by Visual Studio (devenv.exe process which is .NET Framework). But, once you release the mouse button to drop the Button on the form, all further actions (instantiating a Button, rendering it at a specific location, and so on) are related to .NET Core. That means .NET Framework process can no longer handle it. Instead it calls to a .NET Core process which does the job and also creates the user interface code at runtime, which lives in the InitializeComponent method of a Form or a UserControl. This is the same way the XAML designer works for UWP and .NET Core.
Was there a better way?
There was another approach we could take that would save us a lot of time. We could simply “map” the .NET Core objects, features, and so on to .NET Framework ones. But this approach has significant limitations. The new features, that are available only in .NET Core won’t be available in this “mapped” designer. And we already have quite a few Core-only functionalities such as: the new PlaceholderText property of the TextBox control, the new default font, that is used in Windows Forms .NET Core. And going forward we expect more innovations coming.
That’s why we turned down that idea, and proceeded with the described above “out-of-process approach” that handles new additions to .NET Core very well.
This is how it works
The Property Browser in Visual Studio is based on the .NET Framework. However, thanks to TypeDescriptors, we can create “proxy objects” as a communication link between the two processes at design time to access the actual .NET Core objects in the other (.NET Core) process via inter-process communication. That way, even though the UI is still in Visual Studio and thus is .NET Framework, users will see and edit every single aspect of the Windows Forms .NET Core objects’ functionality.
The downside of this approach is that it requires us to rewrite significant portions of the Framework Windows Forms designer. To do this correctly, with the performance and stability that you expect, we had to set out a significant amount of time. The XAML designer team already developed an out-of-process model for UWP XAML designer support when UWP implemented .NET Standard 2.0. They were able to share much of that architecture with WPF running against .NET Core. This gave a head-start for .NET Core WPF designer, and now it is released and ready for .NET Core developers. The Windows Forms team started working on the designer with the .NET Core 3.0 announcement. We expect to get to feature parity by May 2020, and complete the work by the end of 2020.
The Windows Forms team wants to say THANK YOU! to those who are already testing preview versions of the designer and reporting issues! We know the experience may not be stable and we appreciate your patience and your desire to help us!
How to report issues
Your feedback and help are important to us! Please report issues or feature requests via the Visual Studio Feedback channel. To do so, select the Send Feedback icon in Visual Studio top-right corner as shown in the following picture and specify that it is related to the “WinForms .NET Core” area.
.NET Core 2.2 was released on December 4, 2018. As a non-LTS (“Current”) release, it is supported for three months after the next release. .NET Core 3.0 was released on September 23, 2019. As a result, .NET Core 2.2 is supported until December 23, 2019.
After that time, .NET Core patch updates will no longer include updated packages of container images for .NET Core 2.2. You should plan your upgrade from .NET Core 2.2 now.
.NET Core 3.1 released December 3, 2019 as a Long-term support release. As a result, .NET Core 3.0, released September 23, 2019 is supported until March 23, 2020.
Upgrade to .NET Core 3.1
The supported upgrade path from .NET Core 2.2 is via .NET Core 3.1. Migrating from 2.2 to 3.1 is straightforward; update the project file to use 3.1 rather than 2.2. The first document below illustrates the process from 2.0 to 2.1. ASP.NET Core 2.2 to 3.1 has additional considerations detailed in the second document.
Microsoft has a published support policy for .NET Core. It includes policies for two release types: LTS and Current.
LTS releases include features and components that have been stabilized, requiring few updates over a longer support release lifetime. These releases are a good choice for hosting applications that you do not intend to update often.
Current releases include features and components that are new and may undergo future change based on feedback. These releases are a good choice for applications in active development, giving you access to the latest features and improvements. You need to upgrade to later .NET Core releases more often to stay in support.
Both types of releases receive critical fixes throughout their lifecycle, for security, reliability, or to add support for new operating system versions. You must stay up-to-date with the latest patches to qualify for support.
Imagine being able to navigate through your neighborhood using your hearing alone. Microsoft Soundscape is an application built by the Enable Group in Microsoft Research that helps the blind and low vision explore the world around them using a map delivered in 3D sound. Armed with a stereo headset and the Soundscape app, anyone with a visual impairment can experience a mobile voice-based map that helps empower by providing the independence to traverse your environment and the ability to choose how to get from place to another.
With the help of Bing Maps Local Search and Bing Maps Location Recognition APIs, Soundscape enables you to hear where landmarks are around you to orient yourself, build a richer awareness of your surroundings, and have the confidence to discover what’s around the next corner.
We make it easy for users to create new organizations and start collaborating within seconds in Azure DevOps. While our users loved this, some of our big enterprise customers have long been demanding that they need to control who can create new organizations within their company as a way to protect their IP. With the latest sprint deployment, I am happy to announce that we rolled out a new policy in Azure DevOps to restrict this to a configured list of people in your company. This policy is supported only for company owned (Azure Active Directory) organizations. Users creating organization using their personal account (MSA or GitHub) have no restrictions.
To administer this policy, users need to be assigned to a new role called ‘Azure DevOps Administrator’ in Azure AD. Talk to the Azure AD administrator of your company to get this role assigned to you. Please refer to the documentation about this new role here.
You can find this role in the Azure Portal under Azure Active Directory > Roles and administrators.
Once you are assigned to this role, sign into any Azure DevOps organization that is connected to your Azure AD tenant to start managing this policy. You can find this new policy under organization settings > Azure Active Directory.
You can find the documentation to configure this policy here.
Please try out this feature and let us know your feedback through via Twitter on @AzureDevOps, or using Developer Community.
This week, the emerging theme of the community posts is the cross-platform, cross-cloud, extensible nature of Azure DevOps. Azure DevOps is not just a product, but a platform, enabling the community to expand and improve on our engineering efforts to support the growing variety of technologies around the world.
Configure CI/CD in Azure DevOps
If you aren’t familiar with the Azure DevOps Project, it is an Azure resource that lets you deploy and configure a sample app to an Azure environment, and wire up CI/CD for it in Azure DevOps. The Azure DevOps Project supports multiple types of technologies and environments, making it easy to create a deployment prototype that you can use as a reference. In this post, Prakash Kumar shares a detailed walkthrough of configuring a Build and Release for a .NET Core app, using the Azure DevOps Project.
How to build and sign your iOS application using Azure DevOps
In addition to being cross-cloud, Azure DevOps is also cross-platform! In this post, Damien Aicheh shows us an Azure Pipeline for building and signing your iOS application, producing a signed ipa. Thank you Damien!
Using Azure Pipelines to publish the NuGet package from GitHub repo
Of course, not all code is immediately deployed as an app – web, mobile or otherwise. In this blog, Xiaodi Yan shows us how to create an Azure YAML pipeline that publishes a NuGet package implementing a messenger component for WPF and Xamarin. Great work!
Introduction to the Red Hat OpenShift deployment extension for Microsoft Azure DevOps
And, of course, the true reason we can support so many languages, platforms and environments is that we work closely with our partners to extend the ecosystem. In this post, Luca Stocchi introduces us to the new version of the Azure DevOps extension for Red Hat OpenShift. With this extension, you can deploy to any OpenShift cluster from Azure DevOps. And the extension is open source, so you can contribute to the effort. Thanks for the hard work, Luca!
If you’ve written an article about Azure DevOps or find some great content about DevOps on Azure, please share it with the #AzureDevOps hashtag on Twitter!
