views:

39

answers:

3

Hello,

My Visual Studio solution has several late-bound projects (dll) which are loaded by other projects in runtime. The dll loaded depends on some runtime condition.

To load dll in runtime I need it to be present in the application bin directory, and there are several of those apps. To do that I run a post-build script which copies late-bound dll to every application that may need it. I'd like to get rid of the script because it creates a heavy xcopy post-build process which is not really necessary.

What do you use in this case?

I can also add a reference to dll from every application, however in this case I will create a type reference and I (or other developer) may accidentaly reference a type from late-bound dll which may not be present on client's server.

A: 

Change the build output of all the late-bound projects to build directly in the project where you want them to be late bound. So instead of building them to their own /bin/debug/, build them to ../MyMainApp/bin/Debug/.

Sly
Thanks, Sly. The build output is already redirected. The problem is that dll needs to be copied to several folders as the solution contains several independent applications. I'm also thinking about a shared parent folder for all late-bound dlls.
aloneguid
We have a similar situation here, to solve that, we build all projects to the same directory (c:\OurProductName). So that folder contains all the DLLs and all the Apps (EXEs) that we have.
Sly
+1  A: 

You don't have to make it a reference assembly to get it copied into the client project. Project + Add Existing Item, select the DLL. Set its Build Action to "None", Copy to Output to "Copy if newer".

Hans Passant
nobugz: It's only automatic if there are references to those DLL in the client project. He wrote he'd rather not add references (see his last comment).
Sly
Thanks, updated my answer.
Hans Passant
That's a very interesting solution, thanks!
aloneguid
+1  A: 

I've dealt with this problem before as well, it's quite frustrating. The approach I take now is to remove the directory dependency; externalize the location of these late-bound libraries (in the config file), then keep them in a shared location, which you set the build output of the libraries to.

When it comes to deployment, you change that setting, and package the libraries with your installer.

This is especially useful when developing/debugging several independent applications as you only need to keep track of a single copy of the libraries.

If that's not an option for you - perhaps it's too difficult to externalize or perhaps there are major variances in the dependencies from one app to the next - then I would go with nobugz's answer.

Aaronaught