2 out of 2 rated this helpful - Rate this topic

The Shell and Managed Code

Shell extensions should not include managed code. Shell extensions are loaded into all processes that use the Shell namespace and run in-process by definition. Managed code built against one version of the common language runtime might not run in a process running a different version of the common language runtime. At this time, only one version of the common language runtime can be loaded into a process at one time. Therefore, Microsoft recommends against writing managed Shell extensions and does not consider them a supported scenario.

For instance, if you wrote a managed Shell extension, then every application on the computer that has a file Open dialog box would have that managed code and its attendant common language runtime dependency injected into the application's process. The application or extension that is first to load its required version of the Microsoft .NET Framework into that process restricts the process to using that particular version of Framework. If a managed application with an Open dialog box is built on an older version of the Framework than your Shell extension requires, then your extension could fail to run correctly and could cause errors in the application. Conversely, if your Shell extension is the first to load in a process and managed code tries to launch after that (perhaps a managed application or a running application loads the common language runtime on demand), the later code has to use the version of the Framework that was loaded by the Shell extension, whether compatible or not, again leading to the possibility of an application failure.

Developers will be tempted to devise schemes to mitigate the issue, including Component Object Model (COM) wrappers for managed objects, but in the end, each, no matter how convoluted or careful, comes back to the potential for a version conflict in an in-process object. Therefore, we strongly recommend against using any single-instance-per-process runtime or library (such as the Framework, Microsoft XML (MSXML), or Java) in a Shell extension. If you are developing a Shell extension, do so with unmanaged code.

 

 

Send comments about this topic to Microsoft

Build date: 3/7/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
correction to the previous poster
"We still do not support writing shell extensions using any version earlier than .NET Framework 4 because those versions of the runtime do not load in-process with one another and will cause failures in many cases." (quoting from http://msdn.microsoft.com/en-us/magazine/ee819091.aspx)

This means that you CAN write managed shell extensions AS LONG AS they target .NET 4 or later. SxS does let you do this.
.NET v4 does not mitigate the excuse for not using managed code

Where it does seem that .NET v4 and the side by side execution of different .NET versions can mitigate this, it is still a problematic situation because it doesn't solve all problems faced with mixing runtime versions in the same process. What's more, the second article explicitly states that shell extensions are still not supported. This link which was given in the article explains the problem and why it isn't supported. http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/

CLR v4.0 In-Process side by side execution eliminate the excuse for not using managed code.
After the launch of CLR v4.0 whose one of the most significative changes is the introduction of In-Process side by side execution, more than one version of CLR can be loaded simultaneously by a process. It eliminates any remaining excuse for not writing Shell Extensions using Managed Code.
Details about this new feature can be found at .NET Framework 4.0 In-Process Side-by-Side Execution feature documentation (http://msdn.microsoft.com/en-us/library/ee518876.aspx). In addition, the article CLR Inside Out: In-Process Side-by-Side (http://msdn.microsoft.com/en-us/magazine/ee819091.aspx) provide more information about this new features and its implications.

Carlos Loth (http://carlosloth.wordpress.com/)