views:

60

answers:

3

Hello,

My application has at least 2 projects, the OrganizationMangement and the ContactManagement. Previously, I referenced ContactManagement because I need to work with a class located in the OrganizationManagement. Now I need to do the reverse but I'm getting the following error "Cannot reference OrganizationManagement ... to avoid circular reference."

I guess the error makes sense. But, how can I avoid that? I mean I need those classes just to transfert data from one project to another.

To solve the problem, I copied the class to a folder located in the other project and tried this

var contact = (Contact)TempData["contact"];

Now, I'm getting this error: Cannot convert implicitly ContactManagement.Contact to OrganizationManagement.Contact... an explicit conversion exists...

Thanks for helping

+3  A: 

It may not be as bad as you think - a project can always refer to its own classes without needing an explicit reference.

However, when this kind of structural problem crops up, it's usually telling you there's a flaw in the overall design.

I'd guess that there's an implicit third project that you haven't defined yet, that your Organization and Contact projects will each need a reference to. Once you've moved the class in question into the new project, create a reference to it in each of your existing ones, and you'll be all set.

Of course, this may necessitate other structural changes - sorting out this kind of problem can turn out to be a real can of worms.

Bottom line: circular references usually indicate that there's a bit more thought needed to work out what the dependencies in your object model really are.

ChrisA
@Chris: It looks like circular referency is a huge problem. All I wanted was just to transfert time to time data when needed. Now I'll have to go through my code.
Richard77
+1  A: 

Maybe you should refactor all the common domain-related classes to their own new project that can then be referenced by the other projects.

On the other hand I could suggest a very bad workaround for the error you encounter by defining an explicit conversion between the structurally identical classes that only differ in name. But please don't do so. Put all the domain stuff (i.e. entitiy-related classes like Contact, Person, Organization, Customer etc.) to its own project and reference this from the projects that need the classes.

Andreas
@Andreas: Well, I was just about to write a method that does the explicit conversion. Why shouldn't I do an explicit conversion but rather transfert common classes in a new project??? Is there any technical or design justification to that???
Richard77
It is rather a design decision you should take. What you actally did was code duplication, wasn't it? And that leads into its own special problems. Imagine what happened if you change one of the domain classes, e.g. add a new attribute.Is there a special reason why you hesitate refactoring the domain classes into their own (class library - well, it is intended for exactly what i would achieve) project?
Andreas
@Andreas: I'm not hesitating to do what you're suggesting. (in fact, I like your answer, especially the above comment). I just wanted to get more information. Do you agree that it's better to get the whole story before acting?
Richard77
@Richard77: Sure, I agree :-) I just wanted to get to know if there are goot reasons to do it the let's say strange or maybe even ugly way.
Andreas
+1  A: 

Compile both projects and copy the assemblies to a folder "libs". Dont reference the projects but the compiled assemblies.

This works for me. I have 1 project Shop with a Backend ShopBackend. Then I have a project MarketPlace with a a backend MarketPlaceBackend. Both main projects have not a lot in common. Markeplace is a very small application.

The ShopBackend has a class Order that accesses the ShopDatabase. In MarketPlace I use the Assembly ShopBackend to get a list of orders.

On the other hand in Shop I need a list of the participants of MarketPlace. Thats why I call the MarketPlace assembly there.

Yes this design hurts sometimes: It is hard to get the versions right if the signature of methods changed. But in my case applications are realy separate and they have separate databases.

What I want to say: a circular reference can easily be a design issue, but it doesnt have to be. Imagine that both applications came from different companies. I gues it would be ok if Microsoft.dll uses some methods off google.dll and google.dll uses methods of microsoft.dll.

Malcolm Frexner