I have the feeling that when CMP0141 was introduced, it wasn't considered a breaking change (not only for sentry-dotnet, but it highlights this particularly well).

Adding this change introduces a round-trip workaround to something that wasn't necessary in the first place (unless we actually document this as a breaking change).

• for sccache in isolation (since it is only relevant to our tests), it would have sufficed to add the CLI CMake config variable -DCMAKE_POLICY_DEFAULT_CMP0141:STRING=NEW without breaking anything (either downstream or in any other consuming project)
• downstream now broke the toolchain file that was created for exactly this scenario. So, if we'd keep CMP0141 as the breaking change it is, then we should replace those settings with CMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded
• Keep in mind that your setting only works in CMake versions that accept CMP0141 NEW. Otherwise, we'd still have to set the flags for older CMake versions < 3.25. With this PR, we now break those older versions without bumping our minimum requirements.

So, to disentangle this, we have two coarse options:

Option A: Revert CMP0141 from CMakeLists.txt

1. Remove cmake_policy(SET CMP0141 NEW) from the top-level CMakeLists.txt
2. Pass -DCMAKE_POLICY_DEFAULT_CMP0141:STRING=NEW from the test fixture (tests/cmake.py) alongside the existing CMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded when sccache is active. This scopes the policy to where it's actually needed.
3. For the LNK4099 fix itself, use target_compile_options(sentry PRIVATE $<$<CONFIG:Debug,RelWithDebInfo>:/Z7>) instead of MSVC_DEBUG_INFORMATION_FORMAT. With CMP0141 OLD, the default /Zi from CMAKE_C_FLAGS_* is still present, but target-level options appear later on the command line, so /Z7 wins via MSVC's last-flag-wins semantics. Not pristine (two competing flags on the command line), but target-scoped, works on all CMake versions, and doesn't affect consumers.

No breaking change. sentry-dotnet's toolchain continues to work. No minimum CMake version implications.

Option B: Keep CMP0141 as a deliberate breaking change

If we decide CMP0141 NEW is the direction we want to go:

1. Document it as a breaking change in the changelog: consumers relying on flag-based debug info control (like sentry-dotnet) need to migrate to CMAKE_MSVC_DEBUG_INFORMATION_FORMAT.
2. Bump the minimum CMake version on Windows to 3.25, or add a flag-based fallback for CMake < 3.25 where the property is silently ignored.
3. Notify known consumers: at minimum sentry-dotnet needs to replace their toolchain flags with set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT "Embedded"). Or we can remove the toolchain file entirely, since those settings can be added here (and the assumptions that downstream will always build with CMake >= 3.25).
4. Consider scope: this PR only sets the property on the sentry target. Crashpad and breakpad targets in external/ are also affected by CMP0141 NEW (their flag-based /Zi defaults are overridden by the property default of ProgramDatabase), but aren't patched by this PR.

I'm painfully aware that this was a breaking change that should never have been merged. Enabling CMP0141 without fully understanding its downstream consequences was a bad idea. Thank you for helping to fix the screw-up. 🙏

I'm painfully aware that this was a breaking change that should never have been merged. Enabling CMP0141 without fully understanding its downstream consequences was a bad idea. Thank you for helping to fix the screw-up. 🙏

I think we've seen worse unintentional breakage very recently 😅.

In any case, just as a reminder: whenever we twist CMake policies, it is likely a breaking change for the build of someone (and since this repo offers only a source distribution, breaking the build contract means signaling it in the version, at least I always tried to handle it this way). We could add something like this in an agents.md (or the contribution docs). CMake policies must always be considered globally, as with changes to minimum version requirements, even if they appear trivially minimal.

I think we should immediately trigger a fix release for this.