[UPDATED July 15th – New patch is now available to fix some top bugs in Update 3. Check Update July 15th tag]
[UPDATED June 30th – See update tag within the post for details]
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.
[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.]
[Update July 15th: A new patch is now available to apply on top of Update 3. If you downloaded Update 3 after July 12th, you will automatically get the patch, if you downloaded Update 3 before July 12th then please apply this patch to get the latest fixes on Update 3]
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.
|John Montgomery, Director of Program Management for Visual Studio