tags:

views:

67

answers:

1

I'm developing an SSIS component and am trying to come up with a way of maintaining a single source code base while building targets for both the 2005 and 2008 versions.

I have a two part problem:

  • My project's references for v2005 version point use different .NET DLL's than v2008 (ie, different versions of the same DLLs).
  • A class I use in v2005 will have a slightly different name in v2008 (even though it has the same functionality and public interface).

Problem 1 I can deal with, I don't mind having a project for each target version with different references. Problem 2 is not so easy. To illustrate, the v2005 custom property collection is called IDTSCustomPropertyCollection90, whereas the v2008 collection is called IDTSCustomPropertyCollection100.

If I try to use the v2005 DLL in SSIS 2008, the -90 class will not be found, and the same goes for the -100 class if I try to us a v2008 DLL in SSIS 2005. How I work with that class is exactly the same for both my v2005 and v2008 builds, with the exception of that 90/100.

If I were coding in C++, I'd set up a .h file where I'd set up a series of #defines to square this away:

#if defined(VS2005BUILD)
  #define IDTSCustomPropertyCollection IDTSCustomPropertyCollection90
#else
  #define IDTSCustomPropertyCollection IDTSCustomPropertyCollection100
#endif

But this doesn't seem to be possible in C#. Ideas?

+1  A: 

you could try using another Interface between those and your code, and then load the appropriate one from config or something.

ScaleOvenStove
I considered writing pairs of wrapper classes (there are several with this problem) and then using the set that is appropriate for that build. But there's a lot of classes with this problem and I was hoping for an easier solution.
Marc Bernier