Search This Blog


Monday, October 6, 2008

Anti Pattern: Code Duplication in .Net

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:
and this:

 See any difference? No? See again.

Here is another set of picture:
and this:

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, whereas the second picture is a snapshot of the same class, but in the assembly Microsoft.Office.Interop.Word version The same goes for the third and the forth picture.

For your information, version is used on Office 2003 add-in projects, whereas version 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 and Microsoft.Office.Interop.Word version 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.


Anonymous said...

Are you suggesting that Microsoft should have continued using the old assembly, referenced from the new one?

I don't know of many shops that ship their entire old code base every time they create a new version, just to reuse code. Doesn't everyone just pop the source code across and rebuild?

Soon Hui said...

No, What I mean is that Microsoft should put the common code in a common assembly, not to package the common code inside every assembly.

Anonymous said...

If the code is already in the wild, how can you refactor it?