Clever Geek Handbook

Nougat addiction

I have a little question about my own NuGet server and the native NuGet packages we push to it. We have several projects and an adapted TFS build process that automatically launches NuGet packages on our NuGet server - so far it works pretty well.

We are currently asking ourselves if this is a good solution: Our main project uses dependency injection to resolve dependencies. Therefore, we have a project structure such as:

  • Interfaces (.dll)
  • DataLayer (.dll)
  • Localization (.dll)
  • Infrastructure (.dll)
  • Application (.exe)

In my opinion, I would like to split things up into smaller solutions to make it simpler and easier to use:

  • Interfaces (one project only: interface definitions)
  • Compontents (three projects: with DataLayer, localization and infrastructure)
  • Application (only one project: only exe)

This leads us to a problem: if someone changes the interfaces, we will need to update the nuget package version of the interfaces in each component project, commit the changes to our build system, and then update the application itself. It's a bit like DLL Hell - besides, debugging and development is a little more difficult if you try it because of multiple projects being separated.

Is this structure crap? What do you think is a good option for solving dependencies, and for shrinking and expanding large solutions into smaller ones? Or would you recommend combining all projects into one big solution?

+3


source to share


1 answer


The approach you recommend, "if someone changes the interfaces, we will need to update the nuget-package of the interfaces in every component project, make the changes to our build system" is not really best practice and will cause problems when scaling.

Ideally, you want to separate package development from consumer development. Consider your component package and application layer. If you have a current setup where the application project is consuming 1.0.0.0 of your component package. Someone goes in and adds a new component to the Components package and creates version 1.1.0.0. Now, if you go in and update the component package in the Application project, the following will happen:

  • Fixed any bug fixes included in the new component packs (which might be helpful)
  • Any new components added to the package will be available to the application project (this is good only if the application will consume the new component, otherwise it will not affect the application at all)
  • Any new bugs that were added during the creation of a new component that might unintentionally affect the functionality of existing components can also be received.


In my opinion, point 3 is the most dangerous impact of a package update. Whenever I know that a new version of a package is about to fix a bug or introduce new functionality that I NEED for an application, I'm fine with the risk of adding new bugs. However, if I don't use the new components, I would basically introduce instability into the application design without any added benefit.

The process I would recommend is

  • Separate the development of each package from its consumer. This approach scales very well and gives the consumer the OPT-IN option for new changes.
  • Create some system / convention where the developers of the package can tell the consumer when a new version will be released. A good release notes / simple blog can suffice as well.
  • For application / project developers who consume a new package, only pull the latest version when it contains the functionality the consumer needs.
0


source






More articles:


All Articles