Building Multiple .NET Projects that share commom dependencies
I am using TeamCity v 10 with .Net Core Projects. This is a part of the projects I Have:
- Common
- Core
- Secutity.Entities
- Security.Repo
- Secrutiy.API
Each of the projects listed depends on all the projects before, for example Core has a reference to Common, "Security.Entities" has references to both Common and Core, and etc...
I have also other API Projects like notification, reporting (each one has Entities, repo and services and might use Entities of other domains).
Actually, I need to deploy only APIs projects to IIS. So I started by creating a build configuration for Security.API which targets its project.json.
- dotnet restore
- dotnet build
- donet publish
However the build in step 2 would fail since it didn't restore the packages for dependent projects. How would such dependent projects configured? I read a lot of snapshot and artifact dependencies, but still confused about the best approach for this situation. Should I create a build configuration for each project how should I link the projects that are dependent to each others.
I appreciate giving me some example and steps that would work for me.
Please sign in to leave a comment.
Hi and sorry for the delay.
The solution depends on how your approach to delivering is. If you have all the previous libraries precompiled, you can just add them to your VCS and use them. If you have some "solution" file where all the dependencies are preconfigured, then this could do it already.
If not, you probably need to compile every library before the deployment. Then you will need to have either a build step, or a build configuration, for each of the libraries. Build steps are thought to be parts of the same logical build, all will run in the same folder and have all its resources available to each other, but make the configuration less reusable (if you use "Common" in other projects, it would be harder to reuse), while build configurations are more flexible in that aspect, but because they can be run in different folders or even machines, require that all required files are copied first.
A snapshot dependency is basically an order marker. If A depends on B (in your case, Core on Common), then you stablish that dependency, and when you trigger Core, TeamCity will also run Common, to make sure that the dependency is satisfied. If you need a result from Common (such as a .dll, or set of them), then you need to configure Common to publish those files as "Artifacts" in Common General settings, then configure Core with an artifact dependency to Commons, where it takes the required files and copies it into local storage (usually in a Libraries folder or similar), where the project would expect to find the .dlls, so that the build can run.
Artifact dependnecies and Snapshot dependencies don't need each other, but can often go together if you need to ensure that the dlls come from the last version of the code. If you don't, then a snapshot dependency is not needed to satisfy an artifact, but a successful build that has created the artifact is.