The following article was originally published on the Encodo blogs and is cross-published here.
The article Announcing the .NET Framework 4.5.1 Preview provides an incredible amount of detail about a relatively exciting list of improvements for .NET developers.
First and foremost, the Edit-and-Continue feature is now available for x64 builds as well as x86 builds. Whereas an appropriate cynical reaction is that “it’s about damn time they got that done”, another appropriate reaction is to just be happy that they will finally support x64-debugging as a first-class feature in Visual Studio 2013.
Now that they have feature-parity for all build types, they can move on to other issues in the debugger (see the list of suggestions at the end).
We haven’t had much opportunity to experience the drawbacks of the current debugger vis à vis asynchronous debugging, but the experience outlined in the call-stack screenshot below is one that is familiar to anyone who’s done multi-threaded (or multi-fiber, etc.) programming.
Instead of showing the actual stack location in the thread within which the asynchronous operation is being executed, the new and improved version of the debugger shows a higher-level interpretation that places the current execution point within the context of the asnyc operation. This is much more in keeping with the philosophy of the async/await feature in .NET 4.5, which lets developers write asynchronous code in what appears to be a serial fashion. This improved readability has been translated to the debugger now, as well.
The VS2013 debugger can now show the “direct return values and the values of embedded methods (the arguments)” for the current line.[1] Instead of manually selecting the text segment and using the Quick Watch window, you can now just see the chain of values in the “Autos” debugger pane.
“We are also releasing an update in Visual Studio 2013 Preview to provide better support for apps that indirectly depend on multiple versions of a single NuGet package. You can think of this as sane NuGet library versioning for desktop apps.”
We’ve been bitten by the afore-mentioned issue and are hopeful that the solution in Visual Studio 2013 will fill the gaps in the current release. The article describes several other improvements to the Nuget services, including integration with Windows Update for large-scale deployment. They also mentioned “a curated list of Microsoft .NET Framework NuGet Packages to help you discover these releases, published in OData format on the NuGet site”, but don’t mention whether the Nuget UI in VS2013 has been improved. The current UI, while not as awful and slow as initial versions, is still not very good for discovery and is quite clumsy for installation and maintenance.
You’re not limited to just waiting on the sidelines to see which feature Microsoft has decided to implement in the latest version of .NET/Visual Studio. You should head over to the User Voice for Visual Studio site to get an account and vote for the issues you’d like the to work on next.
Here’s a list of the ones I found interesting, and some of which I’ve voted on.