DLL hell?

  • Thread starter Thread starter Julijan Sribar
  • Start date Start date
J

Julijan Sribar

I've made an application in VS2002 (actually an add-in for VS) which worked
on VS2002/2003. I am trying to port it to VS2005, but leave it backward
compatible.

I've managed to make it work on VS 2005 only if VS2002 or 2003 is installed
on the same machine. However, if a machine has only VS2005 installed, the
add-in does not work (it even fails to install on the client machine) as
long as I do not include referenced system assemblies (Extensibility.dll,
envdte.dll and stdole.dll) from the build machine into the installation
package. Need not to mention that those assemblies (but more recent
versions) exist on the client machine.

How can I avoid the need to include system assemblies into installation set,
i.e. allow .NET framework to select the appropriate versions? I suppose
these system assemblies should be backward compatible and the old code
should work with them.

If I build setup on VS2005 (with updated references) add-in works on VS2005,
but won't work on VS2002/2003.

Thanks in advance,

Julijan
 
Julijan Sribar said:
I've made an application in VS2002 (actually an add-in for VS) which
worked
on VS2002/2003. I am trying to port it to VS2005, but leave it backward
compatible.
Click to expand...

I would be prepared to set up build scripts for 1.x (VS 2002/2003).
I've managed to make it work on VS 2005 only if VS2002 or 2003 is
installed
on the same machine. However, if a machine has only VS2005 installed, the
add-in does not work (it even fails to install on the client machine) as
long as I do not include referenced system assemblies (Extensibility.dll,
envdte.dll and stdole.dll) from the build machine into the installation
package. Need not to mention that those assemblies (but more recent
versions) exist on the client machine.
Click to expand...

Not sure what causes this, unless you have not recompiled in VS 2005. Even
then, it seems a bit strange.
How can I avoid the need to include system assemblies into installation
set,
i.e. allow .NET framework to select the appropriate versions? I suppose
these system assemblies should be backward compatible and the old code
should work with them.
Click to expand...

I would imagine a proper compile in VS 2005 will solve this.
If I build setup on VS2005 (with updated references) add-in works on
VS2005,
but won't work on VS2002/2003.
Click to expand...

This is normal. You can either set up a 1.x batch script or MSBuild to build
for older versions of the Framework. VS 2005 builds for 2.0 and nothing
else.

If you want to maintain one code base, you will have to have multiple build
types, as you cannot run 2.0 add ins in VS 2002/2003. The code base can
still be the same, at least in most instances, but the build is separate.

The other option is to branch the code and maintain separate code bases.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
 
Back
Top