Do not write in-process shell extensions in managed code

Property Handler Decisions and Preparation

The Great Flying Tortoise — Tue, 30 Jan 2007 09:47:37 GMT

Viewed as a data flow component, a property handler has a single file stream input and outputs a one

re: Do not write in-process shell extensions in managed code

Dean Harding — Fri, 22 Dec 2006 08:20:45 GMT

> Office components always run out-of-process when started through COM, so it's not an issue in that case.

Are you sure about that? I use both Lookout and Newgator in Outlook, both of which are .NET add-ins and both of which run in-process. Perhaps they don't use VSTO, though...

re: Do not write in-process shell extensions in managed code

AndyB — Thu, 21 Dec 2006 20:28:16 GMT

> To everyone else: don't mix .NET and native code, it's a terrible practice

I thought it just works.

> Native code rarely owns a whole process

Really? I wonder what all these exe's I've been writing for years are.

re: Do not write in-process shell extensions in managed code

KJK::Hyperion — Thu, 21 Dec 2006 15:02:27 GMT

Eric, Dean: Office components always run out-of-process when started through COM, so it's not an issue in that case

Daniel, Cooney: I'm always surprised at the lengths people will go to try and contradict Microsoft's design choices, often apparently for the heck of it. The "try to fix this Windows bug" challenge was especially eye-opening

To everyone else: don't mix .NET and native code, it's a terrible practice. Do it only if forced to do so, but don't incorporate it in an architecture developed from scratch

It's inefficient and terribly embarassing to the runtime, which never has the slightest idea how to handle native calls - will it corrupt the managed heap? will it close one of my internal handles? will it violate security policies? etc. Internal framework functions are not P/Invoke, for a good reason - their C++ implementations are so filled with static code checking annotations (pssst, .NET sources are public) as to virtually offer the same guarantees as managed code

Nevertheless, if you absolutely have to, make it so managed calls native and not the other way around. Native code rarely owns a whole process (notable exceptions are DBMSs, in fact .NET 2.0 was specifically tuned to be hosted by SQL Server) the way a runtime does, so despite the huge inefficiency it's not quite as dramatic as pulling the runtime in a random process

re: Do not write in-process shell extensions in managed code

Dean Harding — Thu, 21 Dec 2006 01:37:33 GMT

Eric: Office add-ins are a little different. The problem with explorer extensions is that your extension gets injected into every other process that tries to open a file-open dialog (or other things). Office add-ins are only run in the Office executable (well, usually - I'm not sure what happens with OLE in this case).

When you call a CCW (that is, a .NET object implementing a COM interface) from a native application, the infrastructure (by default) loads the most recent version of framework that's installed. So Office will typically be running .NET 2.0. This is not a problem for most .NET 1.1 add-ins, which will mostly run quite happily under .NET 2.0.

With explorer, it doesn't always work like that. If you have a process that has ALREADY loaded the 1.1 framework, then it tries to open a file-open dialog and load your .NET 2.0 extension... bang!

re: Do not write in-process shell extensions in managed code

Eric Smith — Wed, 20 Dec 2006 20:15:00 GMT

What about Office add-ins?

I'm having trouble reconciling the discussion here with the apparent encouragement to write managed add-ins for Office represented by the existence of VSTO. Doesn't the same problem exist there (although without the file dialog issue)? Is VSTO only practical in completely controlled environments where all add-ins are guaranteed to use the same CLR?

Sorry, I know this is straying off-topic for Raymond's expertise; you've got a knowledgable community here, though.

re: Do not write in-process shell extensions in managed code

Random Reader — Wed, 20 Dec 2006 11:26:19 GMT

Gabe,

>> The CLR will only know that your main assembly is asking for a class called "FtpRequest". Since this putative app is not directly referencing Foo.FtpRequest, the CLR will look for FtpRequest and its own version first.

That's what I'm saying is incorrect: if your app's assembly name is Foo (normally filenamed Foo.exe as well, but that isn't relevant), all references to FtpRequest will in fact be to FtpRequest _in assembly Foo_.

Explicit namespaces are necessary for organizational reasons, but not for type resolution.

This is the same concept as for native executables: the PE import table references a specific DLL, not just a symbol from anywhere at random.

re: Do not write in-process shell extensions in managed code

John Stewien — Wed, 20 Dec 2006 08:56:02 GMT

Gabe,

shouldn't people be using signed assemblies on released products, and thus not have this problem?

Also isn't the take home message of all this "Don't use managed code in shell extensions"? Managed code should just be used for fancy GUI stuff and web apps surely. Is C/C++ really that hard? It's all I used up until 5 years ago.

re: Do not write in-process shell extensions in managed code

Gabe — Wed, 20 Dec 2006 08:15:55 GMT

RandomReader, here's what I said "Of course you could just put the class in a namespace (like you should have done in the first place) and recompile, but your customers can't recompile."

The CLR will only know that your main assembly is asking for a class called "FtpRequest". Since this putative app is not directly referencing Foo.FtpRequest, the CLR will look for FtpRequest and its own version first.

Like I said, there are trivial steps to take ahead of time (strong names, namespaces, etc.). If you didn't do this when compiling your apps the first time, though, you're in trouble if your client only has the old version of the app and the new version of the CLR.

In the case of a shell extension, you don't get to choose which version of the CLR to load, the app or the first managed shell extension does. The only way to guarantee it working in this case is to send out a recompiled version using properly bound names.

re: Do not write in-process shell extensions in managed code

Random Reader — Wed, 20 Dec 2006 05:50:12 GMT

Gabe,

>> For example, let's say you have a CLR 1.1 shell extension Foo that does FTP, and is has a class called FtpRequest. When you run it on CLR 1.2 which implements its own FtpRequest class, Foo stops working because it gets the CLR's FtpRequest instead of your own.

The class name resolution rules, at minimum, also include a reference the containing assembly. The CLR knows FtpRequest in your assembly is not the same class as FtpRequest in any other assembly, so this situation cannot occur.

Michiel,

>> The root question is: why is the CLR linked against the managed executable using what is in effect a process-wide namespace? Because if multiple CLRs could co-exist, an extension needing CLR 1.0 would link against that CLR, and another could link against CLR 2.0. That doesn't sound hard: if an managed app wants symbols from CLR 1.0, in the compiler simply prefix every symbol with __CLR10__. If from 1.1, __CLR11__.

The CLR is not a library that is linked to an executable; it is a runtime. On newer versions of Windows, a flag in the managed .exe header instructs the OS loader to launch and initialize the CLR, which then loads and executes the managed code from the .exe. (On older versions of Windows, a native-code shim in the .exe's entry point launches the CLR instead.)

Because it is a full runtime, which manages detailed characteristics of the low-level process environment, it is not possible for it to play well with any other code that wishes to do the same thing. Consider the Garbage Collector, which needs to understand memory usage in the process, in order to correctly self-tune. Two such GCs would end up fighting each other, much as two processes that try to efficiently use all available RAM on a server would behave. (There's an old blog post somewhere about, IIRC, IIS and SQL Server that describes a similar case.)

Or for something more high-level, consider the WinForms part of the Framework. Naturally it requires a message loop for a managed thread, and there can be only one main message loop (broadcasts, non-window messages, etc). How are WinForms 1.x and 2.x supposed to both have a main message loop at the same time on the same thread?

So it's not just a simple symbol naming issue :)