Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

49 minutes, 48 seconds


Right click “Save as…”

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.


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • stevo_stevo_ Human after all

    Could just be me but struggling to download the wmv (high), 'finishes' sub 100mb (its nearly 900mb).

    edit: don't worry about it charles, I've give it another go tomorrow (btw the size doesn't bother me at all).

  • CharlesCharles Welcome Change

    Sorry to hear that. Yeah, the WMV(high) for an interview of this length is going to be big (it's encoded at 2.5 Mb/s). When you say 'finishes' do you mean the downloader shows completion and exits?

    (We don't need to have this conversation on this thread, however - Click on the Contact Us link on the bottom of the page and we can do this over email)


  • Compiled 2.0 applications not running on Windows XP with 4.0 CLR only installed is a problem.  This will break all applications I have created to date.  The old rules allowed the older exe to run on newer CLR.  My install will test for 2.0 or higher CLR.  If 4.0 CLR is found, the install will not put 2.0 on the machine but my application will no longer run.  This is a breaking change that will affect many applications.

    I don’t have an issue with this change but please make sure you get the word out to developers.  I would also suggest adding an option to the manifest to allow the previous behavior (allow exe to run on any framework higher than the target).

  • Here's an in-process side-by-side scenario on the server:  you have an ASP.NET 2.0 Web application with dependencies on .NET 2.0 assemblies.  You would like to update your application to .NET 4.0.  You don't own the dependencies to update them as well.  What do you do?

  • CharlesCharles Welcome Change

    I will be uploading a new version of the high bit rate file. Seems we have a problem with the current one. Thanks for the notifications. I'll edit this post to let you know when it's available.


    EDIT: I have verified that there is no problem with the file itself and I've successfully downloaded it on two different networks. Seems the root cause is related to geographic location (CDN nodes are perhaps not evenly distributed) and network issues.

  • Thanks for the feedback, that's an interesting scenario we were hoping was going to be pretty rare.  There's no doubt there's a trade-off here between a number of different types of 'breaking changes', and the principle we're relying on in this case is that we'd rather have an application refuse to run than run on a platform it hasn't been tested with and possibly behave poorly. 

    We did spend a lot of time discussing how we will support developers that want a different trade-off - i.e. are willing to take the risk of allowing their app to run on a future version of the framework without having tested it.  This is one of the main reasons we now support 2-part version numbers in config files.  So, you can get almost what you suggest by adding <supportedRuntime version="v4.0"/> to your app's config (and if you really want ALL future versions, you could add v5.0, v6.0, v7.0, etc. - but I wouldn't reccomend it, there's a reasonable chance a complex app tested only against V2 will NOT run well on some CLR released 10 years from now <grin>).

    Anyway, I definitely agree with your point about needing to do a good job "getting the word out".  I've forwarded your comments to the SxS team and we're discussing how best to document this and other potentially surprising behavior related to SxS.



  • Hi Joe.  In most cases that scenario is not something that can be solved with SxS.  In particular, SxS requires a pre-existing isolation in the code - just like app-domains or different processes.  Most of the time when depending on managed assemblies, the code is tightly coupled at the level of managed code (sharing objects freely back and forth without any sort of marshalling/remoting, etc.), and so can't easily be separated by an isolation boundary (appDomain/runtime/process).

    However, this sort of scenario (composable 3rd party components) is one of the main reasons why binary compatibility is still so important for the CLR.   Just like with .NET 1.x->2.0, we fully expect assemblies compiled against .NET 2.0 to be loaded into the 4.0 runtime.  So most of the time, rolling an application forward to 4.0 that has dependencies on 2.0 assemblies should hopefully just work fine.  One notable exception I discuss in the video is IJW assemblies (C++/CLI compiled without /clr:pure or /clr:safe) - those will unfortunately either need to be recompiled or the application will have to be configured to disallow the V2 runtime from being loaded.

    I can imagine some rare cases though where this could be useful (depending on, for example, code though a COM interface that is implemented in .NET 2.0 and doesn't work on 4.0).  And the ASP.Net team does believe there is some value here.  But it'll probably be rare, and not a high priority scenario in 4.0.


  • Rick,

    Thanks for the reply.  What will happen when a new OS does not support the older framework (ie .net 1.0 will not install on Vista)?  You have forced the user to get an update for the application to support the new OS.  Is the Windows team ok with that?  It makes the OS look bad because it is no longer compatible with the application.  The easy answer is to always ship the older framework with the new OS, but I don't think that is going to happen.  This change is effectively putting a limit on the life of the app.  Again I am not against this change, I am simply trying to help find the holes.

  • stevo_stevo_ Human after all

    Like anything windows, legacy is dropped when it passes the balance of requirement vs. maintainability.. .net 1.0 is very obsolete in my opinion.

  • Good question.

    First a couple follow-ups from your original post after talking to some folks on the team.  How exactly are you detecting whether there is any CLR >= version 2 on the machine?  Since CLR v4 is intentionally hidden from the existing CLR v2 APIs, your code may actually do the desired thing and detect NO clr installed.  Also, we've improved the experience on this sort of failure by popping a dialog saying something like "this application requires CLR v2.0 in order to run - click here to download it".  Not perfect of course, but hopefully a helpful mitigation.

    Now for your OS question.  Yes - big picture removing OS support for a version of the framework is a BIG compat decision.  Due to the problem of perfect compatability I discussed in the video, doing this at all is always going to be an issue - regardless of our roll-forward policy (even if we did roll forward, as we did 1.1->2.0, large apps have historically been likely to break unfortunately).  Windows has a similar philosophy in that they work hard to maintain compat, but know they can't be perfect and so also rely on mitigations like compat labs and app-compat shims.  We do the same thing - running the most popular .NET apps in our labs, and where it's advantageous including app-specific compat policy with a new .NET Framework release (take a look at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\AppPatch\v2.0.50727.00000 for example - it lists applications that are known to be incompatible with v2 and so should not roll-forward, we can do a similar thing in v4 where we can list apps that we've tested and know work with v4 and so should be rolled forward).  This of course is only helpful for the biggest most popular apps, but it's helpful nontheless.  Also, OS upgrade boundaries change the compat formula a bit and may influence the policy we choose to apply.  For example, it's possible that a future version of Windows will include only CLR V4 but will be configured to roll v2 apps forward to V4 (we have not made any decisions about what we WILL do here, just intentionally kept this open as an option - these decisions are all controled declaratively by the upgrade policy in the registry).  The key thing we need to avoid is installing a new .NET Framework breaking some application that was previously working fine - upgrading the OS on that machine is a bit of a different equation.

    Still far from perfect, I know.  But the compat space is all about trade-offs between lots of different less-than-perfect options.


  • Hi,

    A coworker best describes the dillema we faced in making this decision:

                   "It’s a tradeoff of where we want the [error] to come from. Failing in a predictable way that leads to the solution vs. failing in a unpredictable (possibly destructive) way with no indication of how to fix it.  I think we’ve made the right choice here."

    Let me expand on this.

    It is almost always the case, even when a high compatibility goal is in place, that software will diverge with each subsequent major version release as a result of innovation and bug fixes (security bug fixes are the most obvious here). These changes will invariably lead to (sometimes very subtle) breaking changes, both intentional (for example, security bug fixes) and unintentional. As a result, applications that worked correctly on one version of the runtime could malfunction (also in a very subtle way) when run on a later version.

    This is precisely the motivation in eliminating the default roll-forward policy in the v4.0 release of the .NET framework. While we strive to make each version of the .NET Framework highly compatible with previous releases with the goal that the vast majority of applications will "just work", we still want authors to evaluate their applications on each release and explicitly opt into running on them.


  • I am using the AllowLaterVersions Property (Launch Conditions) http://msdn.microsoft.com/en-us/library/aa983311.aspx.  This was provided in VS 2005 IDE.  I did not realize it was removed in the VS 2008 IDE.  Since it was removed in VS 2008 IDE and defaulted to false in VS 2005 IDE, it is likely a smaller problem than I thought.

    Thanks for all the feedback.  Keep up the good work.

  • CharlesCharles Welcome Change

    The CDN issue in England and the Netherlands was resolved last night (PST).


  • Hi,


    really interessting stuff you got their!  Their is only one point i still struggle with: "Assumed i have the level of isolation you mentioned in the video, is it possible to load to an managed clr2 application the clr4 runtime In-process SxS (and vice versa)?  If yes, what do i have to do? Is their any managed api i have to call? Or do i need the come layer or something which then loads the other clr for me?  Are their any samples for the beta1 where i can have a look at?






  • Hi Dan,

    CLR loading is really something that happens through native APIs, either using hosting APIs directly (eg. ICLRMetaHost), or indirectly via COM.  You can do this in managed code (no need to actually write any native code) by using .NET's interop facilities.  So yes, you could write code that ran in CLR v2 which loaded CLR v4 and vice-versa. 


    I know we've got some code samples in the works, but I don't think they've been posted yet.  Keep an eye on the SxS category of the CLR team blog. The simplest way is to build a managed COM component using one version of .NET, and then instantiate it using COM-interop from another version of .NET exactly as you would without SxS.  Look for any samples for building and using COM components with .NET 2.0.


    I hope this helps,


  • Hi Rick,


    thanks for the fast response! That really helps.


    Just to make sure that i got it right: In order to use SxS you have to call the hosting API. This can be done directly (in native code or in managed code by using interop facilities) or indirectly via COM. In the COM scenario the hosting API is called automatically for me within the COM functionality?


    Therefore the easiest way to get an running example of calling CLR SxS in an managed application is using COM in a cross clr scenario. The other way is to do this manually by calling the hosting API...






Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.