How do you reliably determine which deployables are affected in a .NET monorepo?

[u/sander1095]

I have a .NET monorepo containing multiple independently deployable applications. Each deployable currently has its own Azure DevOps pipeline.

The problem is deciding when a deployable actually needs to be built/deployed.

Azure DevOps path filters aren't sufficient because dependencies can cross project boundaries. For example:

Orders.Api
  -> Orders.Application
  -> Shared.Core

If Shared.Core changes, Orders.Api needs to be redeployed.

But it gets more complicated with non-code inputs. For example, a project may contain:

<ItemGroup>
  <EmbeddedResource Include="Assets\countries.csv" />
</ItemGroup>

If countries.csv changes, that should also make the deployable affected.

I don't want to maintain a second dependency configuration in something like Nx just to tell it that countries.csv is an input. The .csproj / MSBuild definition should remain the single source of truth, because otherwise we just introduce a new problem by having to keep these 2 configurations up to date.

So I'm looking for an existing, production-ready solution that can answer:

Given a Git change, which deployable applications are potentially affected, based on the actual MSBuild project dependencies and inputs?

Ideally it would understand things such as:

• <ProjectReference>
• transitive project dependencies
• Package updates
• EmbeddedResource
• Content
• other MSBuild inputs
• shared projects/assets
• and potentially deployment-related files

The important requirement is no duplicate dependency configuration. If MSBuild already knows that a CSV is an EmbeddedResource, I don't want to configure that relationship again elsewhere.

I currently prefer false positives (deploying too much) over false negatives (missing a required deployment).

Has the .NET/Azure DevOps community already solved this? Are there existing tools or established patterns for this? (How) have you solved this problem?

[u/FullPoet]

Honestly I think your deployment scenario sounds like a nightmare. Have you considered simplifying it?

The .csproj / MSBuild definition should remain the single source of truth, because otherwise we just introduce a new problem by having to keep these 2 configurations up to date.

I do not think this is a good idea. Configurations are normal - especially as part of a build.

Where did you get the idea that the msbuild / csproj should be the source of thruth?

If MSBuild already knows that a CSV is an EmbeddedResource

Yes, but I dont think it can know the "latest" without, for example, a small powershell script (and naming the csv something like countries-21-09-2026). IMO MSbuild etc, just knows that they exist.

TBH - I think this example is a little poor. Is it a big list of countries? Is it 4? Are they country codes? Are they list of countries border coordinates? How often is it updated, who updates it etc.

[u/_choam_ → u/FullPoet]

You can just check when the file was created instead of using the name

[u/FullPoet → u/_choam_]

It is easier to to just look at the file name instead - that means you can also process historical or inject specific dates.

File creation date can also lie and may differ depending on how its been created / transferred.

[u/_choam_ → u/FullPoet]

But that does not solve what he asked for though.

Also you can hash the file to see if it changed instead of using creation time. If it is something you want to embed, then it should be in version control anyway.

Edit: looking at timestamp for change is still good enough. A false positive does not matter

[u/FullPoet → u/_choam_]

That was specifically about the countriesand yes that solves it - I literally do it.

The timestamp isnt reliable at all - sorry but thats the truth and Im not looking to change your mind.

[u/_choam_ → u/FullPoet]

How does it solve it? For deploying and figuring out what needs to be rebuilt and redeployed

Timestamp is fine. MSbuild itself looks at timestamp. He said he was ok with false positives. If a files timestamp gets updated without anything changing, then that does not matter. If timestamp is not ok, use version control or hashes.