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?

[Nicholas Paldino [.NET/C# MVP]]

_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?

[Bruce Wood]

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.

[_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>

[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

[Lasse Vågsæther Karlsen]

_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

[multiparadigm]

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.