I really liked Microsoft .Net framework for its elegance, ease of use and the way different components are layered. Although .Net is huge, complicated, but finding what I need and the using the framework is very, very easy. In order to learn some software design principles, I often use the Reflector to study how Microsoft developers structure their libraries, arrange the hierarchies between different objects and make different classes talk to one another with minimum coupling and high cohesion.
But somehow, the Visual Studio Tools for Office libraries are not as well structured as other components. And you got to be careful with them if you want to write cross version add-ins ( such as if you want to write add-ins that run in both Word 2003 and Word 2007).
Let's take a look at these two screenshots:
Here is another set of picture:
Again, notice any difference?
The first and the second picture looks the same, right? Yes, they do, except that they were taken from different assemblies. Look at the version number carefully, the first picture is a snapshot of Microsoft.Office.Interop.Word._Application class, in the assembly Microsoft.Office.Interop.Word version 220.127.116.11, whereas the second picture is a snapshot of the same class, but in the assembly Microsoft.Office.Interop.Word version 18.104.22.168. The same goes for the third and the forth picture.
For your information, version 22.214.171.124 is used on Office 2003 add-in projects, whereas version 126.96.36.199 is used on Office 2007 add-in projects.
Now, you can see that there are code overlapping in different assemblies! Instead of putting common interfaces, methods and classes in a common assembly, Microsoft chose to lump them together with other version specific libraries.
This is an anti-pattern because I can't put my cross-version code in a common assembly because I can't just make reference to Microsoft.Office.Interop.Word version 188.8.131.52 and Microsoft.Office.Interop.Word version 184.108.40.206 at the same time, for the VS 2008 will detect them as duplicate and drop one of them.
In the hands of the unskilled, one might just duplicate the same functionalities for different versions of add-in, thus create a maintenance nightmare.
The only way to solve this problem is to put the common functionalities in a separate cs file, and add it to the Office 2003 and Office 2007 project by using the "Add as Link" option. But this is not really a desirable option. Out of respect for the intellectual property, I might want to protect my code before distributing it to other developers. But the design of VSTO components simply won't allow me if I want to protect my cross-version libraries.
Microsoft should have been more careful when they first designed the VSTO classes. Now they are carrying this design legacy and give millions of developers the trouble. What a costly mistake.