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

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.

Thanks!

     Rick

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