A number of CLR hosts may want to update to use the new v4 MetaHost APIs for runtime activation in order to support in-proc SxS, but want to continue working on a machine with only v2 installed.  This is a common scenario, used by Office and some other internal partners, and I imagine it would be a common customer scenario as well.

We’ve already covered that getting off of the legacy shim APIs is critical to supporting in-proc SxS, but once you move off them, you are stuck only working on a machine that has v4 installed.  Not to worry, it is fairly easy to “fall-back” to a legacy activation path in the case that the new APIs are not present.

The gateway to the new MetaHost APIs is CLRCreateInstance, if it isn’t present, you know that the new APIs aren’t available to use.  So, you simply need to do a “late-bound” call to it via LoadLibrary/GetProcAddress.  If GetProcAddress returns NULL, then you need to fallback to the legacy activation (CorBindToRuntimeEx or similar).  However, the function could be present, but still not be available to use.  The export is on mscoree.dll, but its implementation actually lives with the runtime itself (mscoreei.dll, which is new in v4).  If no mscoreei.dll is available to handle the implementation, mscoree will return E_NOTIMPL from CLRCreateInstance.  This could occur if your mscoree.dll has been updated as the result of an OS servicing event, or if you’ve installed/uninstalled .NetFx 4.

So, the basic decision tree is this:

1. LoadLibrary mscoree. If this doesn’t work, then there is likely no CLR installed at all, move along, nothing more to see here.
2. GetProcAddress for CLRCreateInstance. If this doesn’t work, fall back to CorBindToRuntimeEx or similar.
3. Call CLRCreateInstance to get ICLRMetaHost/ICLRMetaHostPolicy.  If this doesn’t work, fall back to CorBindToRuntimeEx or similar.
4. Otherwise, party on the interface you just got!

This post is intended to fill a gap in the current MSDN documentation for this attribute (http://msdn.microsoft.com/en-us/library/bbx34a2h(VS.100).aspx).  This gap should be filled by the time .NET 4 ships.

There is alot of confusion about what the useLegacyV2RuntimeActivationPolicy attribute does.  Most often, it is used to allow a pre-v4 mixed-mode assembly to load in v4.  In that context, the name makes very little sense.  Below is an explanation I’ve provided to people internally that explains the attribute in the context for which it was named.  This should give people a better idea of what it does, as well as understand some of the subtlies of in-proc SxS.

Ultimately, this attribute has to do with the behavior of the “legacy shim APIs”.  You can think of these as encompassing several categories of CLR activation:

• CorBindToRuntimeEx and friends - This includes most of the flat exports of mscoree.dll defined in mscoree.h (GetCORSystemDirectory, GetCORVersion, LoadLibraryShim, etc). Note, this also includes the strong name APIs defined in strongname.h)
• Pre-v4 COM activation – This includes CoCreateInstance of a CLSID (or type identifier) whose latest registration is against a pre-v4 runtime version. Note this includes both the “new” operator on such a co-class from managed code, or the result of Activator.CreateInstance against a type created by Type.GetTypeFromCLSID on such a CLSID.
• Pre-v4 IJW (mixed mode) activation – For example, calling into a native export on such an assembly
• Native activation of a native runtime-provided COM CLSID – Such as CoCreateInstance on ICLRRuntimeHost’s CLSID
• Native activation of a managed framework CLSID – Such as CoCreateInstance on System.ArrayList’s CLSID (extremely rare)

All these have a “single runtime per process” view of the world, so we try to make those codepaths believe they still exist in that world by “unifying” the version that they see.  After a given version has been chosen by one of these codepaths, that’s the version that all of them see for the remainder of the process lifetime.  Additionally, all of these activation paths had some kind of roll-forward semantics associated with them.  We “cap” those semantics at v2, meaning by default none of these codepaths see v4 at all.  This allows us to claim that installing v4 is “non-impactful”.  It should not change the behavior of existing components when installed. (Note that this has the interesting side-effect of a v4 only machine appearing to have no runtimes installed at all via these codepaths.)

This is all well and good until someone WANTS those codepaths to see v4.  Rolling a v2 managed app forward to v4 using a config (without the attribute) works just fine, unless that app also expects interaction with these “legacy” codepaths to be associated with the current runtime (v4).  For instance, a p/Invoke to GetCorSystemDirectory in order to construct a path to Fusion.dll (please don’t do that, BTW) will give you v2’s fusion.dll.  COM activation of a managed COM object will prefer the runtime it was built against rather than load into the current runtime (meaning you may be dealing with interop rather than a concrete CLR type). That may work, and it may not, depending on what you’re doing.

The useLegacyV2RuntimeActivationPolicy attribute basically lets you say, “I have some dependencies on the legacy shim APIs.  Please make them work the way they used to with respect to the chosen runtime.”  In that context, hopefully the name makes more sense to you. It is *mostly* equivalent to calling CorBindToRuntimeEx using the full version string for v4.  We also have a method in our new shim APIs to do this programmatically, the difference being that in a config file, it can be done declaratively, which is useful for a host that uses config files to determine which runtime to load plugins into. (the attributes value (or lack of value) is conveyed back to a host via the pdwConfigFlags parameter of ICLRMetaHostPolicy::GetRequestedRuntime)

One of the big reasons people need to do this is if they have a dependency on a pre-v4 IJW assembly.  By default, we can’t allow those to load into v4*.  Putting this attribute in your config allows this to happen.

Why don’t we make this the default behavior? You might argue that this behavior is more compatible, and makes porting code from previous versions much easier. If you’ll recall, this can’t be the default behavior because it would make installation of v4 impactful, which can break existing apps installed on your machine.

Well, why don’t we make this the default behavior for v4 managed apps?  Well, that is precisely the behavior we had for beta 1.  As we started trying to explain the behavior to people, we found it was very difficult to explain how these legacy codepaths worked.  We ultimately decided that making the behavior consistent was better.  The example that ultimately convinced me we had made the right choice was that the behavior of a library would change based on whether it was hosted by a native process or a managed one.  That seemed really bad to me.

You might say, “Why shouldn’t I just set this for every app I have?” Well, the downside of this attribute is that it turns off in-proc SxS with pre-v4 runtimes.  It locks them out of the process.  This may not matter to your scenario.  If you look at some of the runtime tools, they are using this attribute.  Even Visual Studio uses this attribute.  Don’t just blindly use it though.  If you' find yourself needing it in something other than a migration aid, or for loading pre-v4 mixed-mode assemblies (which we hope becomes more rare moving forward as people start updating the interesting mixed-mode binaries out there), I’d like to know about it.  Leave me a comment!

Hopefully, you’ve got a better handle on exactly what this attribute means, and can make a more informed decision about when it is appropriate to use.

*There are many engineering challenges around in-proc SxS and IJW assemblies.  Currently, pre-v4 IJW assemblies can only load into the runtime that is associated with the “legacy shim APIs”.  But any given IJW assembly (regardless of version) may only be loaded into a single runtime per process at this time.

I just posted on the CLR Team Blog about this: http://blogs.msdn.com/clrteam/archive/2009/05/14/why-is-appdomain-appendprivatepath-obsolete.aspx

I’m trying to figure out what criteria I will use when determining when I post contents here, and when I post them on the CLR blog.  I’ll definitely post links here if I put content up there.

Today, is my nephew’s birthday.  I had a great time a few weeks ago, visiting with my Brother’s family in Midland.  I got to play with Landon and get to know him a bit.  He’s a hoot.  He’s got a ton of energy, and just goes non-stop.  If you’ve ever seen the movie “Flubber” (preferably the classic), he’s alot like that stuff.

Happy Birthday, Landon!

[A quirk in my blog resulted in this post being posted much earlier this month, so you may have already seen it.  Today is his REAL birthday]

[humorously enough, another quirk caused the originally scheduled post to appear at the correct date (although a bit late in the day)]

Today, the little choncho turns 3! It really is unbelievable to me that she could be this old.  We woke her up this morning, and gave her one of her presents, some butterfly wings.  She really liked them.

I’ll take a rare moment to brag about her publicly, not because I think she’s better than your kid, or because I’m an awesome parent (I’m not), but because I love her and I’m so proud of her.  She is so awesome and sweet and polite (most of the time).  Even when she’s upset, she’ll say “thanks” when you hand her something.  She’s beginning to read, can do some simple math, and loves to draw and paint (the latter can become quite messy).  She builds the greatest things out of blocks and legos.  We went to Red Robin on Sunday, and I asked her to circle the items she wanted from the kids menu.  She circled mac ‘n cheese and oranges.

Happy Birthday, Choncho!

My brother-in-law posted a note on Facebook that was basically one of those silly things you do and perpetuate across the internet.  I usually don’t take part in such things, but this one seemed interesting, and I’ve been thinking about ways to jumpstart my blogging again now that the embargo on all the cool stuff is lifted.  So, I thought I would do it.  Here are the rules:

• Grab the book nearest you. Right now.
• Turn to page 56.
• Find the fifth sentence.
• Post that sentence along with these instructions in a note to your wall. (this was on Facebook, so it is referring to that wall)
• Don't dig for your favorite book, the coolest, the most intellectual. Use the CLOSEST.

So, it took me a while to determine which book was the “closest”, as my position is roughly normal to the bookshelf in my office.  I finally decided to be honest and pick the one that was really closest, but I will share another that was very close, as it is a good segue into future blogs.

The first (and official) one:

Semiconductor materials at 0 K have basically the same structure as insulators – a filled valence band separated from an empty conduction band by a band gap containing no allowed energy states (Fig. 3-4).

Solid State Electronic Devices, Ben G. Streetman

The second, and more relevant/interesting one:

The shim’s algorithm for picking a version in the COM interoperability scenario is much more straightforward – the latest version installed on the machine is always used.

Customizing the Microsoft .NET Framework Common Language Runtime, Steven Pratschner

What is amazing about this second one is that this is directly related to one of the features I’ve been working on for CLR v4 (and yes, that is actually the 5th sentence on page 56).  Namely, this feature is known as “in-process side by side” (or in-proc SxS for short), and was announced publicly at PDC last month.  This feature allows you to have more than version of the CLR loaded and running in a single process.

This feature is primarily a compatibility feature, targeted precisely at the behavior noted in the quote above.  When we use the latest version, we can break existing COM objects.  Not only because of breaking changes we make (of which the number is fairly small), but because of other, more subtle behavior dependencies.

Previously, loading a CLR version into the process locked the process to that CLR version.  Any other policy than “pick the latest” results in a load order dependency problem that can result in “for sure” breaks because COM components targeting newer runtimes cannot run on old runtimes.  So, clearly, that was the best choice of policies.

Now that we support multiple runtimes in the process (v2 and above), we can make a smarter, more compatible choice about runtime activation.  The precise policies are still being worked through, so I’ll avoid stating them explicitly, but you can imagine us being able to make a much better choice about what runtime to activate to run a given managed COM component.

I’ll be posting more about this feature and it’s implications soon.  Feel free to seed my future posts with questions in the comments.  Hopefully, this is the jumpstart I needed.  As for the “game” above, feel free to do it, or ignore it.  It won’t result in any difference to your luck, financial situation, or anything else.

I just leveled up my uncle character!  Luke Andrew Miller was born Sunday night (Oct. 19th) at 9:39 PM.  6 lbs. 13 ounces, 19 inches.

I had originally planned my trip to visit my brother Andrew to be well before Luke was due, but he was so excited to see me that he had to come early :).  It was so great that I was able to help Andrew and Sara out while I was there.  I got alot of play time in with my nephew Landon, who I haven’t gotten to see hardly at all since we moved to Seattle and they moved to Midland.  While Andrew and Sara went to the hospital, I watched Landon and we had a great time.

Hanging out with Andrew was also a blast.  We play Halo together all the time, but it’s just alot more fun to hang out in person.  We didn’t have much of an agenda, just hanging out and inventing weird games to play.  He also introduced me to some new kid’s shows that I think Jenna will enjoy.  WordWorld is awesome.  I got Jenna the cat, which you can take apart into the the letters C, A, and T.  She LOVES it.

I also got to eat a bunch of food that isn’t available where I live:

• Chick-fil-a – I had chicken minis for breakfast when I arrived, and we ate there again later and I had 2 sandwiched, and some nuggets.  Delicious.
• Blue Bell Ice Cream – I really don’t know how they make it so good.  It is far and above better than any other ice cream available in Seattle.
• Sonic – I usually opt for a flurry, but I had already eaten a ton of Blue Bell, so I got a vanilla coke (a coke with vanilla added, not the Vanilla Coke that coke makes).
• Mexican Food – Sure, there are a bunch of Mexican food places here in the Seattle area, but they pale in comparison to what’s available in Texas (especially Midland).  I had chicken fajita soft tacos and sopaipillas from Rosa’s.

There simply weren’t enough meals to hit everything I wanted.  I missed out on Whataburger and On the Border (more Mexican Food).

You can check out my Flickr set, which is a ton of pictures of Landon, and a few of Luke at 5:00am when I got to meet him before flying out.

Richard Lander, one of our PMs, just started a series of posts on deployment.  Specifically, he’s taking the approach of thinking about your v2 strategy while you are still working on v1 of your product.  If you’re already on v3 of your product, don’t worry.  There will still be some useful, interesting information for you. The first post just lays the groundwork for the discussion, so stay tuned for the rest.

I didn't get up an anniversary post yesterday because I was busy DOING stuff for my anniversary this year.  Unbeknownst to Becky, I arranged to take the day off. I sneakily got a late-morning massage appointment for her, and lined up a babysitter (thanks, Molly) so we could go see a movie in the afternoon.  Everything went off without a hitch.

We went to see the latest Indiana Jones movie, which we enjoyed very much despite the somewhat less than explanatory ending. We hadn't been to the theater to see a movie since Pirates II.  But, we both agreed that we aren't missing much except time alone and seeing the latest movies.

Some of my posts that I get the most recurring email/inquiries on are my various posts about the STDF (Standard Test Datalog Format) parser that I originally created as an experiment back in 2005.  After some help from a former collegue, I am pleased to announce that this is finally available on CodePlex as LinqToStdf!

It is a managed library for processing STDF files, and gives you a model to explore the data via Linq queries.  This means, you can leverage the wide variety of managed languages (C#, VB, F#, JScript, IronPython, IronRuby, Managed C++, Boo, etc.) to process the data in STDF files.  It also works in Silverlight!  It has built-in support for the V4 spec, but it's highly extensible and should be able to parse any version of the file format as well as custom records.  It can be configured to be highly strict and throw on format errors, or be robust in the face of issues that normal STDF processors would choke on to the point of being able to detect and repair corruption on the fly.

If that interests you, I'd love for you to drop by and take a deeper look at it and get involved in its ongoing development.  I've already got at least one person interested enough to contribute and ensure its success as a community project.  There is currently a "beta" release available, and hopefully we'll whip it into shape enough to call it v1.0 soon.

My hope is that this can be an adoption driver for .NET in the semiconductor industry and that through this project I can be an ambassador for the CLR in that area.