CODEWITHSUNDEEP
.net.net-assembly
Thomas
Thomas

Reputation: 9277

.net assembly dependency chain

I have the following situation. We are woring on a multilayered application, so I made different assemblies for each layer. Lets call them Top, Middle and Base. They are dependend like:

Top->Middle->Base, because Top uses clases from Middle and Middle from base.

Now we will have a secong Applikation Top2 that only needs some classes from Middle that don't use anything from Base.

Is there a way, to not include Base in the deployment of Top2?

WHen trying to complie, VS tells me that I need also the reference to assembly Base.

Best Thomas

Upvotes: 0

Views: 302

Answers (1)

KingCronus
KingCronus

Reputation: 4529

Sounds like "Middle" is getting a bit big for its boots.

An assembly shouldn't reference anything that it doesn't need. So therefore your situation sounds like a good candidate for splitting the assembly.

Current

Application One -> "Middle.dll" -> "Base.dll"

Your Proposal

Application One -> "Middle.dll" -> "Base.dll"

Application Two -> "Middle.dll" -> "(Redundant) Base.dll"

This is a typical issue which comes up when some really commonly used objects are essentially lumped with business logic unneccesserily. i.e. you might have utility classes in Middle.dll which are useful to applications, but they don't really need to be in there. You might be better with a seperate utilities dll.

Suggestion

Application One -> "Middle1.dll" -> "Base.dll"
                -> "Middle2.dll"

Application Two -> "Middle2.dll"

All of the functionality that needs to use Base.dll, which currently exists in Middle.dll, should be moved to Middle1.dll. That way if you only need to use the non dependant code, you can just reference Middle2.dll

It might be a big refactor, dependant on your codebase, but later on down the line you will appreciate it!

Benefits to this

  • Testing is going to be improved.
  • If you ever need to make these two applications totally separate, you would have less refactoring to do.
  • Less chance of breaking both applications if you only need to change "Middle1" for some reason
  • Cleaner seperation of concerns
  • No compiler problem like you currently have
  • No lumping code not required for a program with every program
  • Smaller, more manageable assemblies
  • Improved intellisense
  • Middle1 and Middle2 can share the same namespace, so to your Applications they won't know the difference.

Note: Obviously I'm not suggesting that you should call them Middle1 and Middle2. But you get the idea.

Upvotes: 1

Related Questions