We're all sharing the same process--let's play nice

This is kind of like the story where the mother tells her kids “While I’m gone, don't climb up onto the countertop, open the cupboard door, take the beans off the top shelf, and stuff the beans up your nose." I’m going to tell you something bad you can do and then hope you believe me that you shouldn’t do it J

So whether you are building an add-in or a VSTO 1.0 code behind the document project, one rule stands true—we’re all sharing the same process—winword.exe or excel.exe or someotherofficeapp.exe—so let’s play nice.

Office programming of add-ins and code behind documents consists of loading an assembly into the Office application host process. It differs from standard WinForms programming in that you don’t have your own process. You should try to have your own AppDomain (see this article) but you won’t have your own process. You are sharing it with other add-ins and code behind written by other developers.

Some things in the CLR are set at a process level and not an AppDomain level. One obvious example is the version of the .NET runtime that loads into the process. You can only load one version of the .NET runtime into a given process. At some point you will be tempted to create a “winword.exe.config” file with the purpose of locking your add-in or document customization to a particular version of the runtime. If you don’t know what I’m talking about, look at this article: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfRequiredRuntime.asp.

Now, you might do this on a dev machine with only your code loading into Office with some safety, but don’t do this on an end-user machine. Doing so is the equivalent of stuffing beans up your nose. Here’s why.

Imagine you use this feature to lock winword.exe.config to the 1.1 version of the runtime. You now deploy a winword.exe.config to the desktops where your add-in or code behind is installed. Now those desktops at some future date open a document or install an add-in that requires the 2.0 version of the runtime. Because you’ve locked winword.exe to load the 1.1 version of the runtime, the add-ins or documents that require the 2.0 version of the runtime will break.

The rule to follow should be always let winword.exe or excel.exe load the latest version of the runtime installed on the user’s machine. Don’t lock it down to a particular version. The CLR makes as close to a guarantee as possible that if your application runs on 1.1, it will run on later versions of the CLR too. The main area where exceptions are made to this rule is if there is a security issue in 1.1 that requires an API change.

On the other hand, there is a definite guarantee that if some developer in the future writes an add-in that uses a 2.0 runtime feature and a user tries to install it on a machine where winword.exe has been locked to 1.1, that add-in is going to fail miserably. We’re all sharing the same process—let’s play nice.