Practical .NET
vNext: What's in It for You?
Here's a grab bag of what you might find useful in the next version of the .NET Framework. It's good news for everyone but ASP.NET Web Form developers.
Microsoft is building a new framework for you: vNext. It won't be as radical a change as moving to the original Microsoft .NET Framework, but it will be like moving to the .NET Framework 2.0: Not all of your existing code is compatible with the new framework. And, while there are downloads that let you try vNext out, be careful: You should not install those downloads on a computer with another version of the .NET Framework.
Visual Studio- and Compiler-Related Enhancements
My favorite change is that, while debugging, Visual Studio now displays on the screen how long each method took to execute. This is information that matters to me. Also, after a very long wait, Visual Basic developers get the same support for refactoring that C# developers have had since the .NET Framework first appeared (though, back then, I think the refactoring support that C# developers got was just an apology for how poorly early versions of Visual Studio supported C#).
The Roslyn compiler has an API that allows external tools to tap into the compilation process. I can't imagine that I'll use that facility directly, but it does mean tool providers can provide better feedback on your code, based on what the compiler discovers. But even without those potential benefits, the new compiler does provide you with lots of new functionality.
For example, renaming a variable or member name in Visual Studio is simpler (no fiddling with dropdown lists) and can be done from anywhere the name is used (not just at the declaration). There are also new language features, though none of the announced changes are earth shattering. Visual Basic developers, for example, already seeing the line continuation character disappear, will see even less of it when creating a string that spans multiple line; C# developers will get simpler syntax for moving parameters to fields in a constructor.
The Roslyn team has bragged about how fast the new compiler builds your code while generating faster code but, quite frankly, you may never get a chance to see that. Behind the scenes, Visual Studio has always been compiling your code in the background (that's what gives you error reporting while writing your code). However, when it came time to debug your application some additional build time was required. With Roslyn, that's not necessary any longer: When you press F5, your application should start running almost immediately.
ASP.NET Changes
ASP.NET developers have seen many of the innovations that first appeared in ASP.NET MVC carried over to the Web API environment. That process continued with the latest versions of the .NET Framework, which has a single model for services and application development. That change comes at a cost: There's no Web Forms in vNext, but (like ASP.NET MVC 5, Entity Framework 6 and other .NET Framework 4.5 technologies) Web Form development will continue to be supported in Visual Studio. Web Pages is in vNext for PHP developers coming to .NET and uses the same architecture as services and MVC applications.
If you've created Web API or Windows Communication Foundation applications you know that you've been able to "self-host" your applications and install your application on computers that don't have IIS installed. vNext extends that feature to all Web applications. To put it another way: You don't need IIS Express to build or test your Web application and you can run your Web application from a thumb drive. Coupled with the "ready to run" feature this means that ASP.NET developers can revise their code in Visual Studio, switch back to the browser, and refresh the page to see their changes.
Regardless of how you host your application, you should find that it starts faster and runs with less memory (especially if you run it in the cloud where memory consumption for a basic application has been reduced to less than one-tenth of its old size). In fact, you can decide how much overhead you want to incur: The runtime environment for a Web application is formed from a set of NuGet packages: add as many (or as few) as need.
Interestingly, the new project structure in Visual Studio reflects the pattern used by ASP.NET Web Form Site projects: If a file is in the project folder (or a subfolder) then it's part of the project -- the file is not listed in the project file. Solution Explorer will automatically reflect changes to the project folder -- there's no need to refresh Solution Explorer to see changes, which should simplify integration with third-party tools. Your projects should also open faster because Visual Studio loads the resources it needs asynchronously (and downloads/repairs any missing packages as it does so).
Those last two changes are important: It means that each application can have its own unique combination of packages. Within your organization, some standardization for application environments is probably a good thing or maintenance could become a nightmare. However, these changes effectively carry "side-by-side" deployment for different versions of the framework to its logical conclusion. You should be able to build applications in Visual Studio with the tools you're used to, but you'll now have the option to create your new projects in vNext.
There are more changes, of course, but these seem to be the features that are most likely to survive until the final release and that you may care about. It's another new world, I'm afraid.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.