-1

I've been looking into this for quite a long time and still havent found any satisfying solutions. We have a few shared libraries (.csprojs) which also have dependencies on each other as well as 3rd party dlls. I want to have these shared projects referenced in several .sln files.

In the past we have tried to make this work with NuGet. We made all our shared components packages and had a local feed. However, when we wanted to update our shared components it would often mess up in the update process and wasn't reliable. It is causing us more headaches than its worth and honestly makes us not want to add Shared code into our shared libraries.

So, now I'm believing its better to just have a reference to the shared project in each solution, thats easy enough but now theres a further issue:

We use feature branching and the shared code isn't part of the branch. We have a structure similar to the following:

/App1
  /Development  (Folder that just contians Main branch)
     /Main
  /Features   (Folder that contains all Features)
     /F1
/App2
  /Development
     /Main
  /Features
     /F1
     /F2
/Shared
   /Development
     /Main

However, If we make changes to the shared in any of the features - and it is pointing to the code in /Shared/Development/Main then it just updated for all of my features and we dont keep a record of shared changes.

What is the right way to solve these issues? Is there a better way to share components between solutions?

jcfore21
  • 72
  • 6
  • The short answer -- keep a record of shared changes. You should be doing that anyway for backup/safety/etc. reasons. Secondly, do you share the code as an actual "project" for a reason? Can't you just compile the shared code and share it as a DLL/library? That would be the best bet, IMHO. – Matt Runion Sep 22 '15 at 20:15
  • I could have it as a dll, but its not just a single dll per csproj - its also all the interdependencies and 3rd party dlls, I now have to tell my application solution projects what those are as well. Plus we have no way to modify it easily within any of the application solutions. Also, im not sure what you mean by keep a record of shared changes? We are using TFS so that is keeping a history. – jcfore21 Sep 22 '15 at 20:27
  • Since this seems to be a widely shared piece of functionality, have you looked into putting it into the GAC? Would that help with the issue? – Matt Runion Sep 22 '15 at 20:31
  • its not just one piece of functionality - im talking about a whole bunch of shared libraries : /Shared/Development/Main/SharedLib1 .../SharedLibr2 ../SharedLib3. I dont think putting everything in the GAC would be the right solution. I'm looking more for examples of how this is actually done in practice - ive just can't find anything that shows me fully how others are handling shared libraries. – jcfore21 Sep 22 '15 at 20:37
  • In practice, we use compiled objects and the GAC. It's still easier to add multiple DLLs as a reference than to add and maintain a shared project. How many shared libraries do you have? – Matt Runion Sep 22 '15 at 20:41
  • We have about 5 right now. I could see that growing. – jcfore21 Sep 22 '15 at 20:49
  • We just reference those as needed. We keep them centrally located, but we would just compile them and reference all required DLLs. If there was things that EVERY project used, we put it in the GAC. That's the way we handle that here anyway. – Matt Runion Sep 22 '15 at 20:52
  • I think the approach you are using (nuget) is the right one, it might be worth asking some questions about the problems you're having with nuget as most people would recommend this approach for dealing with shared libraries rather than any of the other proposed solutions. – James Reed Sep 23 '15 at 11:43
  • Do you use nuget to update several internal applications in each csproj for each of your solutions? How is that handled properly? It sometimes works and sometimes fails horribly with dependencies. Its incredibly slow (over 30mins to 1hr). I have over 15 csproj in two of my .sln files. When I tell nuget to update all my shared packages - it is slow and doesn't work. I'm not convinced its the right approach. – jcfore21 Sep 23 '15 at 19:30

1 Answers1

0

Answer that we have gone with for our issues:

  1. Take all shared .csproj files and place them in their own Main (into a seperate shared .sln).
  2. Then build unit tests for each library.
  3. Point all other solutions to use these .csproj files as project references. These are solutions that live in another Main or Feature Branches - but they will always point to the shared Main.
  4. Lastly setup build definition to build/test on checkin and nightly builds.

With Step 4 you ensure that if someone changes anything in your shared projects then it will be caught quickly by the unit tests.

We can still use NuGet as a wrapper around things for distributing them out to other 3rd parties - but for internal changes this flow seems to work the best for quick development/testing.

jcfore21
  • 72
  • 6