I am looking for advice on how to manage shared code between several projects more effectively.
Currently, we have several applications that use the same common backbone of infrastructure code, from simple utilities to wrappers around larger libraries, offering our preferred ideal interfaces internally.
Currently, we have tried and used a mixture of solutions for distributing this among projects, from single large repositories to Nuget packages.
When visiting this topic late last year, the community had warned me off using Nuget as a method, and I would be interested in understanding what best-proposed methods are.
We are currently developing in C#, across a mixture of Core 3.1, framework 4.62, etc. We use TFS 2017 for version control.
At the moment, I'm considering Subtrees and Sub Modules, but I would be really keen on what people have found most effective from their experiences.
Edits
Based on feedback, as @GregBurghardt has mentioned, I am looking for more conceptual solutions or how it has worked for others rather than a specific tool for a job. I.e. what works for your organisation. What are the tradeoffs of your workflow?
I will admit that I was torn whether the question sits well here or on Stack Overflow. As I felt it was more conceptual or opinion-based, I felt it would be more home here ((apologies if it's in the wrong place!)).
As for Nuget @DavidArno, On TFS 2017, we have set up a local NuGet repository, which is being used by other projects. I migrated my project into this environment, but after 'living' with Nuget workflow, it raised numerous issues. The main one is agility, whereby you want to extend or expose shared functionality quickly, you are pushed into a roundtrip of rebuilding, pushing and updating packages. At a low point, I found myself updating packages 10-20 times in a day, at a high point dreading the need to do it once in the day.
When discussing the issues I found with my workflow, the main prevailing opinion was 'that's not what Nuget is for' and don't use Nuget to distribute libraries internally.
An opinion, I'm inclined to agree now. After building a pipeline that would build, push and update packages seamlessly -the time overhead was becoming exorbitant. Full rebuilds of my project to debug something was pushing over an hour, vs sub 10mins in a single solution. Visual Studio and Rider would often throw a 'wobbly' at frequent package churn and updates in the isolated period.
I appreciate it raises wider questions over coupling, architecture - but given an example of something like a reflection library to help and assist with common jobs, there are times when you are growing the library's functional base in tandem with the task you're doing or discovering a more performant way of solving a problem in your library.
I don't believe development workflow should get in the way or deter from this process.
Obviously, there will be onlookers who have mature library x or process y. In those situations, Nuget is probably applicable. But for those who are facing fragmented codebases, duplication of common functionality between projects are likely to be in my situation where I want to bring about better unification.