how to generate multi part assembly ( per folder) in visual studio for custom library project , C#?

Question

Is there a pre build action or some compiler switch that we can add?

I have just too many projects in our solution at the moment. I want to add new modules and compile them into separate assemblies.I am looking for options where I can avoid adding new projects for each assembly.

I am using Visual Studio 2005.

Also, It will be worthwhile to know if 2008 has better features over this space.

edit #1: There are two development teams working on this project and we want to cut the modules broadly into two verticals and keep the assemblies separate so that the ongoing patches ( post release ) do not overlap with the functionality in two verticals and also the testing footprint is minimized.

Currently the solution has about 8 projects and we need to setup the structure for the second team to start development.

I do not want to end up adding 5 or 6 new projects in the solution but rather create folders in the existing projects so separate code for the new team or some easy way.

Answer 1

No, Visual Studio is still "one project per assembly". Do you really need to have that many different assemblies?

You may be able to write your own build rules which create multiple assemblies from a single project, but I suspect it's going to lead to a world of pain where Visual Studio gets very confused.

If you could give us more details about why you want lots of assemblies, we may be able to help you come up with a different solution.

EDIT: Having read your updated question, it sounds like you would possibly be better off just working off two branches in source control, and merging into the trunk (and updating from the trunk) appropriately. Alternatively, if the two teams really are working on independent parts of the code, maybe separate projects really is the best solution.

One of the problems (IMO) with Visual Studio is that the files in the projects are listed explicitly - which means that the project files become big merge bottlenecks. I prefer the Eclipse model where any source file under a source path is implicitly included in the build (unless you explicitly exclude it).

Answer 2

Neither Visual Studio 2005 nor 2008 lets you create multi-file assemblies. However, you can run the C# compiler at the command line with the '/addmodule:ModuleName' switch and it'll do what you want. For general details on command line usage of csc see this article. For description of the /addmodule switch see this one.

That said, however, you're most-likely taking a non-optimal approach here. In normal situations you should not have to want to create multi-file assemblies just because you have too many projects. Give more details of your general problem so that people can offer suggestions regarding that.

Answer 3

I'd heed the advice you've been given thus far--if you find yourself asking such questions, there's probably a deeper design issue that's being overlooked--but if you really must do what you're suggesting be done, you have several options. You can hack the project file to allow you to compile files into separate assemblies: the project file is an msbuild file, so there's a lot you can do with it. Also, you can simply use an msbuild file for building your projects and solutions. Or you can use a different build system entirely--NAnt is one example.

The likely problem with these suggestions is that they won't be feasible for your work environment. It's no good to start hacking away at project files that other people on your team use, or to just decide that this or that solution is going to be built using your custom msbuild file. There are many good reasons to use something like a single custom msbuild file, or NAnt, to build your projects, but it's always the wrong decision if it's not made with input from everyone the decision affects.