tags:

views:

43

answers:

5

I have two projects; A and B, where B needs to use some classes that are in project A. Hence, I added B to A's solution, and in B I added a reference to project A.

Is that sensible? Or should I rather put those classes in a class library?

I see that if I further want to open form/program B from a menu option in project A, then A needs a reference to B. Which would not be possible if B already had a reference to A. However if I use the class library for the common classes, then it's ok as B doesn't need the A reference.

Does this sound logical? It would be nice to know what are typical reasons for putting projects in the same solution, and if it's advised to use libraries aggressively to refactor common code between two projects, even if it's just a couple of classes.. Yet I've never made my own library, so a bit unsure on when to use it. If you have some principles would be nice to hear..

+3  A: 

Sounds like a perfect use case for a class library to me.

Put the common functionality in a third class library project and have A and B reference that.

Justin Niessner
A: 

In principal, circular dependencies are to be avoided so yes it would make sense to create a class library and add reference to that instead.

kzen
A: 

A class library would be a good solution for this, especially if you plan on having A ever reference B.

If you need A (or B) to actually implement some of the functionality of these classes, you may consider creating a class library with interfaces of your objects, so A and B can pass objects back and forth under interfaces they've implemented themselves.

Daniel Rasmussen
+1  A: 

If you plan to use the same classes in two projects, a shared library is the way to go. It's more than just convenience. Two identical classes with the same name, namespace and members are considered entirely different Types if they are defined in different assemblies (which includes EXEs.) Move common classes into class library C, and reference C in both A and B. A well known guiding principal is that of DRY: Don't Repeat Yourself.

-Oisin

x0n
"Different types", does this mean that even if two classes were identical in two separate projects, they could not be serialized/desirialized successfully across?
bretddog
@bretddog: correct. A types identity is comprised of its strong name (if assembly is signed), the assembly itself, the assembly version and finally the namespace+name of the class.
x0n
+1  A: 

Generally, classs libraries are used for common functionality between multiple projects. In other words, exactly what you're dealing with. So you should pull it out into a class library.

From there, there are two possibilities: if the common functoinality is always going to be the same between the two projects, then it should be a separate project. If it could change for one and not the other then copy it into both projects. You should still refactor it into a class library becasue that will make it easier initially. Note also that in the first case there is going to be another project to be maintained with its own release schedules and management headaches.

Generally, multiple projects in a single solution are a user interface and various libraries and other supporting projects. If there is more than one user interface they are usually realted to the same system, such as a user interface and an admin interface, or possibly interfaces for different platforms.

Jeff Hornby
I see.. Current situation is that one program needs to pass an object to the other program, either in runtime or by serializing to a file that can be loaded by the other. So it seems then this object class must be in a library of separate project/dll.. if I understand correctly.
bretddog