1

We have the following situation/requirements:

  • We have multiple projects which use the same DLLs (which we developed).
  • Different projects shall be able to use different versions of those DLLs
  • The applications within one project shall all use the same version
  • It shall be possible to update the DLLs of a single project so all applications in that project are affected. Other projects shall not be affected.
  • Each application shall have their own directory

This leads to the following desired folder structure:

SomePath
  |- SomeProject
  |     |- DLL
  |     |- Application1
  |     \- Application2
  |
  \- OtherProject
       |- DLL
       \- ...

In order to allow different projects to use different versions, registering them in the GAC is not possible (is it?). Using the probing private path solution is not possible either, as that approach only supports subdirectories, not parent folders.

As I understand it, the Assembly.LoadFrom could work but would mean replacing each new call of types in those libraries by reflection calls (or not?), which would mean a lot of work.

Is there a way to reference the DLLs as specified without having to use reflections? I.e. specify a relative include path to a parent folder.

Hint: Development machine is Windows 8.1, VS 2013; Target machine is Windows 8.1

Community
  • 1
  • 1
Tim Meyer
  • 12,210
  • 8
  • 64
  • 97
  • Nope. That's not the way it works. – Sam Axe Feb 18 '15 at 11:05
  • Every programmer makes this mistake at least once, usually several times. Learning to respect the DLL Hell Beast cannot be taught, it has to be experienced. So go ahead and point that gun at your foot. You will not get any help from the CLR, you have to pull the trigger yourself. Implement the AppDomain.AssemblyResolve event. – Hans Passant Feb 18 '15 at 13:29
  • AssemblyResolve will still require me to use reflections, won't it? After all, the libraries are currently loaded before Main() is executed. – Tim Meyer Feb 18 '15 at 14:14

1 Answers1

0

Answering my own question after further research:

It looks like the only options in this case are:

  1. Deploy the shared DLLs into every application directory or
  2. Convince system engineers that there is no need to put every application into its own directory. If all applications are in the same directory, the shared DLLs can be placed in that very directory or any subdirectory. If application configuration data shall be separated, this can still be done in further subfolders.

We went for way #2.

Tim Meyer
  • 12,210
  • 8
  • 64
  • 97