By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,184 Members | 1,276 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,184 IT Pros & Developers. It's quick & easy.

Are Cyclic dependencies allowed in file references?

P: n/a
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project 1-solution A
accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project cannot be
copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of
the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might trick it
into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this
dll.

My main question is... Is there anything wrong with the cyclic relationship
as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.
Jul 21 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
It turns out that the "dll hell" threads did the trick! I was setting my
references via the bin directory and not the object directory which was
resulting in a gigantic spider net of dependencies that was near impossible
to comprehend After changing to the object directory and knowing I was only
getting the one dependency from that setting, I was able to have cyclic
dependencies per the restrictions I listed below.

Brian
"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project 1-solution A
accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project cannot be
copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of
the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might trick it
into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this
dll.

My main question is... Is there anything wrong with the cyclic relationship as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.

Jul 21 '05 #2

P: n/a
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces
and Patterns to isolate the code so that you don't have circular references.

The last idea is probably the most useful: Pick one of your libraries to be
the "base" library. Create an Interface. Have the "base" class use objects
of the interface type to perform it's actions. In the "dependent" class,
create your new object to inherit from the interface. Then your base class
doesn't need to compile with a reference to the outside class... it simply
calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I
have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project 1-solution A
accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project cannot be
copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of
the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might trick it
into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this
dll.

My main question is... Is there anything wrong with the cyclic relationship as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.

Jul 21 '05 #3

P: n/a
Thanks for the guidance.

In retrospec, I can see how I can apply refactoring to eliminate the
redundancy. I've been reluctant to do so since, the structure I have is
logical and it would sacrifice production for structure.

What guidelines can you share with me as to how to package class libraries
into projects and projects into solutions?

I currently have over 50 solutions primarily due to team development.
Microsoft recommends 1 solution but it appears that the few attempts I 've
made to package many projects results in slow load times for my developers.

I have a several solutions for various libary/mail/data layering routines,
then I have solutions for each business process. ie Separate solutions for
Order Processing, Accounts Receivable, Accounts Payable, Payroll, General
Ledger etc. One issue I have been struggling with is that both Accounts
Payable and Payroll use a "Check" object. I have written two separate check
objects because I am converting a legacy system but now can see that one
check object would be much better. Does this check object reside in a new
project by itself? Does the new project reside in a standalone solution?
.... or should I not use business processes for any of the groupings?

If you would, please walk me through the recommended ways of grouping class
libraries into projects and further grouping projects into solutions. I
think I am very close but have some remaining doubts.

Thanks again for your input!
Brian

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:eIH0d.174549$mD.72519@attbi_s02...
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces and Patterns to isolate the code so that you don't have circular references.
The last idea is probably the most useful: Pick one of your libraries to be the "base" library. Create an Interface. Have the "base" class use objects of the interface type to perform it's actions. In the "dependent" class,
create your new object to inherit from the interface. Then your base class doesn't need to compile with a reference to the outside class... it simply
calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I
have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project 1-solution A accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project cannot be copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might trick it into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this dll.

My main question is... Is there anything wrong with the cyclic

relationship
as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.


Jul 21 '05 #4

P: n/a
In a multiple solution environment, can/should class libraries reside in
mulitple projects? I've been allowing them to only reside in one project
and then having to reference them via projects. Maybe this is where I'm
going wrong.

Brian

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:eIH0d.174549$mD.72519@attbi_s02...
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces and Patterns to isolate the code so that you don't have circular references.
The last idea is probably the most useful: Pick one of your libraries to be the "base" library. Create an Interface. Have the "base" class use objects of the interface type to perform it's actions. In the "dependent" class,
create your new object to inherit from the interface. Then your base class doesn't need to compile with a reference to the outside class... it simply
calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I
have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project 1-solution A accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project cannot be copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might trick it into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this dll.

My main question is... Is there anything wrong with the cyclic

relationship
as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.


Jul 21 '05 #5

P: n/a
Please disregard the above thread.... I forgot the add class would just make
a "copy" of the class.vb.

Brian

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
In a multiple solution environment, can/should class libraries reside in
mulitple projects? I've been allowing them to only reside in one project
and then having to reference them via projects. Maybe this is where I'm
going wrong.

Brian

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:eIH0d.174549$mD.72519@attbi_s02...
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces
and Patterns to isolate the code so that you don't have circular

references.

The last idea is probably the most useful: Pick one of your libraries to be
the "base" library. Create an Interface. Have the "base" class use objects
of the interface type to perform it's actions. In the "dependent" class, create your new object to inherit from the interface. Then your base

class
doesn't need to compile with a reference to the outside class... it simply calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project

1-solution A accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project
cannot
be copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might
trick
it into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this dll.

My main question is... Is there anything wrong with the cyclic

relationship
as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.



Jul 21 '05 #6

P: n/a
Actually, you can add a "link" to a class, which doesn't copy the class. I
don't recommend this features, but it is there.
To use it, in Visual Studio:
In project explorer, select Add Existing Item
In the dialog, select the item, but instead of clicking the "Open" button
(I don't have VS in front of me... whatever the default button is called...)
there is a little drop-arrow right next to the button... click it. You
will see alternate commands you can use. Select "Link This Item"

The class won't be copied... it will be linked.

Once again, I do NOT recommend this command, but I wanted to make sure you
knew it was there.

--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:OK**************@TK2MSFTNGP11.phx.gbl...
Please disregard the above thread.... I forgot the add class would just make a "copy" of the class.vb.

Brian

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
In a multiple solution environment, can/should class libraries reside in
mulitple projects? I've been allowing them to only reside in one project
and then having to reference them via projects. Maybe this is where I'm
going wrong.

Brian

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:eIH0d.174549$mD.72519@attbi_s02...
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces
and Patterns to isolate the code so that you don't have circular

references.

The last idea is probably the most useful: Pick one of your libraries to
be
the "base" library. Create an Interface. Have the "base" class use

objects
of the interface type to perform it's actions. In the "dependent"

class, create your new object to inherit from the interface. Then your base

class
doesn't need to compile with a reference to the outside class... it simply calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I
have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
> I'm not sure if I've broken any Object Oriented rules or not, but

.... >
> I have projects in 2 different solutions that need to use each other's > methods. Therefore I may have an "update" method in project

1-solution
A
> accessing a "save" method in project 2-solution B as well as "getinfo" > method in project 2 accessing a "read" method in project A.
>
> Is this permitted? I am getting the "dependency file in project

cannot
be
> copied... conflict " message when building. The problem is that I am > getting it on the very project I am building! (So I can't directly
> reference it) Everything was working fine until someone went into one of
> the reference projects and probably updated one of my referenced

dll's >
> I have recently switched to manual versioning thinking this might

trick
it
> into building but it seems like I have one mysterious dll with an old > version that is preventing my success. I have not been able to find

this
> dll.
>
> My main question is... Is there anything wrong with the cyclic
relationship
> as long as it does not involve the same two methods from each project? >
> Sorry for this confusing thread.... I hope you can understand what I'm > asking.
>
> TIA,
> Brian
>
> ps. I have read the threads on dll hell and will try some of those
> suggestions asap.
>
>



Jul 21 '05 #7

P: n/a
Hi Brian,

I'm an Architect, so I usually do things visually. I would create a
"component view" diagram (I have some background in RUP) that illustrates
the dependencies between "components" (where a component is a logical
grouping of classes that defines a particular functionality or hides a
particular area of complexity). These are static dependencies: in other
words, Item A is dependent on Item B if some code within Item A refers
specifically to a class, type, or method defined in Item B.

A good article from Scott Ambler is here:
http://www.agilemodeling.com/artifac...entDiagram.htm
(In fact, I strongly recommend this entire site.)

If you have a diagram like this, you will see some things. If your design
is solid, you will see "natural clusters" of components that tend to align
with either (a) functional groupings within your systems, or (b) the
organizational structure of your company. (The latter is unfortunate, but
is typical of teams that collaborate by copying code, rather than creating
common designs). (Note: if you do not see natural clusters of components,
you have created a design according to the antipattern "Big Ball of Mud,"
and will need to seriously embark upon some efforts to identify natural
clusters and break the unnecessary links that bind them).

Now that you can see your natural groupings, take a totally different
ingredient, and add it to the mix: add the Layers pattern (described by
Buschmann, further described by Microsoft's Patterns and Practices group).
This pattern has you break out "libraries" where a library is a collection
of components that can be identified on a GRID. (Your description makes it
clear that you have considered the functionality of your system in terms of
vertical slices. I would also encourage you to define horizontal slices as
well, to make a coherent grid).

One of the natural requirements of this grid: dependencies may only travel
in one direction (usually up, depending on how you draw your diagram). In
other words, an item may depend only on the items that are defined in layers
below it... never beside it, and never above it.

When you apply your naturally occuring clusters of components to this grid,
you will see that some of the classes that you thought should align together
in a single library should not. That in fact, some of the classes belong in
an upper layer, while others, due to their nature, belong in a lower layer.
This is especially true if those lower layer capabilities are reused (or you
would like for them to be reused) by other upper layer classes. This
activity forces you to consider ways to reduce your coupling. My earlier
response, about coding to interfaces, is one of the refactoring techniques
that accomplishes this goal.

So, how does this horizontal slicing work?

In my diagrams, the lowest slice are the classes that hide the complexities
of accessing a system function, external package, or network protocol. This
includes database access, connection to the active directory, reading and
writing queues (MSMQ, et. al.), file access, config file access, sending
e-mail, connecting to a WebDAV directory, etc. Another, completely
independent set of low level classes is a set of Base classes and
Interfaces. These define the objects that the rest of my system will use to
communicate and organize information.

The next layer up depends on both of these packages, and is involved with
using the low level services to create and manipulate objects that meet the
base class definitions. This is the layer where some folks use tools, but I
have yet to find a tool that creates these classes in a way that makes much
sense to me. These are the objects that hold the data that will move
through the services. This is the "model" layer often described in the
Model-View-Controller pattern.

The next layer up is the "controller" layer. (See descriptions of the
Model-View-Controller pattern). This layer contains classes that
encapsulate the business functionality. (e.g. in your financial system, you
are probably doing double-entry accounting. These classes are aware of how
to balance your entries before committing them, to insure that total credits
equals total debits).

The next layer up is an "interface services layer" that groups the
controllers and some visible data objects as services. This layer
encapsulates and hides the vast majority of the classes below it, and
reduces complexity to a series of messages. If you want to pay a bill, you
send a message described as "object A" to "Service B" and the system will
take care of finding the bill, cutting the check, and balancing the books.

The next layer up is the User Interface service layer. In a rich client
app, this layer is nearly always coded in the same executable as the client
windows themselves. In a web app, this layer is nearly always coded as
code-behinds under the web pages. This layer takes the data from the user
interface and composes the messages required by the interface services
layer. It takes the responses and fills user interface controls or makes
the data visible. This aligns with the classic definition of the "view"
classes in the MVC pattern.

The topmost layer are the windows or web pages themselves. This is nearly
always thin "visual" work that creates the layout of controls on a form or
window, manages tab order, responds to short-cuts, handles resizing of the
window, etc. I spend as little time in this layer as I can, because I'm not
gifted in this area, and others clearly are.

As you can see, this is considerably more detailed than is typical of older
descriptions of Model-View-Controller, but is both consistent with it, while
still allowing for newer Service Oriented patterns to interact with the
systems architecture.

With a layering design like this one, you can define packages that will
minimize the effort of your team both during compilation and during
maintenance. Your system sounds complex, which tells me that it is an
Enterprise class system. By defining packages in this manner, you can
isolate areas of likely business rule changes, and keep your system usable
while reducing code (and therefore, reducing bugs). It should also be much
easier to create automated unit tests for the system because the functions
of a layer do not depend on the layer above, and the layer below can be
modeled with mock objects. (Google on NUnit and NMock).

Now that you have a package design, you can create solutions that make
sense. I would create assemblies (projects) that align with the component
libraries that emerge from the above process. I would define solutions to
include the necessary projects to make a single developer or small team
effective. Note that a project can occur in multiple solutions (although I
would minimize this). I've seen enterprise class systems with only five or
six solutions, and perhaps 40 or so projects. I would avoid having a
solution that makes the source code available for more than two layers at a
time... that's just a rule of thumb to help me to stay focussed on reducing
coupling and increasing cohesion.

I have not normally seen solutions that contain only one project. That is
not unheard of, but it is somewhat rare, and usually done when there are
issues with deployment that drive this (An event handler in Sharepoint, for
example, is normally signed and placed into the GAC... the difficulty of
deploying multiple dependent libraries into the GAC often yeilds a single
large assembly. As a result, the solution file will contain only the single
assembly and perhaps some resources and an installer).

I hope this helps to answer your questions.

--- Nick Malik
"Brian Sabolik" <bs******@excitez.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Thanks for the guidance.

In retrospec, I can see how I can apply refactoring to eliminate the
redundancy. I've been reluctant to do so since, the structure I have is
logical and it would sacrifice production for structure.

What guidelines can you share with me as to how to package class libraries
into projects and projects into solutions?

I currently have over 50 solutions primarily due to team development.
Microsoft recommends 1 solution but it appears that the few attempts I 've
made to package many projects results in slow load times for my developers.
I have a several solutions for various libary/mail/data layering routines,
then I have solutions for each business process. ie Separate solutions for Order Processing, Accounts Receivable, Accounts Payable, Payroll, General
Ledger etc. One issue I have been struggling with is that both Accounts
Payable and Payroll use a "Check" object. I have written two separate check objects because I am converting a legacy system but now can see that one
check object would be much better. Does this check object reside in a new
project by itself? Does the new project reside in a standalone solution?
... or should I not use business processes for any of the groupings?

If you would, please walk me through the recommended ways of grouping class libraries into projects and further grouping projects into solutions. I
think I am very close but have some remaining doubts.

Thanks again for your input!
Brian

"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:eIH0d.174549$mD.72519@attbi_s02...
yes, there is something wrong with it. Stop doing that.

Refactor your libraries. Either move the capabilities of one class to
another, or move one class out of one library to another, or use Interfaces
and Patterns to isolate the code so that you don't have circular

references.

The last idea is probably the most useful: Pick one of your libraries to be
the "base" library. Create an Interface. Have the "base" class use objects
of the interface type to perform it's actions. In the "dependent" class, create your new object to inherit from the interface. Then your base

class
doesn't need to compile with a reference to the outside class... it simply calls any class that implements the Interface.

This is a little bit of refactoring, but it should work.

Sorry this is so vague... I don't know what your objects actually do, so I have to speak in generalities.

Good luck.
--- Nick

"Brian Sabolik" <bs******@excitez.com> wrote in message
news:eu**************@TK2MSFTNGP14.phx.gbl...
I'm not sure if I've broken any Object Oriented rules or not, but ...

I have projects in 2 different solutions that need to use each other's
methods. Therefore I may have an "update" method in project

1-solution A accessing a "save" method in project 2-solution B as well as "getinfo"
method in project 2 accessing a "read" method in project A.

Is this permitted? I am getting the "dependency file in project
cannot
be copied... conflict " message when building. The problem is that I am
getting it on the very project I am building! (So I can't directly
reference it) Everything was working fine until someone went into one of the reference projects and probably updated one of my referenced dll's

I have recently switched to manual versioning thinking this might
trick
it into building but it seems like I have one mysterious dll with an old
version that is preventing my success. I have not been able to find this dll.

My main question is... Is there anything wrong with the cyclic

relationship
as long as it does not involve the same two methods from each project?

Sorry for this confusing thread.... I hope you can understand what I'm
asking.

TIA,
Brian

ps. I have read the threads on dll hell and will try some of those
suggestions asap.



Jul 21 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.