I keep seeing the same argument in microservice estates, and it usually gets framed as a tooling choice. Should we pin every NuGet version in one place with central package management, or lean on feature flags so each service can ship new behaviour whenever it likes? Wrong framing. They don't compete. They control two different kinds of change, and most of the pain I see comes from using one to do the other's job.

Here is the split. Central package management, the `Directory.Packages.props` file with `ManagePackageVersionsCentrally` switched on, decides **what code is compiled into your binaries**. A feature flag decides **which compiled code runs right now**. One acts at build time, the other at runtime. Obvious when stated that way, and yet teams routinely try to roll out a risky library upgrade by hiding it behind a flag, which can't work.

Why not? Because the flag can't un-load an assembly. If service A upgrades a shared client library from 4.x to 5.x, the 5.x types are in the process whether the flag is on or off. Static initialisers run. Transitive dependencies get resolved. If 5.x drags in a newer `System.Text.Json` that changes a default, every serializer call in that service sees it, flag or no flag. You can gate the call site. You cannot gate the dependency graph.

So I'd say this plainly: **a feature flag is not a safe way to adopt a package upgrade.** It is a safe way to adopt a behaviour change that lives in code you own.

That sounds like a point for central package management, and for a single repo it mostly is. One file, one version of each package, a dependency bump is one diff that touches every project at once. Drift between projects disappears. Nobody ends up with three services on three patch levels of the same logging package, each failing in a subtly different way.

The cost is the blast radius. One edit to `Directory.Packages.props` changes the build of every service under that root. In a monorepo of, say, thirty services, a bump that breaks two of them blocks a merge that the other twenty-eight wanted. Central pinning trades per-service autonomy for consistency, and in microservices autonomy was the whole reason you split things up.

Which brings me to the part where I take a side. For services that deploy independently and are owned by different teams, I'd put the central file **per team or per domain, not per repository tree**. Shared across the things that genuinely upgrade together, separate across the things that don't. A single global props file for forty services is a monolith wearing a microservice costume. It just moved the coupling from the runtime to the restore step.

Feature flags have their own version of this trap. They are cheap to add and expensive to remove. Each flag doubles the paths through a function, and a service with ten live flags has, in principle, 1,024 configurations of which you tested maybe four. The flags that stay around past their rollout are the dangerous ones, because nobody remembers which combination production actually runs.

My rule of thumb: a flag gets an owner and an expiry date at creation, and the build warns when it's past due. A flag with no expiry is configuration pretending to be a release mechanism.

Now the interesting case. What about when you need both?

Say you're moving a service onto a new major version of a library and the new version changes behaviour you depend on. The sequence that has worked for me goes like this:

1. Bump the package in the narrowest central file that covers the service. Nothing else changes yet.
2. Keep the old code path and add the new one beside it, selected by a flag defaulting to old.
3. Ship. At this point the new library is loaded but the behaviour is unchanged. That is the entire point of splitting the step in two.
4. Flip the flag for a slice of traffic, watch, widen.
5. Delete the flag and the old path in the next release.

Notice that step 1 and step 4 are different risks on different timelines. If something goes wrong at step 3, a rollback is a redeploy. If something goes wrong at step 4, a rollback is a config change taking seconds. Mixing them into one release means a bad outcome can't be attributed to either, and you end up bisecting in production.

This only works when the library lets old and new behaviour coexist in one process. When it doesn't, say a wire-format change on a shared contract package, no flag will save you. That needs a compatibility window: publish a version that reads both formats, upgrade every consumer, and only then start writing the new one. Slower, yes. Still the only honest option.

Shared contract packages are where central management earns its keep in a way people undervalue. If services exchange messages through a common contracts library, then the version of that library is effectively part of your API. Letting each service float on its own version there is how you get a producer writing a field the consumer's older copy silently drops. Pin those centrally and bump them deliberately. Let leaf libraries, the ones that touch only internal code, drift per service if teams want.

One more thing I'd push back on. People say flags give you "independent deployability." They give you independent *activation*. Deployability is about the build and the artifact, and it's dependency versions that tie services together there. A fleet where every service is flag-driven but all share one pinned dependency set still has to move in lockstep for anything that matters.

So the decision isn't flags versus central management. It's two questions you ask separately. Does this change alter what gets compiled in? Then it's a package decision, scoped as narrowly as your ownership boundaries allow. Does it alter what runs? Then it's a flag, with an owner and a date.

Get those the right way round and the tradeoff mostly dissolves. Get them swapped and you'll be debugging a "flagged-off" feature that is still breaking production, because the thing that broke was never behind the flag.

I keep seeing the same argument in microservice estates, and it usually gets framed as a tooling...

Central package management and feature flags solve the same problem at opposite speeds

Tummala Krishna Kishore

Health checks. Structured logging. Retry policies with jitter. Everyone who writes a "production readiness checklist" for a .NET Core service reaches for the same list, and none of it is wrong. But it's the wrong list to reach for first if your services live inside a shared domain model.

I spent a chunk of this month wiring up something that's not on anyone's checklist: turning our domain projects into versioned NuGet packages, pushing them to a private Artifactory feed, and building a bot whose entire job is bumping the version number and rippling that bump out to every microservice repo that consumes it.

It sounds like plumbing. It is plumbing. But it's the plumbing that decides whether "production-ready" means anything across a fleet of services instead of just one.

Here's the problem it solves. Once you factor shared domain logic — entities, value objects, business rules that more than one service needs — out of a monolith and into a library, you've created a dependency graph you didn't have before. Every consuming service now has an opinion, implicit or not, about which version of that library it's running. Before we packaged it properly, that opinion was enforced by copy-paste and tribal memory. Nobody actually knew which service had which version of which rule.

NuGet fixes the packaging half of that. Artifactory gives you a private feed so the package doesn't leak outside the org and you get an audit trail of who pulled what, when. Neither of those pieces is interesting on its own. The interesting part, and the part that actually determines whether this approach helps you or quietly wrecks you, is the bot.

The bot watches the domain package repo. When a new version ships, it opens a PR against every downstream microservice repo, bumping the reference. That's the whole job. No cleverness, just a scripted dependency bump that used to be a manual chore somebody forgot to do half the time.

And here's where I'll disagree with the take you see in half the "microservices done right" posts: automating that bump is good, but only if you admit you've just built an internal Dependabot, and internal Dependabot needs the same discipline the external kind does — discipline most teams skip because "it's our own code, we'll catch it."

You won't catch it. Not reliably.

If the bot opens the PR and someone rubber-stamps merges on domain package bumps the way they rubber-stamp a patch bump on a logging library, you are one mislabeled semver bump away from a breaking change landing in a dozen-plus services on the same afternoon. A shared domain library isn't a leaf dependency. It's load-bearing. A major-version bump there deserves the same scrutiny as a schema migration, because functionally that's what it is.

So the real production-readiness question isn't "do we have a bot that bumps versions." It's "does every consuming service have a CI gate that runs its own integration suite against the new package version before that PR is mergeable — not after." We didn't have that gate on day one. We had the bot open the PR, a green build meaning "it compiles," and a merge button sitting right there. That's not readiness. That's speed dressed up as readiness.

Getting the gate right meant slowing the bot down on purpose. It still opens the PR immediately, but it no longer auto-merges past a minor version bump until the consuming service's full integration suite passes against the new package — not just its unit tests, the whole suite, including the slow ones nobody likes running. That one change moved the failure mode from silent breakage in production to a red CI check somebody has to look at. Not exciting. Correct.

There's a real trade-off here, and I won't pretend it away: this slows down how fast a domain fix reaches every service. In the old copy-paste world, a bug fix in a shared value object reached whichever service someone remembered to update, whenever they remembered — slow, but nobody's build broke overnight because of it. In the new world, the fix propagates fast to every service wired up to the bot, and any service where the fix collides with a local assumption finds out immediately, in CI, instead of three weeks later in an incident channel.

I'd take the second failure mode every time. Fast and visible beats slow and invisible. But the cost is real, and pretending otherwise is how these systems lose the team's trust the first time a bump breaks a build at 5pm on a Friday.

One more thing worth saying plainly: none of this replaces the usual checklist. A service still needs health checks, a sane retry policy, and logs that actually correlate across a request. What packaging and version-bump automation buys you is a production-readiness checklist that's true across the whole fleet, not just true for the one service you happened to test carefully. A service can pass every item on that list in isolation and still go down the moment a shared library changes underneath it in a way nobody flagged.

If you're building shared .NET domain libraries and haven't worked out who reviews a major version bump, what test suite has to pass before that bump merges, and who's accountable when the bot's PR breaks something two services downstream, you don't have a production-ready fleet. You have a production-ready service, once, and a bot quietly deciding when that stops being true.

Health checks. Structured logging. Retry policies with jitter. Everyone who writes a "production...

What a .NET Core service needs before it's actually production-ready

After going through your all edits and a bit of research from me , you want to execute the following command after the publish from the Visual Studio

> C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -pe "appSettings" -site Default -app "/" 

If I understood right , You can try wrapping the _ItemGroup_ in a Target with _AfterTargets_ set to **AddIisSettingAndFileContentsToSourceManifest**

```
<Target Name="executeinHosts" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
    <ItemGroup>
      <MsDeploySourceManifest Include="runCommand">
       //here would be your path that need to run after the publish
      </MsDeploySourceManifest>
    </ItemGroup>
  </Target>
```
So in Your case this is how that part should look:

```
<Target Name="executeinHosts" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
    <ItemGroup>
      <MsDeploySourceManifest Include="runCommand">
         <path>C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -pe "appSettings" -site $(DeployIisAppPath) -app "/"</path>
      </MsDeploySourceManifest>
    </ItemGroup>
  </Target>
```
***Additional Info:***
* **AddIisSettingAndFileContentsToSourceManifest** target works just right before Web Deploy copying files from local to server.
* **aspnet_regiis** can be run in <target> node by _<Exec>_.

**Example:**

```
<Exec Command="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef connectionStrings $(ProjectDir)obj\Debug\Package\PackageTmp" WorkingDirectory="$(publishUrl)" />
```

After going through your all edits and a bit of research from me , you want to execute the following...