.NET 4.5.1 and Visual Studio 2013 previews are available

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.

x64 Edit & Continue

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).

Async-aware debugging

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.

Regular Call stack (VS2012)

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.

Async-aware Call stack (VS2013)

Return-value inspection

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.

Automatic return-value inspection

Nuget Improvements

“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.

User Voice for Visual Studio/.NET

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.

• Support Edit & Continue for all method bodies: While it is, to some degree, understandable that methods, fields and constants cannot be added or removed easily without restarting the debugger, method bodies can be modified. Unless they include lambdas or generics. Experience has shown that this means that we can’t use Edit & Continue for most of our code. VS needs to allow the modification of lambdas and anonymous methods or the even higher-rated issue, Debug Lambda expressions. The other missing piece of this puzzle is to add Support for generics under Edit & Continue.
• Better Generics and Design-by-Contract support: Language feature requests include Expand Generic Constraints for constructors, allow [p]roper (generic) type ali[a]sing and, near and dear to my heart, Integrate Code Contracts more deeply in the .NET Framework or Integrate Code Contract Keywords into the main .Net Languages.
• There seem to be a lot of people asking Microsoft to work on Silverlight 6. Having developed several applications in Silverlight 5, we wouldn’t be averse to seeing continued support rather than obsolescence for those projects.[2]
• Make Visual Studio run faster and leaner: There are also pleas to Decrease the Memory Footprint (of Visual Studio) or Make Visual Studio startup and shutdown faster and Make [Visual Studio] Solutions Load Faster or at least Improve performance of Visual Studio builds and other uses better when working with solutions with several projects (ex. 40+). Other ideas in this vein are add a Visual Studio Task Manager so we can at least see which components, plugins and panes are causing trouble. If all else fails, just [m]ake VS scalable by switching to 64 bit.