Entries tagged with clr 4 - Channel 9

.NET Framework++: Moving Forward and Staying Compatible with the Past

Charles — Wed, 10 Jun 2009 02:58:00 GMT

You've recently learned a good deal about the next version of the CLR here on Channel 9. One of the things that is top of mind for engineers who create and consume the .NET framework (CLR + BCL) is compatibility with previous versions. In fact, much like security, compatibility is something that is front and center during feature design meetings: "Will this break an application that depends on the version we're updating?". The question is easy to understand, but extremely difficult to answer without extensive testing, implementation refinements, extensive testing, implementation refinements... In some cases, due to impossible compatibility requirements, new features do not see the light of day. It's just part of the business, part of the dance of software evolution in the context of real world customers who depend on current iterations of .NET.

Here, we meet some of the folks who spend a great deal of time ensuring that the compatibility bar is met, breaking changes are isolated and communicated and bridging the gap between dreaming up new features and not breaking old ones. This is a very hard job and often does not receive the credit it deserves (well, at least from the outside looking in). Principal Test Manager Alain Raitt, Program Manager Preeti Kurup, and Program Manager Lead Mike Downen share with us the challenges and opportunities of compatibilty, the advances in the state of the art of compat testing and future directions. Much thanks to you three and the legions of engineers who ensure that the next versions of .NET remain as compatible as possible with older versions.

Ian Carmichael: The History and Future of the CLR

Charles — Tue, 09 Jun 2009 16:18:00 GMT

Ian Carmichael has been working on the CLR team since before Microsoft came up with the .NET branding for our managed platform and the virtual machine that powers it all, the Common Language Runtime. Well, we're getting close to the third major release of the CLR, CLR 4 (V3 was really a service or minor release, but who's counting?).

Back in the good old days prior to V1, Ian was an engineer and a peer of Chris Brumme, Vance Morrison and other top of the line engineers working through the architecture, design and implementation of the CLR. Now, Ian is the GM of CLR and he's at the helm plotting out the course for CLR's future. Necessarily, we had to sit down with him to pick his brain about CLR then, now and tomorrow. Tune in. Get a glimpse into the past and future of the CLR from somebody who's been deeply involved with the advent and evolution of Microsoft's now ubiquitous managed runtime.

Raja Krishnaswamy and Vance Morrison: CLR 4 - Inside Type Equivalence

Charles — Fri, 05 Jun 2009 17:12:00 GMT

You recently learned about CLR 4's support for type equivalence in a conversation right here on C9 with Raja Krishnaswamy and Jesse Kaplan. The idea of type equivalence and its potential usefulness beyond simplifying and de-bloating COM interop that employs Interop Assemblies (CLR 4's No-PIA feature) led to the need to sit down with Raja and Vance Morrison to really dig into the thinking behind the technology. How does type equivalence actually work? What are the semantics and why? In the VS 2010 timeframe, what should developers expect to be able to do with this new programming abstraction? What types make sense to mark as equivalent? Why? Where does Type Embedding fit into this picture and what role does the compiler play in the No-PIA dance? What impact may this have on the future of managed-to-managed type "interop"? What's the story here? What's next?

This is a great conversation with the primary minds behind type equivalence support in CLR 4. Enjoy.

Rick Byers and Simon Hall: CLR 4 - Side-by-Side In-Process - What. How. Why.

Charles — Wed, 03 Jun 2009 19:16:00 GMT

CLR hosting has always been a hot topic. Consider the case of Windows Shell Extensions and the inability to load more than one CLR version per process being the dagger in the heart of the very idea of scalable managed shell extentions. With CLR 4, consuming applications will be able to host both a CLR 2 and CLR 4 in the same process. Again, gone are the days of single instance CLR per process. The implications here are profound. On the one hand, this means that applications can run code targetting an older CLR version and code targetting CLR 4 in the same process. How does this work, exactly? What are some of the key supported scenarios for mulitple CLRs per process? What does CLR In-Proc Side-by-Side mean for the future of CLR hosting, generally?

Meet two of the CLR SxS In-Proc developers, Simon Hall and Rick Byers. They explain exactly what went into the SxS In-Proc design, the challenges and opportunities. Tune in to get insight into the thinking behind the thinking in CLR 4's side by side in process hosting.

Erika Parsons and Eric Eilebrecht : CLR 4 - Inside the Thread Pool

Charles — Mon, 01 Jun 2009 16:46:00 GMT

General purpose thread pools are more complicated to get right than you may think. In CLR 4 (the next version of the VM that powers .NET), the thread pool has made some significant advances in performance and support for concurrency and parallelism.

Since V1, .NET programmers have been afforded the luxury of an automatic queue-dequeue-execute-from-the-queue thread management infrastructure inside the CLR. This is .NET's Thread Pool.

As expected, the CLR's thread pool has improved with each iteration of the CLR (hey, V1 was, well, V1...). The goal has always been efficient, reliable, performant thread management. With CLR 4, the team that designs and implements the thread pool, have made some truly compelling changes, which should add up to a very solid thread pool shipping with CLR 4. One of the big changes is the addition of thread-stealing algorithms to support concurrency and parallelism. Indeed, CLR 4 has native support for the Parallel Computing Platform's Parallel Extensions for .NET. What does this mean, exactly? How does it work, exactly? What else is new in CLR 4's thread pool?

Meet developer Eric Eilebrecht and program manager Erika Parsons. Eric helped implement the thread pool (he's been doing this for multiple versions, actually). Erika, as PMs do, helped design the thread pool and ensured that the design and implementation meets the needs expressed by customers who rely on the thread pool.

Tune in. Lots to learn. You'll be impressed both by the enhancements and direction set forth for the future in CLR 4's thread pool.

Eric has some great blog posts on the new addtions to the thread pool in CLR 4 that will be very useful for expanding on the knowledge you gain from this conversation.

Surupa Biswas: CLR 4 - Resilient NGen with Targeted Patching

Charles — Thu, 28 May 2009 18:18:00 GMT

Surupa Biswas is a Program Manager on the CLR team working on NGen, CLR's Native Image Generator. The Native Image Generator (ngen.exe) creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.

What happens to current NGen images when you update the .NET Framework or CLR by installing a patch or new version of the framework/CLR? Do you have to NGen everything all over again? Well, yes, today you do. Today, NGen images are rigid. But this conversation is about tomorrow, beginning with CLR 4. What do you think the answer is in the future context?

Tune in. Learn about what Surupa and team will be delivering in CLR 4 to enable resilient NGen via targeted patching. This all adds up to enabling framework and CLR patching/updating without requiring the regeneration of native images already stored in the local native image cache. How does this work, exactly? What are the implications of image resiliency on the future of patching?

Shawn Farkas: CLR 4 - Inside the new Managed Security Model

Charles — Wed, 27 May 2009 19:10:00 GMT

Senior SDE Shawn Farkas digs into the new security model in CLR 4. Gone are the days of head scratching complexity when it comes to reasoning about security in the managed world. The main goal for CLR 4 security was simplicity, in design and implementation for consumers (developers) of both security policy and secure design at the code level (both of these have been traditionally overly complex with a side effect of enabling insecurity rather than preventing it).

Shawn has been working on security inside the CLR (which of course manifests itself in the managed code and libraries you use to build your applications and services). He and team have been very, very busy over the past few years essentially rearchitecting the core security model of the CLR. What, exactly, have they done? Given the somewhat drastic changes, how does this impact compatibility (especially for those applications that took the leap and built complex CAS and policies into their applications)?

There's a lot of very useful information in this conversation with plenty of whiteboarding. It's great to see the managed security model evolve into a much more simple expressive model with policy patterns that mere mortals can understand and reason about. Great job Shawn and team! Thank you.

Tune in. Meet one of the minds behind CLR 4's security model.

Enjoy

Raja Krishnaswamy and Jesse Kaplan: CLR 4 - Inside No-PIA

Charles — Wed, 27 May 2009 15:43:00 GMT

Principal Architect Raja Krishnaswamy, Program Manager Jesse Kaplan and team have created a new way to streamline and simplfiy PIA-based COM Interop: rather than including an entire PIA (Primary Interop Assembly) in your application to utilize the functionality of a few of its member classes, with CLR 4 you are able, via type embedding and type equivalence, to include only the objects you need which has the pleasant side effect of decreasing the size of your application and making it much easier for you to update without relying on a new PIA version from some third party (like Microsoft Office, for a canonical example). How does this work, exactly? Does this mean that PIAs are no longer required? How does versioning in this scenario work, exactly? Let's learn all about the thinking behind the thinking of this new CLR enabled feature, No-PIA.

You will learn, in great detail, about Type Equivalence in a soon to be released conversation with Raja and Vance Morrison. For now, wrap your head around No-PIA. Raja and Jesse are great at explaining complexity in simple to understand ways.

No-PIA in CLR 4 is the beginning of something very, very useful (consider the non-interop scenario (managed to managed) for a moment. Fascinating, Captain.)

Enjoy!

CLR 4: Debugging and Profiling API Enhancements

Charles — Tue, 26 May 2009 19:07:00 GMT

Developers Thomas Lai and David Broman join Program Manager Jon Langdon to share with us some of the new debugging and profiling enhancements in CLR 4. They've done a lot work in the upcoming release and besides evolving debugging and profilining capabilities and semantics (APIs), they've implemented (or fixed) many things customers have been asking for.

The managed debugging and profiling story with CLR 4 is based on a new core architecture (they are moving to an out of process model which means you'll be able to debug multiple threads rather than being stuck to the same thread(s) attached to the main context. Something like that. Watch, listen, learn.).

Tune in to learn about some of the design decisions made to support moving out-of-proc, improving debugger and profiling reliability, enhanced core APIs, future directions and meet some of the people who design and implement these important engineering components for the managed (.NET) world.

Enjoy.

Maoni Stephens and Andrew Pardoe: CLR 4 Garbage Collector - Inside Background GC

Charles — Tue, 26 May 2009 16:06:00 GMT

Maoni Stephens is a software developer who spends her time implementing .NET's GC. In fact, she's been working on the GC since the early days of .NET. Andrew Pardoe is the GC PM. The last time we focused on GC on C9 was a conversation with GC creator Patrick Dussud. In that conversation he suggested that we talk to Maoni to get some more deep insights into how the CLR manages object lifetimes.

The .NET GC has always been a very efficient and well crafted general purpose collector. Now that CLR 4 looms on the horizon, how has the GC evolved to meet the needs of the future? Maoni has been very busy for the past few years and with CLR 4 the GC team have come up with a new concurrent collection strategy called Background GC, an evolutionary state of concurrent GC. What comes next?

From Maoni's blog:

Background GC is an evolution to concurrent GC. The significance of background GC is we can do ephemeral GCs while a background GC is in progress if needed. As with concurrent GC, background GC is also only applicable to full GCs and ephemeral GCs are always done as blocking GCs, and a background GC is also done on its dediated GC thread. The ephemeral GCs done while a background GC is in progress are called foreground GCs

Tune in and meet the main developer of .NET's garbage collector and a recent addition to the team who comes from the native world and will drive GC into the future.

Enjoy!

Inside .NET 4: Meet the BCL Team

Charles — Thu, 21 May 2009 18:13:00 GMT

Much of what you can do with .NET, from a compositional perspective, is enabled by the vast functionality housed in .NET's huge base class libraries (in fact, the BCL is what provides all the incredibly default(part of the .NET framework) useful objects you use to paint your binary vision). Who are some of the folks who think up and write the BCL? Who tests the BCL to ensure these libraries do what they claim to do and in a performant, reliable and predictable way? What are some of the innovations in the BCL that ships as part of Visual Studio 2010? Tune in and find out the who, what and why behind BCL 4.

Members of the BCL team in this interview:

Josh Free
Brian Grunkemeyer
Matt Ellis
Justin Van Patten
Melitta Andersen
Matthew Greig
Kim Hamilton
Katy King

Enjoy!

Vance Morrison: CLR Through the Years

Charles — Tue, 19 May 2009 15:48:00 GMT

CLR Architect Vance Morrison has been very busy working on the future of the CLR, especially as it relates to execution performance and the type system. Some of his latest work is present in the upcoming 4th version of the virtual machine that powers all things .NET, CLR 4, which ships with Visual Studio 2010. Vance has been on the CLR team since its inception. MSIL, the intermediate language produced by the compilers of all .NET languages, is primarily Vance's doing.

Here, Vance guides us through some of the history of the CLR, a look inside the upcoming version and some insights into the future. One of the things that Vance is thinking about with respect to type inheritance is what he calls default interfaces: they are contractual, but with default implementation characteristics, as opposed to purely abstract as interfaces are today. So, a default(implementation) interface is capabe of changing without breaking the systems that implement it. Wait a minute, that' goes against the basic rules of interfaces in the OO world. Vance explains. Relax.

Meet Vance, the face of MSIL. There's much of his thinking and code inside the CLR. Learn about some this here. Tune in.

Enjoy.