When should I add a project to my solution vs. adding the project's dll to my solution

Question

So right now I have project A and project B. Then there is a class library project Z. Project Z contains classes and methods both A and B use.

My question is, should I have project Z compiled and added to project A and B using its dll, or adding the project itself to both A and B?

Which cases would I use project in project in appose to dll in project?

Answer 1

If code from project Z is built and released on the same schedule as projects A and B, Z should probably be a part of the same solution.

On the other hand, if Z is a fairly stable library, with it's own release/maintenance schedule, you'll probably want to add it as a compiled reference.

You can ask yourself simple questions such as must Z to be compiled every time A and B are compiled? Should a developer working on A and B be able to modify Z?

Answer 2

In my experience, the biggest differentiation between doing one or the other is the amount of transparency you need within the specific project.

Obviously, if you have the potential to edit the project in any way, you would need direct access to the project. But on the other hand, if you are debugging an issue and you reach a project for which you only have the dll, your code vanishes into the black box of that dll and coughs out the result, disallowing you to step through it.

In the end, it is typically a preference thing. If you are confident enough that you won't need to get inside the black box of a dll while debugging or error hunting, and you would like a cleaner solution explorer, then by all means simply include it as a dll. This also allows for a faster compile time as it doesn't have to compile that particular project into a dll for debugging/release/etc. If you don't mind the extra clutter (and longer build times), or need that transparency, then I would suggest including it as a project.

As for my personal preference, I tend to not mind the longer build time and more cluttered solution explorer, and prefer adding projects instead of dlls when that is an option.

Answer 3

I would suggest branching Z with your version control system and add it as a project. That way you get the best of both. You get full debugging and you can edit the library and your A and B projects will not suffer if the Z interface is updated in other solutions.

If you make updates to Z, you can merge them with the other versions in a controlled manner.

Unless Z is extremely well documented you would definitely like to navigate in and out of the Z code while coding on A and B.

Only if Z is huge and take ages to recompile I prefer to include it as a DLL.

Answer 4

I think if Z is used both by A and B (assuming A and B are in different solutions), then you should add Z as dll. This way you will edit code in one place instead of two and you are sure that A and B are using the same version of Z library (again assumin you update dll in both ;))

Answer 5

I am far from an expert on this but my general rule of thumb is:

• If A and B are closely related and Z exists primarily to support them, let A and B both use a reference to the Z project.
• If A and B are not closely related, Z was created to support A, and then found to be useful to B, let A use a reference to the Z project while B uses a reference to the Z dll.
• If Z was created as a stand alone library intended for use by any and all projects that may find it useful, everything uses a reference to the Z dll.

My reasoning for this is to make sure that each project is tied to the correct version of the library.

What form of source control you are using could also be a factor. Depending on the overall situation and the capabilities of your system branching Z to both projects might be a good solution.