Share via

CPM for a Microservices project across Repos

Shanmathy Palanisamy 0 Reputation points
2026-04-22T11:15:53.6+00:00

I understand CPM can be used on a repo to create a single Directory.Packages.Props file share across projects on the repo. What about a micro services project that spans across repos ? would you suggest to use CPm only in each repo or across repo or would it be an anti-microservices pattern ?

https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management

Developer technologies | Visual Studio | Other
Developer technologies | Visual Studio | Other

A family of Microsoft suites of integrated development tools for building applications for Windows, the web, mobile devices and many other platforms. Miscellaneous topics that do not fit into specific categories.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Shanmathy Palanisamy 0 Reputation points
    2026-04-22T11:18:49.8966667+00:00

    should i use git submodule essentially a reference to a git repo from another git repo, and share the Directory.Packages.props across repos in Microservices

    0 comments
  2. Q&A Assist
    2026-04-22T11:16:09.8366667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Central Package Management (CPM) is explicitly scoped to a repository: a Directory.Packages.props file is discovered by MSBuild only by walking up the directory tree from a given project, and only one such file is automatically evaluated per project by default.

    For a microservices architecture where each service lives in its own repository, CPM should therefore be used per repository, not across repositories:

    1. Each repo gets its own Directory.Packages.props (usually at the repo root) with ManagePackageVersionsCentrally set to true and the relevant <PackageVersion /> items for that service.
    2. Projects in that repo use <PackageReference Include="PackageX" /> without Version, letting the repo-local Directory.Packages.props control versions.
    3. If a single repo contains multiple services or solutions, additional Directory.Packages.props files can be placed in subfolders to refine versions for subsets of projects, optionally importing the parent file when needed.

    This aligns well with microservices principles:

    • CPM is a build-time, per-repo concern and does not introduce runtime coupling between services.
    • Each service remains independently versioned and deployable; dependency versions are coordinated only within that service’s repo.

    Trying to share a single Directory.Packages.props across multiple repositories is not supported by the CPM discovery rules and would require custom, out-of-band mechanisms (for example, copying or generating the file into each repo). That kind of cross-repo coupling is closer to monorepo-style coordination and can work, but it is a process decision rather than a CPM feature.

    If strong, global consistency of package versions across services is required, a monorepo (single repository) is the model that naturally benefits most from CPM, as described for single repositories: it simplifies dependency management and cross-cutting changes. In a multi-repo microservices setup, CPM should be treated as a per-repo optimization, not a cross-repo mechanism.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.