Dependency problems

[mandelbrot]

Dear All,

 

 

I am presently modularising various sections of a project, turning them into compiled libraries on a central server. I then add these as references to other libraries.

 

Some of the libraries I have written access other libraries which access other libraries... (Hope I'm not loosing you). My problem lies in the fact that I have one particular library that utilitses two other libraries both of which require the same (fourth) library, causing a structure like the image enclosed below.

 

The only way I can get this to work properly is by setting the Copy Local property for the reference to false, preventing the offending classes from being copied locally; but wont this lock the DLL, preventing it from being replaced if necessary at a later date if the DLL is in use?

 

 

Paul.

[Diesel]

My problem lies in the fact that I have one particular library that utilitses two other libraries both of which require the same (fourth) library,

 

Add a reference for the 'fourth library' to the 'one particular library'. This reference 'should' take precedence over the other 2.

[mandelbrot]

Diesel,

 

 

I don't see how this will benefit.

   [a]   1st library
  /   \
[b]     [c]  2nd/3rd libraries
  \   /
   [d]   4th library

Linking [a] directly to [d] would surely not resolve for and [c]... and [c] still need to reference [d], but [a] doesn't. Am I missing something?

 

 

Paul.

[Nerseus]

Are all of these in the same solution? If not, I don't see the problem as you just have to build each one, one at a time (as long as you close solution A before loading B or C).

 

If they're in the same solution I'd set each project as a Project Reference, if possible - that would be the ideal solution.

 

If they're in the same solution you can also use the Project->Project Dependencies dialog to mark each dependecy to make sure they get built in the right order. I don't have much experience there as setting a project as a Project Reference does this for you and works for me.

 

-ner

[mandelbrot]

Ah! Actually, I've omitted one of the reference links. A truer representation of the references would be:

   [a]  1st library
  / | \
[b]  |  [c]  2nd/3rd libraries
  \ | /
   [d]  4th library

 

... so a link does actually exist between [a] and [d] anyway. Basically all of the other references, as well as the current project ([a]) require a link to [d]. This seems to be causing a dependency problem. I do know enough to say that this is actually caused by conflicting copies of a library (dll), but I'm afraid that's as far as my experience takes me. The conflict is rising from one of the central libraries (say for example).

 

I've tried various ways to implement this, but have always arrived at the same problem. Originally everything was code in the same project, but I wanted to break these into smaller, more manageable chunks that could be utilised by any other project (which is supposed to be one of the objectives of .NET, as I see it!). I failed!! LOL!

 

 

Paul.

[Cags]

So...

[a] references , [c] and [d].

references [d]

[c] references [d]

 

If this is the case then there is nothing inherently wrong with the structure of your dll's, which means there is probably something conflicting with the code. Perhaps the same class name in two dll's causing a problem.

 

As Nerseus's says having all the projects in the same solution file would be the ideal solution, is this how you have them?

 

Heres an example.

Test App.zip

Edited March 10, 2007 by PlausiblyDamp

[mandelbrot]

Yes, but then this defeats the whole object of writing a program using .NET. Initially, everything was enclosed in the same solution. I decided to break this all down into manageable component/class libraries stored on a central server. Practically all of the classes reference a very basic library called coreUtils ©. This library tends to provide very general things like accepted default values, and small routines that usually save time. DataServices (b) and simpleSecurity ([c]) both access some of the routines in coreUtils, as does the current project (ehOccurenceClass - a).

 

LOL! What's worse is that when I've completed this class, it's going to be linked into a further couple of classes that will both utilise numerous quantites of the afore mentioned libraries... * Talk about spaghetti! * :rolleyes:

 

 

Paul.

[Cags]

Well I'm obviously missing something here, I don't see at all why my example defeats the objects of using .Net, it follows the exact structure you layed out.

[PlausiblyDamp]

I think you are confusing a Solution with a Project.

 

A Solution contains projects, so having one Solution with all the projects detailed in your example contained within it isn't defeating the point in any way. Have you looked at the example Cags provided?

[mandelbrot]

Right - yep - appologies, Cags. I'm viewing this as a project rather than a solution. Personally, I can't see why this should make much difference - all I'm trying to do is include several already generated libraries into my project - there doesn't seem to be a need for much else. A solution seems a huge overkill for the small (one class) project that this should be! This is why I say that it appears to defeat the object...

 

PS: I did download the example.

[Cags]

Theres no reason why it wouldn't work 'manually' if you like, i.e without a single solution. It can just be tricky getting the references set up correctly. When I was on my placement one of my collegues prefered to work with seperate solutions. But this meant changing all the build events, or manually moving all of the compiled dll's. Personally I could never see the point since VS will do it all for you.

 

As for saying a solution is an overkill, I've personally never worked on a project that wasn't in a solution. Whats more the situation you are describing that uses lots of dll's made by yourself is the ideal candidate, as this is what a solution is for.

 

If you want to do it manually however, as long as all the reference's are set correctly and all dll's are located in the same folder, it should work fine. The tricky part is getting all the references right.

 

EDIT:- putting all teh files you wish to reference in the output directory before compiling may help.

[mandelbrot]

It seems odd that the project not only wants to localise each library to the current project, but also wants to localise dependancies of the referenced libraries! It seems to be this that's causing the problems.

 

I'll try dividing it up into a solution and take it from there.

 

 

Many thanks to you all for your help.

 

 

Paul.

[Cags]

It is not as odd as it may seem if you think it through. For an application to access its referenced libraries, these libraries must be in one of a few places. In the same directory as the application, the system folder or a folder added to the references path list in visual studio. For that referenced library to work, any libraries that it references must also be in one of these folders. As such whenever you build the application it tries to copy all the files to the output directory.

 

Ok, that didn't get confusing at all :D

[PlausiblyDamp]

.Net really takes 2 approaches to deployment - everything in the same folder (or sub folders) or everything in a controlled shared location (GAC).

 

Are you trying to share these DLLs out on the network and access them remotely or are they being installed to the local machine anyway?

I'm assuming they are on the server from your original post - this might also cause other problems (security policies) and installing locally would often be a better choice.

If you are trying to keep deployment issues simple by not having to update client PCs then an alternative route (web services, remoting or similar) may offer a cleaner solution.

 

At the very least you might want to consider strong naming the DLLs and assigning version numbers to them - that way either the dependencies will be managed better or you will have better information on exactly what is causing the problem.