2

I am struggling with how to organize external references in a C# program in order to minimize code repetition.

I have application "A1" for which I want to use Microsoft's Unity IoC/Dependency Injection system. So I use NuGet to pull down the Unity package and install it in A1. This pulls down 2 projects and 4 DLLs into A1's project.

To facilitate using Unity, I encapsulate the container object in a Singleton pattern (S1). So I have a constant/consistent home for the container and no matter where in A1 I have easy access it.

But I want to use Unity in a different and independent application A2 as well. This other application is not in the same solution as A1. Thus it would make sense to move my S1 code to a third solution which builds an external DLL (D1) that can be referenced by both A1 and A2. In this way I am not continually writing the S1 code in each application. I have achieved code re-use!

However in order to do so I now need to use NuGet to insert references to Unity into each of the A1, A2 and D1 projects/solutions. And because of that, the versions of Unity in the application and DLL are totally independent. I am starting to feel like the epitome of the old Regex joke:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

I can't see a clean way to organize all of this. The only options I see are:

  1. Manually duplicate the S1 code in every application (and leave it out of the DLL), and use NuGet to enable Unity into just those applications.

  2. Move my S1 code to the DLL, but have NuGet reference totally independent versions of Unity in the applications A1 and A2 and the DLL D1 solutions.

  3. Move my S1 code to the D1 DLL and have NuGet reference Unity only in that solution. Then in every application add not only my custom D1 DLL from the DLL solution, but also manually add the 4 Unity DLL's that were added to my D1 solution.

All 3 of these options have some sort of code smell. I am currently leaning to option 1 as being the least worst option of those 3. Is there a 4th option that provides the flexibility I want but eliminates these code smells?

I know that the singleton code is only a very small file, but it is the principle of this dilemma that is killing me. Also my D1 project has a whole bunch of other common code and not just the S1 code.

Improve this question
1
  • A fourth option to consider could be dropping the sharing of what you call S1 and have each application have their own (even if they are largely the same code). If you are not sharing container configuration at all and it's only about wrapping unity access... just reuse as a code snippet.
    – Joppe
    May 16, 2017 at 6:51

1 Answer 1

Reset to default
1

Create a new nuget package for S1 with a dependency on the Unity package.

You can then consume this nuget package i your applications and they will automatically import Unity as a dependency

Improve this answer
1
  • Never even thought of doing that. I looked into it and it is not overly complex, including hosting my own NuGet package repository. So definitely the way to go given the technologies I am using.
    – Peter M
    May 8, 2017 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.