Building a large modular solution with shared components

StackOverflow https://stackoverflow.com/questions/22106651

Question

The Background

I am creating a tool that loads assemblies at runtime to perform work. It gets a message that states what kind of work and other data about what to work on, then it finds and loads the assembly necessary. Each of these task assemblies references a shared assembly, and many of them share one or two other components.

Currently I have each task contained in its own solution. There will eventually be about 50 tasks so developing in a ginormous solution like that would be a bit unwieldy. However, to keep tasks from getting out of date, I would like to create a mega solution that would let us check that changes to a shared component will/will not break a task.

The Current Setup

Task 1 Solution

  • TaskBaseClasses
  • Task1DataLayer
  • Task1
  • AnotherSharedProject

Task 2 Solution

  • TaskBaseClasses
  • Task2DataLayer
  • Task1DataLayer
  • Task2
  • AnotherSharedProject

If I make a change to a class in the TaskBaseClasses project, that change has to be checked against the other projects containing references to that changed class. With two tasks, this is not a big deal. When we have 40 or 50 tasks it will be a real pain to open every one of them and make the changes.

Deployment

In deployment the application is setup like so: ApplicationDirectory

  1. ApplicationDirectory
    • Tasks
      • Task1
        • Task1.dll
        • TaskBaseClasses.dll
      • Task2
        • Task2.dll
        • TaskBaseClasses.dll
    • ProcessApplication.exe
    • Otherstuff.dll

The above illustrates another problem. When I build out the tasks individually, all of the shared references are duplicated. This is not a problem now, but when I have 50 copies of TaskBaseClasses.dll

The Setup I Want

So I would really much rather have (in addition to my smaller individual task assembly solutions) a large solution that would allow me to check all of the tasks for consistency with respect to shared assemblies, AND build everything in such a way that there is as little binary duplication as possible by hosting shared assemblies in a separate place and projects can refer to them by relative path.

MegaSolution

  • TaskShared
    • TaskBaseClasses
    • Task1DataLayer
    • AnotherSharedProject
  • Task1
    • Task1
  • Task 2
    • Task2
    • Task2DataLayer

Deployment

  1. ApplicationDirectory
    • Tasks
      • Task1
        • Task1.dll
      • Task2
        • Task2.dll
      • TaskSharedComponents
        • TaskBaseClasses
        • Task1DataLayer
    • ProcessApplication.exe
    • Otherstuff.dll

Is this feasible? I want to keep the Development solutions AND create a more or less Deployment solution. When I start changing the references for the deployment solution, won't that throw off the references in the development solutions?

We are using TFS 2012 (soon to be upgraded to 2013) automated builds, and I would love nothing more than to have a nightly build of the mega solution ready for testing.

How can I have my cake and eat it too?

Was it helpful?

Solution

Sounds good to me. Use smaller solutions for more localized sets of tasks--perhaps as little as one task per solution--and mega solutions as necessary.

An alternative is to not use binary references for communication between tasks. Consider a more resilient-to-change coupling like HTTP services using JSON. It's much easier to maintain backward compatibility that way.

When you need to share code, use assembly references. When you need to share behavior, consider using HTTP services.

OTHER TIPS

A hand-crafted solution could be a maintenance nightmare. I suggest to have strict naming and structure convention for your projects so you can easily script the collector and deploy.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top