All geek questions in one place

Project Links v NuGet Dependencies

I embed NuGet in our software development process, both for external binary files (for example, Moq, NUnit), and for internal library projects containing common functionality.

TeamCity creates NuGet packages from our internal library projects and publishes them in a local repository. My modified solution files use a local repository to access NuGet packages.

Consider the following solutions for source code:

  • Company .Interfaces.sln creates Company.Interfaces.1.2.3.7654.nupkg .
  • Company .Common.sln contains a link to Company.Interfaces through its NuGet package and builds Company.Common.1.1.7655.nupkg , with Company.Interfaces.1.2.3.7654 included as a dependency.
  • Company .DataAccess.sln uses the added value of Company.Common nupkg to add Company.Interfaces and Company.Common as links. He builds Company .DataAccess.1.0.8.7660.nupkg , including Company.Common.1.1.1.7655 as a dependent component.
  • Company .Product.A is a web solution containing links to all three library projects (added by selecting Company.DataAccess NuGet).

Questions:

If there is a source code change for Company.Interfaces, do I always need to renumber and rebuild the intermediate packages (Company.Common and Company.DataAccess) and update the packages in Company.Product.A?

Or it depends on whether there was a change in the source code

  • error correction or
  • new feature or
  • violation?

In fact, I have 8 levels of dependent library packages. Do I need tool support to update the entire package tree?

I know about the semantic version.

We are using VS2012, C # 4.0, TeamCity 7.1.5.

+6
source share
2 answers

It is a good idea to update everything with every registration in order to check it at an early stage.

What you are describing can be easily managed using artifact dependencies ( http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies ) and “Finish Build” assembly triggers (or even just “Running Nuget dependencies”).

+3
source

We wrote our own assembly configuration in the base project (in this case, Company.Interfaces.sln ), which builds and updates the entire tree in one go. It checks for updated package.config and .nuspec files along the way. I can’t say how much time it made us be, even if it might seem redundant in the beginning.

One note: the script we wrote checks in the files, even if the chain does not work somewhere in the middle, to give us the opportunity to fix it on our local machine, check the fix and restart the publication.

+1
source

Source: https://habr.com/ru/post/946257/

More articles:


All Articles