Shell extensions in managed code - a workaround?

[Ympostor]

Hello. I have been researching a bit about creating shell extensions in
managed code (I want to show some overlay icons on files to the user).
This is a good guide to do it, right?:

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


And yes, I've read all of the information about the typical problems
when doing this in managed code:

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/


However, now I'm wondering, can I avoid this versioning problems just
stating that my program is only compatible with a Windows OS that has
just one version of the .NET framework installed? Could I create an
installer that detects this?

Thanks very much in advance.

 

[Stanimir Stoyanov \(C# MVP\)]

As you already know, the versioning problem exists because a given
application can only have one version of the .NET Framework loaded at the
same time. Even if there is only one .NET Framework version installed at the
time your shell extension is being deployed, there is no reason why the
system administrator won't have to install the next Framework version
sometime soon. It might as well be automatically updated via Windows Update.

However, yes, most (if not all) installers allow you to perform registry
checks before proceeding. A list of the currently installed version is kept
in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework and each version has
its own sub-key starting with "v" (e.g. v2.0.50215, v2.0.50727, v3.0, etc).

You should consider executing this project in C++ if possible. Is there a
particular reason you want to do this with .NET, which justifies the risk of
incompatibility and possibly frustrated users?

 

[Ympostor]

As you already know, the versioning problem exists because a given
application can only have one version of the .NET Framework loaded at
the same time. Even if there is only one .NET Framework version
installed at the time your shell extension is being deployed, there is
no reason why the system administrator won't have to install the next
Framework version sometime soon. It might as well be automatically
updated via Windows Update.

My application will also include a system-tray service that will execute
always on the background, so I even could check from time to time if a
new version of .NET has been installed, and inform the user about the
incompatibility.

However, yes, most (if not all) installers allow you to perform registry
checks before proceeding. A list of the currently installed version is
kept in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework and each
version has its own sub-key starting with "v" (e.g. v2.0.50215,
v2.0.50727, v3.0, etc).

You should consider executing this project in C++ if possible. Is there
a particular reason you want to do this with .NET, which justifies the
risk of incompatibility and possibly frustrated users?

Yes, the reason is portability. I'm thinking about developing a .NET
library that will abstract the OS particularities of shell extensions,
and provide an easy way to include overlay icons and context menu
options regardless of the platform. This way the shell extensions will
be in a single codebase and we will not have the need of having to sync
every feature we do in C# with the C++ special one.

Thanks for your answer!

 

[Stanimir Stoyanov \(C# MVP\)]

I see, thanks for giving a little background on the project.

My application will also include a system-tray service that will execute
always on the background, so I even could check from time to time if a
new version of .NET has been installed, and inform the user about the
incompatibility.

This is a good idea and not something I had thought of. To take this a
little further, if needed, the Windows service could trigger a disable
feature so that Explorer will not load the extension library the next time
Windows starts, avoiding a possible conflict. Otherwise, it is possible that
users will not even be able to access Control Panel and folders in general,
through Explorer.

 

[Ympostor]

I see, thanks for giving a little background on the project.


This is a good idea and not something I had thought of. To take this a
little further, if needed, the Windows service could trigger a disable
feature so that Explorer will not load the extension library the next
time Windows starts, avoiding a possible conflict. Otherwise, it is
possible that users will not even be able to access Control Panel and
folders in general, through Explorer.

Yeah, I thought about this.

However, what if the application cannot deploy a system-tray service?

In this case, I'm thinking about this solution, please tell me if it's
technically possible:

- Have a shell extension written in C++ (in order to avoid the
versioning issue) that, firstly detects if there are more than one
runtime version installed on the system.
- If yes, it then disables the .NET shell extension feature.
- If not, it lets the .NET shell extension run.

What I mean is, can C++ shell extensions call .NET shell extensions?

Thanks.

 

[Andreas Johansson]

- Have a shell extension written in C++ (in order to avoid the

versioning issue) that, firstly detects if there are more than one
runtime version installed on the system.
- If yes, it then disables the .NET shell extension feature.
- If not, it lets the .NET shell extension run.

This seems to be a better idea than having a service/notify icon polling for
new .NET versions. The user may have disabled the service/notify icon and it
would not be able to warn the user of the possible conflict. To have a check
just before the conflict may arise is the best approach.

Consider if your app is useful on a terminal server machine. What if that
machine has hundreds or thousands of users. Even if your polling
service/notify icon takes little memory and uses little CPU time, when
multiplied with 100 or 1000 concurrent users on one server it will be
significant and will have impact on the terminal servers performance.

What I mean is, can C++ shell extensions call .NET shell extensions?

You can use the .NET assembly from C++ via COM interop, this is what you
need anyway to make a shell extension. When you expose a .NET assembly as
COM, this will cause the .NET CLR to be loaded into the process when used,
avoiding conflicts.

/Andreas