Create a Shell Extension Handler thumbnail extractor with .net?

Question

Hi,
My application creates nice graphics see http://www.mavericksplan.com/mavericks and it saves a custom document type.
I'd like to show the contet of the document in Explorer when the user switch to Thumbnail view.

To implement this feature I understand I need to create a Shell Extension Handler Thumbnail Extractor that extract the image from my file type to feed Explorer thumbnail vew, which is not easy at all for me.

I look on the web and I found 1 C++ example and none in C#.

Does anybody have a sample code to create a Shell Extension Handler thumbnail extractor with .net in C#?

Thank you
Andrea

Answer 1

Unfortunately unmanaged C++ is really the only way to go here.

Writing in-process \shell extensions in managed code is actually a very dangerous thing to do because it has the effect of injecting your managed code (and the .NET Framework) into every application on the machine that has a file open dialog.

The problems occur because only one version of the .NET Framework can be loaded in a process at any given time (other shared components such as java and msxml have the same property and thus the same restriction).

If you write your shell extension using the 2.0 .NET Framework and an application built with the 1.1 .NET Framework uses a file open dialog, your shell extension will fail because it can not run on an earlier version. Things can get even worse if your shell-extension manages to get loaded in a process before another applications managed code does: your extension may force an existing application onto a different runtime version than the one it was expecting and cause it to fail.

Because of these problems we strongly recomend against using any single-instance-per-process runtime or library (such as the .NET Framework, java, or msxml) in an in-process shell extension.

Answer 2

Thank you Jesse.
I will go with unmanaged code then. 

I'm positive I will not be able to create a bug free code at first, how bad is going to be for my Explorer and Windows? I mean can I break it having really hard time in restoring it or cleaning it?

Thanks again
Andrea

Answer 3

Do not believe to Jesse! It is possible to create Shell Extensions with managed code.
See this example:
<SDK v1.1>\Samples\Technologies\Interop\Applications\ShellCmd\

Answer 4

Thank you Andrey,
You are right! The sample is called "CLR Explorer Shell Extension Sample"

I'm going to look if I can figure how to define the Thumbnail view.

Andrea

Answer 5

Correct me if im wrong, but jesse is not saying it cant be done, he is saying that it is a dangerous thing to do.

Answer 6

Telestoon is correct here. It is certainly possible to create these shell extensions with .NET but it is extremely dangerous to do.

It's not that if you have a bug in the application you can cause instability problems in exporer.exe (though that is important as well). The real issue is that when you write shell extensions you actually inject your code  and your depenencies (such as a particular version of the .net framework) inside all processes on the machine that have an open file dialog box. If the application that does an open file uses a different version of the runtime than the one your extension was built against any number of bad things can happen.

Answer 7

I don't think it's that bad  a thing to do -- after all, Microsoft have released a shell extension to display thumbnails from digital camarea raw images; and it is written in .Net 1.1

Answer 8

Jesse,  assuming one did not need the shell extension to be loaded into non-Explorer processes, one could always write an unmanaged COM shim (as is commonly done for managed Office add-ins) that would check that the loading process is EXPLORER.EXE before loading the actual (managed) extension, right ?

 

Answer 9

That's still wrong. What happens when Explorer becomes written in managed code with a conflicting CLR version from your shell extension?

Answer 10

Thank you for your insight, Raymond.

I would like however to point out that the very same potential problem exists for managed Office add-ins. You didn't mention another one : that various managed extensions could conflict if each tried to load a specific version of the CLR. I believe these issues can be mostly avoided if each extension is modest in its requirements, i.e. :

• be compiled against the oldest CLR version possible
• if the CLR is already loaded in the process, use it
• if the CLR is not loaded, load the latest version available (the default behavior of the hosting API)

The CLR team's stellar work in backwards compatibility does the rest...

Cheers,
--Jonathan 

Answer 11

If the CLR is not loaded, you can still run into trouble if you load the latest version available, because the application might use the CLR on-demand (i.e., not load the CLR until you invoke a feature that requires it). That feature might have been written to an older version of the CLR, and loading the latest version would create a conflict. (I don't know if the CLR hosting APIs help here any, but you can't count on people using it - I bet most people haven't even heard of CLR hosting.)

Answer 12

I know this was asked ages ago, but if anyone is still interested check out http://www.mvps.org/emorcillo/en/code/shell/shellextensions.shtml

Answer 13

Extending that logic, wouldn't the same be true for any COM visible component written in .NET?

Answer 14

The key point is that you have to avoid injecting the CLR into processes that aren't expecting it. COM is just a conduit for the injection. Don't focus on the COM part; focus on the injection part. If all the processes that use your COM object are expecting the CLR (e.g. because you wrote them) then there's no problem since there is no injection.

Answer 15

So, if we can't run two versions of the CLR in a single process, is there any way to write an unmanaged proxy between the caller, and the extension. This could spawn a new process for each CLR version that differs from the caller and pass any calls between the two. Not sure I like the resource implications of this, but what we are saying is that if we run two sets of managed code compiled to different CLR vestions the we will always need two versions of the CLR running.

As an aside - I remember reading about Visual Studio for Applications (I think that was the name) a little while back which provided an infrastructure for a .Net plug-in model. It handled versioning issues of the hosting app and the plug-in, but can't remember if it handled different CLR versions (or if so, how it did it).

Answer 16

Andy,

Even if you were to do that successfully, you are only solving half of the problem.  Your extension might work OK, but your solution doesn't do anything about dependencies that have not yet been resolved (both from on-demand loading of the hosting application or from other extensions not yet loaded). 

To get this to work, all extensions (and the hosting application) would have to follow the same rules.  The result could likely be several instances of the app (say IE), one for each version of .NET installed.  Forget the performance issue here, what about the UX?

Robert W. Anderson

Answer 17

Some other people have brought this up, but I'm really curious now:  Given the hazards that have been described, should we avoid writing managed plug-ins for Office?  There is a whole toolkit for creating managed Office plugins.  Does it somehow mitigate this problem?  If not, why was it created?

Is this problem somehow less important with office, because we are talking about a single application vs. a system-wide issue with Explorer?  Seems like it would still be very important -- what if I have 2 critical office plug-ins, each targeting a different CLR version?  What if a version of Office loads a specific CLR version, then loads my plugin, which targets a different version of the CLR?

 

Answer 18

I've had this exact problem, and this was my experience:

Whichever add-in gets loaded first loads that specific CLR version.  If subsequent add-ins use a different version of the CLR, they're just not loaded.  Period.

This happened to me relatively recently.  I had a .NET 2.0 Excel add-in that had been working swimmingly for quite some time.  I installed a .NET 1.1 add-in, and the .NET 2.0 add-in just stopped working.  It took me a while to figure out what was going wrong.

In the end, I had to uninstall my .NET 1.1 add in.

One possible answer is to build two versions of your add-in (well, 3 if you're going to release a .NET 3 version) and let your users decide which they'd like to install.

Answer 19

Dan Ciruli wrote:

One possible answer is to build two versions of your add-in (well, 3 if you're going to release a .NET 3 version) and let your users decide which they'd like to install.

 

.NET 3 runs on the .NET 2 CLR...so I'm not sure that'd be an issue (good luck explaining that to your users though).

Answer 20

I forgot to ask...does this apply to IE addons as well?  I ask because the IE team says they are working on managed code examples:  http://blogs.msdn.com/petel/archive/2006/11/07/writing-ie-addons.aspx

 

Maybe they realised it was a bad idea and dropped it?

Answer 21

I am trying to start into shell extensions and would really like to use managed code for it.  I understand what you are saying here, but I am wondering if there is a way around this problem.  By writing a shell extension proxy in unmanaged c++ that makes calls to my managed code, can I get around this problem.  The way I see it, the COM server would then be the process that is loading the .NET framework for my managed code and not the process that is trying to use my shell extension.  Is this correct?

 

Sterling McClung

Answer 22

Dan Ciruli wrote:

One possible answer is to build two versions of your add-in (well, 3 if you're going to release a .NET 3 version) and let your users decide which they'd like to install.

But that still doesn't resolve the issue if there is ultimately a mix of add-ins based on different versions of the runtime. BTW, .Net 3.0 is really .Net 2.0 - same base runtime, just with added W[C|P]*F goodness.

Isn't there a way to shim the add-in to be a bit more sophisticated about loading/hosting decisions? Either dynamically or statically analyze the state of the machine configuration to determine which to load/run?

That or delay the load until absolutely needed, and then unload eagarly? In terms of a Shell Extension, the shim could do the shell-extension stuff (drawing menus, etc), and then when invoked load the runtime to accomplish the use case, unloading when the work ends? That way the process wouldn't have an silent injection scenario.

 

Answer 23

"In terms of a Shell Extension, the shim could do the shell-extension stuff (drawing menus, etc), and then when invoked load the runtime to accomplish the use case, unloading when the work ends?"

Whether the injection is silent or not isn't the issue; it's that injection is happening at all. While your extension is doing its work, another extension runs which requires a conflicting version of the CLR. Oops, that other extension fails to load. Now you get bugs like "Why can't I see thumbnails for my PDF files when I'm viewing the properties of a .TXT file?"

Answer 24

Raymond Chen - MSFT wrote:

Whether the injection is silent or not isn't the issue; it's that injection is happening at all. While your extension is doing its work, another extension runs which requires a conflicting version of the CLR. Oops, that other extension fails to load. Now you get bugs like "Why can't I see thumbnails for my PDF files when I'm viewing the properties of a .TXT file?"

It's true, but consider that the injection is well-defined. If there is no CLR in the process, then it is loaded and unloaded based on a specific user action, say viewing file properties. When this activity ends, the CLR is unloaded. While this doesn't eliminate the problem, it turns it into a usage problem rather than a machine configuration state problem, which is a more manageable affair. If you make a decision about which CLR version to load dynamically (detect if the CLR is already loaded, then use that one), then you reduce the whole problem to, essentially, a race condition. If there was some kind of way to detect CLR loading failure (winning the race and picking an incompatable runtime), your add-in could unload the CLR, load the needed version, and reload the failed add-in. Lots of work, sure, but possible (assuming there exists such detection facility).

Also, the other point I had made was doing analysis of machine configuration. Is there no way to determine which possible processes on a machine require which version of the runtime, and load the runtime based on that analysis?

Grateful for your insights,

-r

Answer 25

The problem is already a race condition. Suppose you have two thumbnail extractors, each written in different versions of the CLR. The user opens a folder, the shell kicks off a few background threads to do thumbnail extraction, and now you have two extensions running simultaneously, with conflicting requirements. "When I go to a folder with both PDFs and SVGs, it seems about a third of the thumbnails randomly fail to appear."

Answer 26

Raymond Chen - MSFT wrote:

The problem is already a race condition. Suppose you have two thumbnail extractors, each written in different versions of the CLR. The user opens a folder, the shell kicks off a few background threads to do thumbnail extraction, and now you have two extensions running simultaneously, with conflicting requirements. "When I go to a folder with both PDFs and SVGs, it seems about a third of the thumbnails randomly fail to appear."

Yes, we are walking the same path here - it is a race condition. My observation is that race conditions are first of all much easier to handle than incompatibility between add-ins, since, secondly, there is recourse. Race conditions are observable at runtime. Wouldn't such detection also entail a compensating action of unloading the current and loading an appropriate version of the CLR, and reloading the offended add-in, causing the following scenario: "When I go to a folder with both PDFs and SVGs, it seems that about a third of the thumbnails don't appear at first, but then after about a second they show up." To which the response would be "Ah, yes, it seems that there are two shell extensions using the CLR, and the one loaded secondly fails at first, but this is detected by the first one which changes the CLR loaded into the process and reloads the formerly failing add-in."

Answer 27

How does the first shell extension know that a second conflicting shell extension has been loaded and that the first extension should therefore abandon its work in progress, unload the CLR, then somehow compute what version of the CLR would work better for both extensions, load that version, then restart the original operation? No wait, I don't want to know. It's all moot because the conflict might come from the hosting process. E.g., while the first shell extension is still doing its work, the host decide it's time to load the CLR (say the user activated a feature written in managed code) and it can't because the shell extension loaded a conflicting version. Result: "Sometimes when I try to do convolutions, I get a strange error about the wrong version of .NET. Sometimes if I wait a few minutes and try again, it works." I think your technique requires too much in the way of psychic powers on the part of the shell extension.

Answer 28

It looks like Microsoft is releasing .NET extensions (or am I missing something here?)  The new Photo Info viewer requires .NET 2.0:

http://www.microsoft.com/windowsxp/using/digitalphotography/prophoto/photoinfo.mspx

Answer 29

Michael Letterle wrote:

I forgot to ask...does this apply to IE addons as well?

IE hosts the runtime itself, it is already inproc there, and managed code doesn't have to make decisions about whether the process can have the CLR injected, and what version, etc., so it would be safe in those terms.

The issue isn't whether IE or even Explorer can or can't handle the runtime, it's 1) does the hosting process decide, and in deciding, make the requirements for add-ins clear, and 2) will the add-in spill out all over to other processes which load shell add-ins via loading shell-provided functionality like messageboxes. In the case of Explorer in 1 and normal COM shell extensions in 2, the answers are no and yes respectively, which are the wrong answers for being able to write .Net add-ins. IE hosts, therefore it decides. In the case of CLR IE add-ins it will probably also mean strictly managed add-ins, not registered like normal shell extensions, and not going through COM-interop.

-r

Answer 30

It appears the Photo Info extension uses a non-CLR DLL for the shell extension work and then spawns a separate process which is the .NET stuff.

It would be great to see the Windows Shell team build a managed API or build a shim that we can interface with in some fashion.  Back in the hay day of Vista/Longhorn the talk was that Win32 APIs were going to start going away in favour of Managed APIs.  It seems that like WinFS, this too has gone away with the wind.

Answer 31

I really do not get it. After all the noise about how great .NET and the managed world is, it turns out one cannot and must not develop anything more than a standalone executable with it. What happened to the claim the DLL hell was over?

Not being able to have multiple CLR versions in a single process is a terrible design if you ask me. If it was you started Visual Basic like this, your company history would have looked differently. At Microsoft you've lost your minds! And I feel pity I have spent my life developing applications for your platform.

Answer 32

Just as I got resigned to shelve my beloved VC++6 and start using C#, I discover this horror!  How could the richest corp in the IT world let this happen?

 

Should we get back to our reliable UNmanaged C++?

 

 

Answer 33

This same issue would apply to writing managed ActiveX controls, intended for general use, written in a managed language, wouldn't it?

---

Steve

Answer 34

Back in december 2006 Mr McClung asked if it would be possible to work around this problem by writing the shell extension in unmanaged code and then call the managed code from it.

I could not find a clear answer for this, although I suspect that as long as we are running in the same process the answer would be no.

However the problem I'm facing is that I would like to generate thumbnails for files of a specific graphics format (owned by the company I work for). The rendering engine for this format is written in .Net (C# and J#/Java) porting it is not in the scope and would not be doable so from what I understand from these discussions I'm screwed. Unless I come up with a way to load the engine (and thus the CLR) in another process.

The easies way would be to simply write the extension in C++, make a unmanaged/managed C++ bridge and then call into the managed C#/J# assembly. Any thoughts on how to make the managed part run in another process?

I'm thinking COM server (stand alone), started on demand and terminated after use. Another way would to write a service and register it for on demand start, but then it would run until you halt it (could be done from the shell extension) or windows shuts down.

Any thoughts/ideas on this?

Answer 35

Guys,
i have 2 words for you...... Marshal.FinalReleaseComObject(this);

or what ever com object you would like to release......
Managed .NET code is still hooked to windows core modules such as ntdll.dll which have released there threads already....
the  FinalReleaseComObject will raise an unmanaged exception that can be ignored, but will also release your com object, thus, avoiding the crash of the explorer.
The crash of the explorer is actually the crash of your com object, but since it is running within the explorer process it messes-up the explorer's heap by messing up it's own....

This is the exception i am overcoming by the Marshal.FinalRealeaseComObject method...
Faulting application explorer.exe, version 6.0.6001.18164, time stamp 0x4907e242, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a7a6, exception code 0xc0000374, fault offset 0x000b015d, process id 0x154c, application start time 0x01c9d8e1668fa160.

Make a long story short..... drop everything before you exit the IContextMenu.InvokeCommand method.


yaniv

Answer 36

How about a slightly off the thread suggestion:

In your custom file format, keep an easily extracted thumbnail that is in a common image format (embed a jpg or png). JPG and TIFF at least have well-defined thumbnail specs. Most digital camera raw formats include thumbnails. Then you have a small and simple C++ shell extension that reads the thumbnail from your file format. No need to access the whole rendering engine, or even to read the entire file. Doing this makes the user experience using Windows with your shell extension tolerable because you're simply retrieving a few bytes from the file, instead of parsing the whole file format to render the image.

I expect that you're in this pickle because the developers of this custom format did not anticipate a need for thumbnails/previews.

Answer 37

> to create these shell extensions with .NET but it is extremely dangerous to do.

don't you think it's the bug of .net. you all are paid to fix it.

 - blll gates, your patient, our passion.

Answer 38

Johan, I think if the person is working for a company which owns a particular graphics format, it might be contradictory to propose to embed another gfx format... which is why they perhaps are/have created a new format no?

Potentially a weird solution if you go... hey , we have created a .dnt solution (just an example obviously), but hey, we can't use code to create a natural thumbview out of it, we need to use a 'rival' or standard format, embed it in ours, just to make a thumbnail preview :/

Answer 39

Very interesting discussion...

now where do I find the information to create a Shell Extension Handler?

Thanks

Answer 40

Very interesting discussion...

now where do I find the information to create a Shell Extension Handler?

Thanks

 

http://msdn.microsoft.com/en-us/magazine/cc188741.aspx

 

[ Editor's Update - 6/23/2006: Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario.]

Ok only to say, that now is possible in .Net 4.0 to run side by side:

 

http://msmvps.com/blogs/peterritchie/archive/2008/11/12/net-4-0-evolving-net-development.aspx

 

[2010 .Net 4.0] Another notable improvement is side-by-side (SxS) support for multiple versions of .NET. This allows hosting of more than one version of the CLR within a single process. This makes writing shell extensions, for example, in C# a reality in .NET 4.0. You shouldn't need to target .NET 4.0, but as long as .NET 4.0 is installed you should be able to write shell extensions in a current version of .NET (like .NET 2.0) and it will be supported. Prior to .NET 4.0, a process could only have one version of the CLR loaded into a process, making extending 3rd party native applications (like the Windows shell) very problematic because what version of the CLR that was loaded into a process would depend on the first extension loaded. If the first extension loaded was a .NET 1.1 assembly then any other extensions loaded requiring .NET 2.0 would subsequently fail.

Answer 41

I know this is off topic for this forum, but since it was suggested above does anyone have a good link for guiding one through writing an UNmanaged Shell Extension handler to create thumbnails?

Thanks.

-Noel

Answer 42

Ragnar, I believe you may have missed the point of the in-process side by side execution feature (please forgive me if I am mistaken). According to http://msdn.microsoft.com/en-us/library/ee518876.aspx , this feature is specific to the .NET Framwork 4.0, meaning that v4.0 itself can run side by side with one older version of the runtime (but not both), at least as far as COM interop is concerned. It also specifically states that in-process side by side execution is not available between v1.1 and v2.0, since those runtimes do not inherently support such a feature (I'm sure v1.0 is implied in all that as well). So the compatibility issues Jesse refers to will still remain if, say, you have two shell extensions written against v1.1 and v2.0, respectively, regardless of whether or not there is a third extension that was using the v4.0 runtime.

Bottom line is that I would take Jesse's word for it, and just not do it, period. It wouldn't be the first time that different groups in Microsoft released conflicting information that another group closer to the feature had to either discourage or outright refute. Regardless of what Microsoft reps say, the argument against doing it makes sense to me: A native executable cannot implicitly bind to exports from two different versions of the same DLL without having problems (or failing to execute at all), so I wouldn't expect the .NET COM interop layer to behave any differently.

Answer 43

Fixed ShellExView x64 to require to run as admin under Windows 7/Vista, like the 32-bit version.

Version 1.47
date: 18/05/2010

ShellExView can be used for solving context-menu problems in Explorer environment                     

Answer 44

From Jesse's article on MSDN:
"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."
This restriction seems well documented here as well as other forums and web-sites.

Is there a specific example of failure that I can show to skeptics on my team? I built a 2.0 shell-context-menu and a 3.5 shell-context-menu each which just shows a MessageBox when the menu is selected. I built both with VS2008 and they both load and run fine on my XP SP3 system.

I need an actual failing example to help me make my case no matter how contrived that example may be.

 

Answer 45

 

Is there a specific example of failure that I can show to skeptics on my team? I built a 2.0 shell-context-menu and a 3.5 shell-context-menu each which just shows a MessageBox when the menu is selected. I built both with VS2008 and they both load and run fine on my XP SP3 system.

I need an actual failing example to help me make my case no matter how contrived that example may be.

2.0 and 3.5 are running on the same CLR version (2.0). You need to create a shell extension with .NET 1.1 if you want it to fail.

Answer 46

Also, I think I should add that there is added danger if people start writing managed shell extensions. If explorer tries to load two extensions made with a different .net framework (You make yours in .net 4, and 5 years later, you download one made in .net 6), either one of the extensions won't work, or explorer might fail and all applications that use a dialog box (Which would be VERY bad).

Answer 47

Everything depend onversion of .net

Answer 48

Also, I think I should add that there is added danger if people start writing managed shell extensions. If explorer tries to load two extensions made with a different .net framework (You make yours in .net 4, and 5 years later, you download one made in .net 6), either one of the extensions won't work, or explorer might fail and all applications that use a dialog box (Which would be VERY bad).

Actually if you made yours in .NET 4 it won't be a problem at all. Starting with 4 you can have multiple instances of the CLR loaded at the same time. Read this MSDN magazine article (it actually contains a link to this thread in the article itself), if you are .NET 4 or above you are good to go on compatibility with other  .NET versions when writing COM extensions.

Here is a compatibility chart from the article showing what can load with what

Which version will my component run against?
Component Version	1.1	2.0->3.5	4.0	5.0
Machine/Process State
1.1, 3.5, 4.0, 5.0 installed None loaded	3.5	3.5	4.0	5.0
1.1, 3.5, 4.0, 5.0 installed 1.1, 4.0 loaded	1.1	Fails to load*	4.0	5.0
1.1, 3.5, 4.0, 5.0 installed 3.5, 5.0 loaded	3.5	3.5	4.0	5.0
1.1, 3.5, 5.0 installed None loaded	3.5	3.5	Fails to load by default**	5.0
*These components would fail to load in the past as well **When you register components you can now specify a range of versions that they support and so you could configure this component to run against 5.0 or future runtimes if you have tested them.

Answer 49

Unfortunately unmanaged C++ is really the only way to go here.

Writing in-process \shell extensions in managed code is actually a very dangerous thing to do because it has the effect of injecting your managed code (and the .NET Framework) into every application on the machine that has a file open dialog.

...

Because of these problems we strongly recomend against using any single-instance-per-process runtime or library (such as the .NET Framework, java, or msxml) in an in-process shell extension.

Even if these technologies wouldn't have version conflicts, there's another very good reason not to do this lurking here: the CLR and the JVM have high per-process overhead, so loading them into every application with so much as an "Open" dialog (or, for IE extensions, every process that embeds IE to show some HTML) is really quite wasteful of time and memory.