Good question about managing dependencies. I actually ran into a issue related to this earlier this week. What I did in that situation was that I updated Package A to depend on the same version as Package B and released a new version. I think that is fine, since it is a major release and breaking changes are expected between 1.0 and 2.0. I always strive and make sure that I communicate what the breaking changes are so that the consumer is well aware of what has been removed / changed.
It would be interesting to hear how you've solved it. :)
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Your solution is perfectly fine for me. I'd do the same and align version of the depending packages. In most cases, it was a quite straightforward operation. In the longtime perspective, it became a quite big pain in the neck because of the number of dependencies between nuget packages rapidly grew.
We decided to rearrange our package in the way which reduces the amount of it. I consolidated some of them. Some of them we put into the simple library (depending on our needs). The number of nuget packages decreases by 60%. If the problem still occurs, we make binding redirects in app.config files like in the example below:
use nuget packages only for independent/generic places in the solution. Referring to the DDD: shared kernel, generic context.
check if the creation of the nuget package is required and if it could be replaced with a simple dll library. Example question: is this library needed in more than one repository?
use nuget packages for the stable projects. It's annoying when nuget package version updates multiple time in a day.
To sum up, I'm not saying that nuget packages are evil, but it's easy to make a Nuget Hell in your project. The pragmatic approach is essential.
Of course, that is only my thoughts based on my experience. I hope it somehow helps you too.
Yeah this is definitely a learning process. I’m pretty sure the way we are doing it will in some way change in the future. Time will tell. :)
Most of the packages are library functions that we do not want to write over and over again. If a bug or update is neccessary we only have to do it in one place. It is also a motivator to get people more involved as well.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
That’s True. As I mentioned earlier, I replaced Nuget packages with responsible libraries in cases where they weren't in separate repositories. My motivation was to remove unused (be me) abstraction. Maybe in the Future, I’ll be able to utilize the power if the Nuget in 100%. Fingers crossed.
Cheers!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you Rafal!
We have a dozen packages at the moment.
Good question about managing dependencies. I actually ran into a issue related to this earlier this week. What I did in that situation was that I updated Package A to depend on the same version as Package B and released a new version. I think that is fine, since it is a major release and breaking changes are expected between 1.0 and 2.0. I always strive and make sure that I communicate what the breaking changes are so that the consumer is well aware of what has been removed / changed.
It would be interesting to hear how you've solved it. :)
/Niklas
Your solution is perfectly fine for me. I'd do the same and align version of the depending packages. In most cases, it was a quite straightforward operation. In the longtime perspective, it became a quite big pain in the neck because of the number of dependencies between nuget packages rapidly grew.
We decided to rearrange our package in the way which reduces the amount of it. I consolidated some of them. Some of them we put into the simple library (depending on our needs). The number of nuget packages decreases by 60%. If the problem still occurs, we make binding redirects in app.config files like in the example below:
My lessons learned:
To sum up, I'm not saying that nuget packages are evil, but it's easy to make a Nuget Hell in your project. The pragmatic approach is essential.
Of course, that is only my thoughts based on my experience. I hope it somehow helps you too.
Yeah this is definitely a learning process. I’m pretty sure the way we are doing it will in some way change in the future. Time will tell. :)
Most of the packages are library functions that we do not want to write over and over again. If a bug or update is neccessary we only have to do it in one place. It is also a motivator to get people more involved as well.
Thanks for sharing your experience!
Best
Niklas
That’s True. As I mentioned earlier, I replaced Nuget packages with responsible libraries in cases where they weren't in separate repositories. My motivation was to remove unused (be me) abstraction. Maybe in the Future, I’ll be able to utilize the power if the Nuget in 100%. Fingers crossed.
Cheers!