views:

219

answers:

1

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!

+1  A: 

Instead of putting them in a project, you can put the files in a Solution Folder. One of your projects can have a build action that does the copying, but since they won't be in a project, they won't try to "build".

Reed Copsey
I originally thought of answering with this as well, but our team had to abandon solution folders because the upkeep was tremendous across multiple solution files. We ended up doing what the OP is doing and ignoring the generated .dll :/
womp
As "womp" suggested, I was hoping to keep the DLL stuff encapsulated entirely within their own project and not have to do maintenance somewhere else as well. I'm inclined to just ignore the junk DLL as well (it's only 3K after all). It just seems sort of "messy" this way. I'm doing this is for the SQL Server Compact Edition assemblies incidentally.
Scott Bussinger