views:

135

answers:

1

We have a situation where we will have two VSTO Outlook add-ins which both start off with some common shared code, but the shared code will probably diverge over time. Ideally, we'd like to restructure the add-ins to factor out the common code into a separate shared dll, but for non-technical reasons this is not an option right now. What problems do you anticipate if both the add-ins are deployed on the same outlook instance? Do you see problems cropping up because there would be two classes with the same name and same namespace, but with different definitions loaded by the two different add-ins on to the same outlook instance? Also one of the add-ins needs to call a form in the other add-in. Do you think this will be a problem with the differences in common code?

Assuming we manage to restructure the add-ins to separate out a dll with all the common code, will Outlook have a problem with different versions of the same dll being deployed by the two different add-ins?

+2  A: 

My current project had done similar code sharing between VSTO add-ins for Word. For now, we're using references to the other project with "copy local" at compile time but would like to switch that to reference the shared code out of the GAC so we are freed from the scenario of building the shared component requiring a rebuild of all projects that depend on it.

If all of your shared library dll's are "copy local" during build, you shouldn't have any name/namespace conflicts - but you will need to rebuild the add-in whenever your shared library code changes. If you want the builds to be handled separately, create an add-in that will serve as the library, that installs a copy of itself in the GAC so other add-ins can use it. I've included some links that show how to call code from other add-ins. In practice I've found it a little goofy because of VSTO being .Net on top of Office's native code.

References:

Mike Regan