Question

I’m using Visual Studio 2008 and would like to create a sort of container project that holds a number of DLL’s that must be installed with a solution. I want them to be in a separate project so that they can be easily attached to a solution as a group.

I created an empty project call TEST, added my DLL’s to it with a Build Action of “Content”, and set them to “Copy Always”. That all works exactly as I want. The problem is that if I set the TEST project Output Type to “Console Application” or “Windows Application” that it won’t build because there’s no entry point. If I set the Output Type to “Class Library”, it builds but I end up with an extra TEST.DLL file that I don’t really want.

Is there anyway to sort of set the Output Type to “none”? I want the build actions to take place (so my DLL’s get copied) but I don’t want the dummy class assembly created. Any ideas?

Thanks!

Answer 1

Assumptions for the following step-by-step guide:

Let’s assume that you have a solution with two projects:

• Main: your main (start-up) project.
• BundledDLLs: a library project which contains the .dlls that should end up in the main project’s output directory.

Step-by-step guide:

The easiest way to achieve your goal inside Visual Studio is probably the following:

1. Add all .dlls to BundledDLLs and set their Copy to output directory to Copy if newer.

   This is done in the Project Explorer and the Properties windows.

2. Configure BundledDLLs‘s output directory to be identical to Main‘s output directory.

   This can be done in the Build tab of BundledDLL‘s Project Properties page. Enter something like the following in the Output Path textbox:

   ..\Main\bin\Debug
   

3. Set up BundledDLLs as a dependency of Main.

   Do not add BundledDLLs as a project reference to Main, as you usually might; instead, use the Project Dependencies dialog to . This will tell the build tool that whenever Main is built, BundledDLLs needs to be built first.

   Do this by right-clicking on the Main project node to open the context menu; select Project dependencies… from there. In the now opened dialog, first select Main from the drop-down list; then check BundledDLLs in the project list below. BundledDLLs is now registered as a dependency of Main.

   P.S.: One disadvantage of not having an explicit assembly reference in Main is that some tooling might not recognise the dependency. For example, ClickOnce deployment might not work properly.

4. Add a post-build event to BundledDLLs that deletes the superfluous BundledDLLs.dll.

   As you said, you don’t want, and don’t need, the dummy output generated when BundledDLLs is built. So add a post-build event that simply deletes this .dll once it’s been created.

   Open the Build events tab in BundledDLLs‘s Project Properties page, and enter something like the following in the post-build textbox:

   DEL "$(TargetDir)\$(TargetName).*"
   

   (In case you wondered: The reason why you didn’t add this project as a project reference to Main earlier is because if you had done so, Main would be looking for BundledDLLs.dll, which it wouldn’t be able to find since you don’t actually want such a file to be generated.)

   P.S.: One disadvantage of adding such a post-build step is that it might interfere with incremental builds. If your project keeps getting recompiled from scratch after this, you might be better off removing the post-build step and living with the extra BundledDLLs.dll in your solution’s output directory.