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
This means that you CAN write managed shell extensions AS LONG AS they target .NET 4 or later. SxS does let you do this.
- 9/18/2011
- Joao M Correia
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/
- 9/29/2010
- crescens2k
- 9/29/2010
- crescens2k
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/)
- 5/15/2010
- Carlos Alberto Loth
- 5/15/2010
- Carlos Alberto Loth