I’m continuing to channel how excited I am about my Pluralsight course “What’s New in .NET 4.5” into a series of blog posts with the most important thing(s) in each module. Sure, I won’t mind if these posts inspire you to watch my course, but I’m also doing this so folks that can’t watch my course can still get the most important information.
Module 2: Changes to the Core Framework
There is a whole lot of information in this module, and I might come back to the most important thing in each clip. But for right now, I’m going to maintain discipline and focus on the single most important thing, which has two parts.
That would be the changes in how we deliver applications – how libraries are arranged and how MSIL becomes native code on the target machine. I’ll focus on how libraries are arranged, with just a smidgen on native code creation because it deserves a dedicated post.
Portable Class Libraries
You might have heard about Portable Class Libraries. It’s a new type of class library you can create that will run on the platforms you choose. Right, that’s platformS, plural. In the box you’ve got .NET main framework, Silverlight, XBox, Windows Store and Phone. Online, you’ve got more, including Azure and updates to other platforms.
In these libraries – these DLLs – you can only do things that work across all the selected platforms – the limited intersection of behavior. You’re not going to write your entire application this way, but you can create key libraries with business rules, calculations, maybe service access, maybe View Models – you get the idea. This, of course, directly useful. It also causes both you and Microsoft to rethink the concept of a DLL.
Using Portable Class Libraries will force you It will instill new discipline in your designs, and I’d encourage you to begin moving everything possible into Portable Class Libraries just for this reason.
Isolated designs have been on our whiteboards for years – like View Models without any UI artifacts. But enforcement was by .NET libraries – and they were designed for many reasons other than correctly dissecting your code. No one that created reflection had a clue that it would look fundamentally different in a Windows Store application.
Visual Studio provides the appropriate IntelliSense and the compiler structures the correct libraries. We coders work organically. There are things we learn to do reflexively, and you want the classes and methods you reach for to be the right ones – generally that means the techniques with the broadest reach. As you learn what works within your Portable Class Libraries, you’ll learn what works across multiple platforms.
I’ll warn you that the jury isn’t entirely in on some critical details, such as using async across some of the different platforms, but many core features work flawlessly today, and the others are sorting themselves out.
Prior to .NET 4.5, the .NET libraries were fairly large units and completely different versions were created for alternate platforms. Just ask a phone developer how painful this pattern was as new sets of redesigned libraries reflected changes in how .NET was interpreted for the platform.
Starting with apps targeting .NET 4.5, there’s a new approach to core assemblies. This reflects platform differences, such as how local storage works, and isolates commonalities. Sometimes, such as the new Zip libraries in .NET 4.5, libraries can be designed with portability in mind.
It doesn’t make sense to restructure legacy assemblies to meet today’s vision, because today’s arrangement will be tomorrow’s legacy. Instead a huge effort behind the scenes created smaller leaner libraries that can be pulled together, and a redirect system that means you no longer care where any piece of functionality resides.
You can see this in Object Browser. View Containers to show the assemblies (from the gear for settings) and select “Portable Class Subset” (not legacy) from the dropdown. Now open mscorlib. Huh!!! It’s empty. That’s a bit of a surprise.
Now open System.Runtime – which is one of the many libraries that didn’t previously exist. It’s got all that mscorlib stuff. What you need at runtime will be there – but in an assembly location that’s platform dependent.
Nowhere is the importance of PCL more evident than with the newly designed reflection. It needed an overhaul. It sits at a critical junction of many other things – often causes performance problems of design compromise to avoid performance issues. For example, if you ask for the members of a type, assemblies containing all base types must be loaded. Also, GetMembers and its siblings have horrendous enum dependent overloads to help you filter the results.
Microsoft redesigned reflection for Windows Store applications. I’ll skip the details, but the GetMembers method is replaced with a DeclaredMembers property that returns an IEnumerable you can party on with LINQ. It doesn’t load any base class assemblies – if you want that, walk the tree so you understand what’s happening. The team also split the name of the type separate from all other functionality. The name is often enough and avoids loading even the class’s assembly.
This quick sketch of the massive change lets me illustrate why you want to move reflection based code into PCL projects.
.NET main framework projects need to support the old and new reflection approach. Instead of ditching the old stuff and creating a new namespace, they extended existing reflection to include the new features. I’ll leave it to the video to explain the inheritance hierarchy sleight of hand that let’s this happen. But the resulting classes have all the features of the old and new reflection approaches.
While I agree with this decision to allow smooth transition of existing reflection code with no breaking changes, I think it makes it nearly impossible to learn and use the new reflection approach – unless you create a PCL targeting main framework and Windows Store apps and do as much of your reflection work as possible in this assembly.
You’re already doing all your reflection in utility methods – right? No? Well, then this is also a moment for reflection, er, um, no, um, meditation, contemplation, deliberation, musing, rumination on the nature of an evolving framework and how to structure code to survive this change. That’s more posts, and I’ll get to them, but for now, reflection of your poster child of constructive change you’ll need to roll with.
JIT and NGen
It’s a separate blog post series, but I just can’t talk about this module without talking about JIT and NGetn. Your actual delivery is changing. There are now six, or is it seven, different ways IL can turn into native code on your target machine. It’s a pretty big set of changes, and I promise a blog post that cuts through some of the detail I hit in the video to more simply explain how to choose your approach. But don’t worry, for most people, most of the time plain old JIT remains the best approach (maybe with a little chocolate sprinkles).
Core Library Changes
Does my focus on the library creation and deployment mean that there weren’t any meaningful changes to the libraries themselves – new classes and methods? No, it doesn’t mean that at all.
There were a lot of changes to the core frameworks, and I hope to come back and give the most important couple of items from each clip in this module – changes to reflection, big arrays, console improvements, and, most exciting of all, real Zip support. These are great improvements, but none of them stand out as changing your development the way PCL does.