A first hand look from the .NET engineering teams
The new installment of the “CLR Inside Out” column in MSDN Magazine is now available on line. This month we have an article from Jesse Kaplan and Luiz Fernando Santos on In-Process Side-by-Side. The article contains details on this new .NET Framework 4 feature and the problems it solves. It is especially useful for add-in or COM component developers and those wishing to write managed shell extensions.
You can find a list of all “CLR Inside Out” articles here. It’s a new link this month, as MSDN Magazine has updated their site. As always, please let us know if you have topics you’d like to see covered in the column.
Hi.
I read the article and have a question about it. I understand In-Proc SxS is available in Managed COM Components. But is it also available in managed components, for example, ones which run in Managed Extensibility Framework? According to the article, "In-Proc SxS does not solve the compatibility problems faced by library developers". Does this mean In-Proc SxS can't be available in managed components?
Thanks.
At the runtime level In-Proc SxS is available for all managed components but only if they are loaded in a certain way. We updated our managed COM component activation pathway, as well as a few other places in the framework, to utilize In-Proc SxS.
The reason MEF components, and normal libraries, are not loaded automatically in the runtime they were built against is because loading a component in a different runtime than it's caller requires that the caller is capable of talking to the component through an isolation boundary and this usually not the case for these scenarios. COM components are automatically isolated anyways and so this isn't an issue. If MEF added support for composition across runtime boundaries then it could take advantage of In-Proc SxS more directly.
Does that help?
--Jesse
Thanks for your clear explanation! Now I understand the reason why managed components are automatically loaded with In-Proc SxS.
Sorry, I mistook. 'are automatically' -> 'are not automatically'.
Hi,
One of our main products uses an explorer integration as main UI. MS recommendations are to not use .NET for explorer integrations. I believe the reason is that you can never know what other addins a customer has. If the customer has an addin developed in 1.1 and our integration is in 2.0, then we'll have an in-process SxS issue.
Based on this we are stuck with native code using Win32/MFC/COM/etc.
However, from what I can tell from your post, this wont be an issue any longer?
Is this correct and 100% guaranteed if all our code is in .NET 4.0, or are there any pitfalls?
Thanks!
I've been struggling trying to get .NET 4 to co-exist with .NET 2 runtime. I've read all the blog posts and watched the channel 9 video and read the MSDN article. Rather than repeat the problems I'm having, I would really appreciate if one of the experts could chip in here:
http://social.msdn.microsoft.com/Forums/en/netfxappcompatprerelease/thread/a181e9b0-9d67-4d3c-80c4-11529196d3bc
Thank you very much!
Got my problem resolved. See the earlier link I posted for the resolution to my problem.