New Features in Visual Studio 2019 v16.8 Preview 3.1
In conjunction with Ignite 2020, we are releasing Visual Studio 2019 v16.8 Preview 3.1. Our events always bring an excitement to our team as we launch new functionality to our product. In this release, we are giving you access to improvements in Git Integration, C++20 conformance, .NET Productivity, Web Tools, and XAML . We can’t wait to hear how these features impact your work for the better. Equally, we love to hear how we can strive for constant improvement through our Developer Community.
While taking in one of our free Ignite 2020 sessions, why not download our latest Preview release and give some of these new features a try?
GitHub Codespaces for Visual Studio
GitHub Codespaces for Visual Studio is now available as a limited beta in Visual Studio 2019 Preview 3.1. This gives you an instant cloud development environment that lets you code from anywhere. You can use the features you love from Visual Studio 2019 in a codespace to develop, test, and deploy modern apps including ASP.NET Core web apps, .NET Core, CMake, and C++ console / library apps. GitHub Codespaces for Visual Studio is available to a subset of GitHub users that sign-up while in limited beta. Over time, more users will get access based on availability and sign up date.
On a local machine, Visual Studio competes with other apps for resources with limits in CPU and disk space. With Codespaces, many of the CPU intensive operations like loading the solution, building, and debugging are offloaded to the cloud. This allows you to work on enterprise scale application without impacting your local machine’s resources. This also allowed us to dramatically reduce what we install locally when you’re building apps in a Codespace. Installing Visual Studio to connect to GitHub Codespaces takes minutes.
Quick Set-up
Whether you are new to the team or on a new machine, getting a full development environment setup from scratch for a project can be challenging. Getting the configuration for a repository correct takes time. Worse, if something doesn’t work, you’re left wondering if you made a mistake or if the setup steps are out-of-date. Now, you can setup a development environment with a new command line tool called devinit. This allows you to define dependencies in code through a declarative format that versions with your source so it is always up-to-date in any branch of the code. Devinit supports a range of existing package managers to automatically and repeatably configure dependencies in a codespace. We’ve put together some resources so you can learn more about how to use devinit.
Git Integration
We have been expanding and improving the support for Git source control workflows, with the new Git tools. In this latest preview, you can create new branches from Azure DevOps Work Items using the new ‘create branch’ dialog. Just go to the Work Items panel from Team Explorer and right click a work item to create a new branch from it.
You also now have available a list of local Git repositories that Visual Studio detects and adds to the Git menu when you open a project, solution, or just a folder. You can also directly clone a repository and it gets added to this list. Selecting a repository from this menu opens the Git context in Visual Studio. You can then go to Solution Explorer to load the solution or folder you want.
In addition, we’ve changed the default source control provider to Git, which is active when you install Visual Studio for the first time. It was previously TFVC. So now you will get the Git menu and tool windows available in your first launch without having to go to Tools – Options – Source control to change the setting.
C++
The C++ team is excited to announce that they’ve improved support for major C++20 features across the compiler, standard library, and IDE. You can now use Modules, Concepts, Coroutines, and (some of) Ranges all in the same project!
The work we’ve been doing around C++20 Coroutines is now complete and available under /std:c++latest. When using C++20 Coroutines you should include the <coroutine> header. Support for our legacy behavior is available under <experimental/coroutine> and the /await switch. Read more details in our C++20 Coroutines blogpost. Also available under the /std:c++latest are feature-complete C++20 Modules. This includes header units and experimental MSBuild support. What makes this exciting is that this will work out your module dependencies automatically and ensure they are built in the right order. Far more details are available in the team’s C++20 Modules blog post.
Also landing in this release is support for the majority of C++20 Ranges. The big highlights are support for most of the range-based algorithms. Though, rest assured, we are still working tirelessly to complete the remaining. Feel free to track our progress on this GitHub issue.
STL Features and Optimizations
Outside of Ranges, this release brings several new STL features and optimizations. Some examples include:
- std::atomic_ref<T> allows you to perform atomic operations on non-atomic objects.
- Our std::midpoint and std::lerp implementations are now constexpr.
- std::execution::unseq indicates that an algorithm’s execution may be vectorized on a single thread.
- We’ve hand-vectorized our std::reverse_copy implementation
As always, we document all of the STL updates in our Changelog.
IntelliSense now provides support for C++20 <concepts> and <ranges> headers, and rename and browsing for concept definitions.
We do have a known issue that we expect to address in Visual Studio 2019 v16.8 Preview 4.
While we are on IntelliSense, we’ve added new warnings and quick-fixes based on an IntelliSense-driven code linter. Use Tools>Options>Text Editor>C/C++->CodeStyle->Linter + Fixups to configure this to your liking. You’ll be able to get warnings and fixes for arithmetic overflow, uninitialized local variables, converting the result of an integer division to float, and more!
Our code analysis tools now support the SARIF 2.1 standard: the industry standard static analysis log format. Behind the scenes, SARIF 2.1 powers the MSVC code analysis experience in Visual Studio, including error list population in both regular and background code analysis runs, green squiggles and fix-its. In the near future, we plan to improve the IDE experience further by color coding the squiggles according to severity level (Info/Warning/Error) of each defect based on information in the SARIF logs. You can read more about the format SARIF format in the official specification.
C11 and C17 Support
All required features of C11 and C17 are now supported using the /std:c11 and /std:c17 switches. This includes:
- _Pragma
- restrict
- _Noreturn and <stdnoreturn.h>
- _Alignas, _Alignof and <stdalign.h>
- _Generic and <tgmath.h> support
- _Static_assert
It is important to mention that the optional features are not supported, so we do not claim C99 compliance. Learn more in our C11/C17 blogpost.
Debug Linux Core Dumps
If you run a “Windows shop”, but deploy to Linux servers, you may find this next feature quite exciting. You can now debug Linux core dumps on a remote Linux system or WSL directly from Visual Studio. This will help you diagnose crashes in a familiar environment.
Speaking of Linux, we’ve improved our error reporting for missing build tools on Linux projects. Previously you would encounter a lot of errors when compiling, debugging, or using IntelliSense. The warning in the toolbar will now give a clear error telling you about the missing tools in the error view.
Here are a couple of examples of what you’ll see in Visual Studio 2019 v16.8 Preview 3.1:
Or
Wrapping up our features from the C++ team, the addition of Conditionally trivial special member functions are now supported in MSVC. And finally, we have upgraded the version of CMake shipped with Visual Studio to CMake 3.18. This will enable you to use their new CMake profiling feature, and more. Read more in the team release notes.
.NET Productivity
.NET compiler platform (Roslyn) analyzers inspect your C# or Visual Basic code for security, performance, design, and other issues. Starting in .NET 5.0, these analyzers are included with the .NET SDK. Code analysis is enabled, by default, for projects that target .NET 5.0 or later. We have added the ability to enable code analysis on projects that target earlier .NET versions by setting the EnableNETAnalyzers property to true. On the flip side, you can disable code analysis for your project by setting EnableNETAnalyzers to false. Another means of accomplishing the same is to use the Project Properties toggle. To access the Project Properties right-click on a project within Solution Explorer and select Properties. Next, select the Code Analysis tab where you can either select or clear the checkbox to Enable .NET analyzers.
Inline Method Refactoring
There is now an inline method refactoring that helps you replace usages of a static, instance, and extension method within a single statement body with an option to remove the original method declaration. Place your cursor on the usage of the method. Press (Ctrl+.) to trigger the Quick Actions and Refactorings menu. Next select from one of the following options:
Select Inline <QualifiedMethodName> to remove the inline method declaration:
Select Inline and keep <QualifiedMethodName> to preserve the original method declaration:
The same Quick Actions and Refactorings menu has the option for the new C# 9 `not` pattern matching syntax when a suppression operator is present. Again, use (Ctrl+.) to trigger the menu and select Use pattern matching.
Finally from this team, creating a new C# or Visual Basic files from a template respects EditorConfig code style settings. The following code styles will automatically get applied when creating new files: file headers, sort using directives, and place using directives inside/outside namespaces.
Debugger
Similar to the feature added from our C++ team, we realized debugging a captured managed Linux core dump on Windows has been difficult. It would usually mean setting up another Linux environment that exactly mirrored production and then installing a set of tools for the analysis. Thankfully with Visual Studio 2019 16.8 preview 3.1 you can simply drag and drop a managed Linux core dump directly into your IDE and immediately start debugging.
XAML Experiences
XAML Binding Failures diagnostic improvements
Developers working on WPF, UWP, WinUI and Xamarin.Forms projects must often detect and resolve XAML data binding failures in their applications. To improve the diagnostic tooling in this scenario we’ve added two new experiences to Visual Studio 2019 (16.8 Preview 3.1+) and both are now on by default for our Preview customers.
Details:
- XAML Binding Failure Indicator Icon is now present in the in-app toolbar for WPF and UWP projects. This icon will show a red indicator if at least one binding failure is detected. Clicking the icon will also take you to the new XAML Binding Failures window.
XAML Binding Failure Indicator Icon in Visual Studio 2019 - New XAML Binding Failures window is now available for WPF, UWP, WinUI and Xamarin.Forms projects. This new dedicated experience provides a rich user interface over the binding failure information that was previously only available in the Output Window. Improvements include the ability to see the failures as a set of columns that can be sorted, customized and are fully searchable. We’ve also grouped similar errors together limiting the noise that can occur during certain combination of data binding templates failures while still making all the original raw error information available and easily copyable through a right-click menu option. (note: requires Xamarin version 5.0.266-pre3 or higher)
New XAML Binding Failures Window in Visual Studio 2019
Other XAML Tooling Improvements
We’ve also released many other new XAML features in previous 16.8 preview releases including updating XAML Hot Reload settings UI, XAML Hot Reload support Xamarin.Forms projects targeting UWP and improved MVVM tooling to help you set a XAML documents d:DataContext through IntelliSense. For details on these additional features see the full release notes.
A sneak peek of what’s coming next: Fakes code coverage support in .NET Core
With the release of .NET Core support for Fakes in Visual Studio 16.6 many users are eagerly awaiting code coverage support for Fakes in .NET Core as well. We are hoping to land this support in the 16.9 update on windows only, here is the sneak peek.
This required enabling the Visual Studio built-in dynamic code coverage to use the open source CLR instrumentation engine. This is also an exciting first step to providing a cross platform solution for dynamic code coverage eventually.
Enjoy Ignite 2020 and Visual Studio 2019 v16.8 Preview 3.1
Once again, we are constantly moving forward with greater functionality with our features. While enjoying Ignite, please Download Visual Studio 2019 v16.8 Preview 3.1 to give them a try. Let us know how we are doing as your input is of the greatest value to our teams.
10 comments
The big purple “Visual Studio Roadmap” button on the “Release Version” tab at this page:
https://developercommunity.visualstudio.com/spaces/8/index.html
does not work, it doesn’t take you to the roadmap. This is what happens when you don’t link the button to the actual page, but instead use some redirection service.
Thanks for the heads up. It’s now fixed.
It would be great if you could mention (probably in the following Blog entries) which of the VS improvements have impact or bring improvements to the VB programmer.
For example: Are the refactoring improvements also available in VB.Net? Etc.
Thank you in advance!
I’m glad DotNet 5.0 is now in RC1 and cleared for production deployment, but unless I’m using VS Code which lacks the WinForms designer, it unfortunately requires VS 2019 16.8 Preview, which is not cleared for production development. Without making any promises or forward-looking statements, what rough timeframe should I expect for VS 2019 16.8 to exit preview?
This is also quite interesting for me. A short answer would be appreciated.
any news on Native C++ NuGet PackageReference?
The convenience and versatility of vcpkg in the VS platform are not good.
On the VS platform, NuGet is 100 years ahead of vcpkg.
NuGet has long supported source code compilation just like vcpkg. I have never understood why Native C++ does not support PackageReference.
Isn’t this a very easy thing?
Are you going to continue to include support for .NET Framework 4.8 in future versions of Visual Studio, for example Visual Studio 2021 or whatever it is? Or, will .NET Framework developers get left behind on Visual Studio 2019?
I don’t think .NET Framework 4.8 support will be drop anytime soon from Visual Studio, as VS itself is built using .NET Framework. So you can still expect having your .NET Framework projects supported and working in VS 2019 for the time being.
Any news on the WinForms designer? I haven’t seen anything about it in awhile.
All controls are supported now. We are working on supporting data scenarios, third-party controls, improving performance and fixing other minor issues.