471,337 Members | 907 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,337 software developers and data experts.

Circular dependency flagged at compile time

_DS
I have two projects that currently need to refer to each other. More
precisely:

Proj A:
Class 1 refers to Proj B Class 1

Proj B:
Class 1
Class 2 refers to Proj A Class 1

Visual studio, for good reason, doesn't like that.

Obviously I could split Proj B into two separate projects. There are
no crossrefs between the two classes in Proj B, but the classes do
really belong together.

I've read about application of Interfaces to break the full circle but
I don't see any elegant way of applying that in this case.

Or I can kludge it and remove Proj B from Proj A's solution, then
replace 'Project' references with hard refs to DLLs. That would seem
to compromise build integrity (and would have to be changed for
release build).

Any alternatives?

Jan 13 '06 #1
6 1430
_DS,

I would say a bit of refactoring is due here. I would combine the class
from Proj A with Proj B. They can still have separate namespaces. Either
that, or create project C, which Project A and B both reference.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"_DS" <_D*@noemail.com> wrote in message
news:4s********************************@4ax.com...
I have two projects that currently need to refer to each other. More
precisely:

Proj A:
Class 1 refers to Proj B Class 1

Proj B:
Class 1
Class 2 refers to Proj A Class 1

Visual studio, for good reason, doesn't like that.

Obviously I could split Proj B into two separate projects. There are
no crossrefs between the two classes in Proj B, but the classes do
really belong together.

I've read about application of Interfaces to break the full circle but
I don't see any elegant way of applying that in this case.

Or I can kludge it and remove Proj B from Proj A's solution, then
replace 'Project' references with hard refs to DLLs. That would seem
to compromise build integrity (and would have to be changed for
release build).

Any alternatives?

Jan 13 '06 #2
Could you give them more descriptive names than A and B? If I knew a
little more about the domain in which you're working, and what the
classes / assemblies do, I could probably indicate how to solve your
problem using interfaces.

Jan 13 '06 #3
_DS
On 13 Jan 2006 12:40:47 -0800, "Bruce Wood" <br*******@canada.com>
wrote:
Could you give them more descriptive names than A and B? If I knew a
little more about the domain in which you're working, and what the
classes / assemblies do, I could probably indicate how to solve your
problem using interfaces.


To rephrase:

I have two projects that currently need to refer to each other. More
precisely:

Proj A 'ComplexDataType':
ComplexDataTypeCollection - Contains TypeX from proj B Class

Proj B: 'TypeXProcessor':
TypeXFormatConverter
TypeXWriter - Gets data from collection in Proj A

Proj A simply defines a complex data type and collections of that data
type. The data type includes a component of 'TypeX' so the
ComponentBuilder relies on the converter class in Proj B.

Proj B deals only with TypeX (a specific string format). It has a
class for converting to TypeX format, and a class for writing it to a
(specifically formatted) file.

As the ComplexDataType collection is built, it refers to
TypeXFormatConverter to create one of its fields. That's not the
problem. The problem arises because the ProjB's TypeX-derived file
writer needs to take the ComplexDataTypeCollection as an argument.

So Proj A needs to refer to the converter in Proj B.

Proj B needs the data type from Proj A.

The collection in Project A is used for lots of purposes, but happens
to encompass a TypeX field, among other things.

The functions in Project B all relate only to TypeX, so I'd like to
keep them together in one lib.

Aren't you sorry you asked? <g>

Jan 14 '06 #4
SP

"_DS" <_D*@noemail.com> wrote in message
news:cl********************************@4ax.com...
On 13 Jan 2006 12:40:47 -0800, "Bruce Wood" <br*******@canada.com>
wrote:
Could you give them more descriptive names than A and B? If I knew a
little more about the domain in which you're working, and what the
classes / assemblies do, I could probably indicate how to solve your
problem using interfaces.


To rephrase:

I have two projects that currently need to refer to each other. More
precisely:

Proj A 'ComplexDataType':
ComplexDataTypeCollection - Contains TypeX from proj B Class

Proj B: 'TypeXProcessor':
TypeXFormatConverter
TypeXWriter - Gets data from collection in Proj A

Proj A simply defines a complex data type and collections of that data
type. The data type includes a component of 'TypeX' so the
ComponentBuilder relies on the converter class in Proj B.

Proj B deals only with TypeX (a specific string format). It has a
class for converting to TypeX format, and a class for writing it to a
(specifically formatted) file.

As the ComplexDataType collection is built, it refers to
TypeXFormatConverter to create one of its fields. That's not the
problem. The problem arises because the ProjB's TypeX-derived file
writer needs to take the ComplexDataTypeCollection as an argument.

So Proj A needs to refer to the converter in Proj B.

Proj B needs the data type from Proj A.

The collection in Project A is used for lots of purposes, but happens
to encompass a TypeX field, among other things.

The functions in Project B all relate only to TypeX, so I'd like to
keep them together in one lib.


Pass a list (array / array list...) of TypeX to ProjectB from the
ComplexDataTypeCollection. You have already stated that "ProjectB deals only
with TypeX" so there is no need for it to know anything about
ComplexDataTypeCollection so all you want is a simple list of TypeX's to
allow ProjectB to do it's stuff on the TypeX's.

SP
Jan 14 '06 #5
_DS wrote:
I have two projects that currently need to refer to each other. More
precisely: <snip> Any alternatives?


You could always combine them into a single project/assembly...

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2
Jan 14 '06 #6
I have two projects that currently need to refer to each other. More
precisely:

Proj A:
Class 1 refers to Proj B Class 1

Proj B:
Class 1
Class 2 refers to Proj A Class 1

Visual studio, for good reason, doesn't like that.

Obviously I could split Proj B into two separate projects. There are
no crossrefs between the two classes in Proj B, but the classes do
really belong together.

I've read about application of Interfaces to break the full circle but
I don't see any elegant way of applying that in this case.

Or I can kludge it and remove Proj B from Proj A's solution, then
replace 'Project' references with hard refs to DLLs. That would seem
to compromise build integrity (and would have to be changed for
release build).

Any alternatives?
The problem is not the mutual reference -- it's the VS project system.
An easy fix is to NOT add the refererences as PROJECT references.
Add them simply as files (using the Browse tab in the Add Reference dialog box).
You will lose the automatic dependency checking between the projects (the depended-upon project won't be automatically rebuilt). But it's a very minor inconvenience to solve an nasty problem.
I have tried this and it works.
May 10 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Evelyne | last post: by
reply views Thread by David Sandor | last post: by
1 post views Thread by Henry Miller | last post: by
6 posts views Thread by Markus Dehmann | last post: by
2 posts views Thread by ernesto basc?n pantoja | last post: by
4 posts views Thread by Henke | last post: by
2 posts views Thread by Mike | last post: by
7 posts views Thread by barias | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.