3

My team and I had a discussion about our future architecture, since we've always just written the code that was needed in each separate project, which have now led to extremely redundant code across multiple systems. Therefore, we wish to create a local NuGet feed to share functionality across our new systems.

Some of us really like this idea, whereas some do not. I wanted to share this with you, to perhaps get some experienced eyes on the matter.

Problem
Redundant code across multiple systems gives us loads of challenges when adding new functionality, or updates to the backend database. Everytime we make changes that should replicate to more than one application, we need to go through all thes e applications and write the exact same lines of code.

Possible solution
As mentioned, some of us thought this through and came up with a solution using TFS to automaticaly create a NuGet package in our local NuGet feed, and then we can simply update said NuGet package to include the new functionality across multiple systems.

Here's a simple illustration to show our ideas:

enter image description here

Of course we would write tests for our shared libraries, but we can be sure that they're working and we do not need to write the same functionality into multiple systems, since they'd just use the library we created for this specific scenario.

Should it occur that we add breaking functionality, the existing systems would not need to update their NuGet package, unless they need that new functionality. It would be okay for System A and System B to still use Library A v1.0.0 though we just added new functionality to Library A v.1.2.4. Should it occur that the existing systems would need new functionality based on one of the libraries, and we did add breaking functionality, it's just a matter of rewriting the old code, to accept the new changes.

Ideas
As mentioned in the very beginning, some of us really dig this idea, while others are not fans of this architecture. I'm writing this question to get experienced eyes on this discussion, and perhaps some better ideas, or suggestions for better architecture on the existing idea I've laid out for you here.

Improve this question
4
  • so when you add json.net or unity or some other published library to your project I assume you use nuget. What is the objection to using it for your own libraries?
    – Ewan
    Jan 30, 2019 at 8:53
  • Some of my colleagues do not like the fact that systems may use older version of the NuGet package, so System A uses Library A v1.0.0 instead of Library A v.1.2.4. I do not see the problem, but some of my colleagues do. I just wanted to get some thoughts on this architecture before we go all-in on it, and start implementing it everywhere.
    – Detilium
    Jan 30, 2019 at 9:00
  • 2
    Possible duplicate of Starting to use TFS - handling internal dependant libraries - local nuget?
    – Machado
    Jan 30, 2019 at 12:07
  • @Detilium well, some systems might use outdated external Nugets. The story is the same. When you release a new library you let people know there is a new release and they update when needed.
    – bobek
    Jan 30, 2019 at 21:37

1 Answer 1

Reset to default
2

It would be okay for System A and System B to still use Library A v1.0.0 though we just added new functionality to Library A v.1.2.4.

I gather this is the contentious issue, not that legacy apps wouldn't be immediately updated, but that a new system would pick a version based on required functionality.

I would say that although its common not to keep up to date with the latest package releases, its bad practice to not use the latest version of a library when you are adding it for the first time.

There is a difference between 'versions' and 'supported versions'. If you found a bug in say v1.0.0.0 of your library after you had released v2.0.0.0, you would only release a hot fixed version v1.0.1.0 if v1 was a 'supported version'. Otherwise you would just release v2.0.1.0 and advise your users to upgrade to v2

If you treat every version as a supported version that's a lot of overhead to deal with.

Improve this answer
6
  • I agree with the fact that it's bad practice not to use the latest version when creating a new system that should use the functionality of said library, and I agree that hot fixes for v.1.0.0 should not only be fixed in v.2.0.0, but we should create a hotfix for version 1, like v.1.0.1, if v.1 is a supported version.
    – Detilium
    Jan 30, 2019 at 9:21
  • yeah, I guess the question boils down to, do you want to be making v1 a supported version?
    – Ewan
    Jan 30, 2019 at 9:23
  • Exactly, that's something we'll have to consider further down the road, when we suddenly have many version of the same library. But I'm more interested in the base idea of this architecture. Is it viable or do we end up with loads of issues when we have many shared libraries? I can't see any issues with this architecture.
    – Detilium
    Jan 30, 2019 at 9:28
  • well there's nothing wrong with using nuget, as you have established by using it for public libraries. the odd thing about your setup is the idea of deliberately not using the latest version.
    – Ewan
    Jan 30, 2019 at 9:30
  • We will be using the latest library in new systems, but I cannot see any reasons for going back into existing systems that use the library, before we actually need the new functionality, or scenarios where we need to edit the existing system anyways. I just don't want to go through each system using the library, everytime I add a new version of the library. I only want to update the library verion in a system, whenever I need to make other changes to said system anyways.
    – Detilium
    Jan 30, 2019 at 9:33

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.