oday we are sharing the final release of Visual Studio 2015 Update 3, Team Foundation Server 2015 Update 3, and .NET Core and ASP.NET Core 1.0.
I’m going to start with .NET Core and ASP.NET Core. If you’ve not been following the .NET blog or the WebDev blog, .NET Core is a cross-platform, open source, and modular .NET platform for creating modern web apps, microservices, libraries and console applications that run on Windows, Mac, and Linux. This release includes the runtime and libraries for .NET Core and ASP.NET Core and a new set of command line tools, as well as Visual Studio and Visual Studio Code extensions that enable developers to work with .NET Core projects. The tooling will be at release quality with the next major release of Visual Studio, Visual Studio “15.”
Switching to VS Update 3, normally, I’d share some of the highlights of this release here, but over the past few months we’ve been working to improve our release notes and known issues so they are much more readable and approachable (and complete). So rather than using this post to talk about a bunch of the changes, I want to share a story about hunting down some memory issues in VS.
This is really a tale of two customers – both reasonably large and successful companies who’ve been using VS for many years. Both had reached out to us with saying they were having problems with sluggishness and stability when dealing with solution files containing 100s of projects and millions of files. One customer, for example, had a solution file with 500 projects (all .NET), which was making VS hang and crash from anywhere within five to 60 minutes of opening a solution. Another customer had a solution file with 200 projects (mostly .NET, but a handful of C++ projects). Though this project would load successfully, it was consuming a lot of CPU cycles, causing the IDE to be very sluggish while editing code, and the customer also experienced random crashes.
On the surface, these might look like very related issues. But they weren’t. As we talked with the customers and debugged their solutions, it became clear that the root causes were pretty different. Here are some of the things we learned and what we changed:
- We had tuned the algorithm for releasing cached project information to one particular shape of solutions (basically mid-sized .NET-only solutions)
- Some cached project information was simply retained for too long, regardless of the solution.
- VS enabled high-impact features like full code scanning in all cases, rather than allowing users to select whether they wanted them on or not.
- When VS would fire events aimed at multiple projects in a solution, VS wouldn’t properly batch them; it processed them one by one.
- VS would sometimes promote metadata references to project-to-project (P2P) references for a better experience; however, for some customers (those with complex P2P reference chains, or with post-build steps that modify binaries), this was actually degrading performance.
These problems turned out to be quite complex, often involving engineers from five or six feature teams to diagnose and fix them. That took time – our time and, more importantly, the customers’ time. I want to take a second here to thank both of these customers (you know who you are) for their patience and willingness to let us take a look at their projects.
All of these fixes (and more) are in Update 3; please take a look at the release notes and known issues for the full list.
[Updated June 30th: Thanks to some of you early adopters, we were able to fix or offer workarounds for some installation issues that were affecting a small percentage of users, including the inability to install Update 3 and not being able to create or load UWP projects. Other fixes to other product issues are in the works and will be available soon. Please refer to the known issues for details.]
To learn more about other related downloads, see the Downloads page. You can also access the bits and release notes right now on an Azure-hosted VM. You should be able to install this update on top of previous installations of Visual Studio 2015.
As always, we welcome your feedback. For problems, let us know via the Report a Problem option in Visual Studio. For suggestions, let us know through UserVoice.