The problem is both projects can't access one another. There is a compile order you can see (click the "Debug"/"Release" dropdown and select options at the bottom, its in there). It first compiles project A, then project B. But if it cannot compile Project A until Project B has been compiled, and Project B cannot be compiled until Project A has been compiled... you have circular dependencies.
All of the code that is common between the two assemblies must be moved to a third assembly, and your two existing projects can reference that assembly.
Also -- Be sure that when you add a reference for a project in the same solution that you click "Add Reference..." and at the top you will see tabs, click the "Projects" tab and add a reference to the project by name, not to the C:\location\of\the\dll.
ohk..i got it.
i will implement what you said. Infact , that would make my project easier to handle.
But, then wouldnt it affect the namespaces i have already structured?
Or just refactoring the namespaces and changing the default namespace in the projects would work out?
Also then my structure would be as follows :
namespace NetworkTracker
{
// types common to both the other assemblies (or projects).
// i would create this in a project named NetworkTrackerCommon.
namespace Tracker
{
// client-side code
// i will include this namespace in client-side assembly : Tracker
}
namespace UserInterface
{
// server-side code
// i would include this namespace in server-side assembly : UserInterface
}
}
What should i keep the default namespaces in each of the assemblies ?
I think it should be :
NetworkTracker in NetworkTrackerCommon assembly
NetworkTracker.Tracker in Tracker assembly
NetworkTracker.UserInterface assembly
I would also refactor the names in their respective assemblies.
Am i right? Or i should keep the root namespace NetworkTracker as the default namespace in all of the projects ? ( i didnt seem this feasible).
Offline 
Marked 
