From 875fabfce166374ff019093cd4444b6707d89406 Mon Sep 17 00:00:00 2001
From: electricessence <5899455+electricessence@users.noreply.github.com>
Date: Thu, 12 Nov 2026 08:15:36 -0800
Subject: [PATCH] Release builds map the repository folder to a neutral prefix,
 so a package does not embed the build machine's folders

In a Release build the SDK now maps the repository root (DeterministicSourcePaths) in every path it embeds: the
source files, the debug-symbol path inside each dll, and the Source Link mapping inside the symbols. A package
built on a developer machine no longer carries that machine's folder names. Debug builds are unchanged, so local
debugging still finds the sources.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---
 Source/Directory.Build.props     | 4 ++++
 docsite/articles/whats-new-11.md | 1 +
 2 files changed, 5 insertions(+)

diff --git a/Source/Directory.Build.props b/Source/Directory.Build.props
index 2b5fef9..af9ea39 100644
--- a/Source/Directory.Build.props
+++ b/Source/Directory.Build.props
@@ -8,6 +8,10 @@
 		<!-- Release candidate line: delete this element (or pass -p:VersionSuffix=) to build the stable 11.0.0 packages. -->
 		<VersionSuffix Condition="'$(Configuration)' != 'Debug'">rc.4</VersionSuffix>
 
+		<!-- A package built on a developer machine must not carry that machine's folder names. In a Release build the SDK maps the repository root to a neutral prefix
+		     in every path it embeds: the source files, the debug-symbol path inside each dll, and the Source Link mapping inside the symbols. -->
+		<DeterministicSourcePaths Condition="'$(Configuration)' == 'Release'">true</DeterministicSourcePaths>
+
 		<!-- net11.0 is the primary/modern target: each major version of ODX targets the matching .NET.
 		     net10.0 (LTS) stays alongside it. netstandard2.0/2.1 are retained as shimmed
 		     legacy paths (via #if switching + BCL compat packages). net472 lives only on the
diff --git a/docsite/articles/whats-new-11.md b/docsite/articles/whats-new-11.md
index 54a8053..c6a69a6 100644
--- a/docsite/articles/whats-new-11.md
+++ b/docsite/articles/whats-new-11.md
@@ -7,6 +7,7 @@ Version 11 is a performance release and a tidy-up release. Result mapping is rew
 
 ## Changes since rc.4
 
+- A package built in a Release build no longer carries the build machine's folder names: the SDK's `DeterministicSourcePaths` maps the repository folder to a neutral prefix in the dll, the debug symbols and the Source Link mapping.
 - Version 11 targets .NET 11: every package adds `net11.0` next to `net10.0` (LTS), `netstandard2.0` and `netstandard2.1` (`MSSqlClient`: `net472`, `net10.0` and `net11.0`). Each major version of the library targets the matching .NET. Building the repository needs the .NET 11 SDK (`global.json`).
 - `.SingleResult()` can be written before `Map`, so a query reads as behavior first, then shape: `command.SingleResult().Map<Post>().ToListAsync(cancellationToken)`. It works on an expressive command (`IExecuteReader`) and on a raw `IDbCommand` or `DbCommand`, with the same `Map` overloads as before, and it is the same as `command.Map<Post>().SingleResult()`, which still works. There is none on `IDataReader` or `DataTable`: their views never read through, so there is nothing to opt out of. Nothing changes by default: without it a `Map` terminal still reads through the later result sets.
 - **`ExecuteScalar<T>()` and `ExecuteScalarAsync<T>()` convert the way `Map<T>()` does.** They cast the provider's value exactly, so a `bigint` read as `int`, or a `numeric` read as `long`, threw `InvalidCastException`, which a port from Dapper met only on a real database. Now a value that is already a `T` is returned as it is, an integer converts to another integer type with a range check, and any other value is converted by the same code `Map<T>()` uses. `NULL` and no row still give `default(T)`. A value that cannot be converted, or does not fit, throws `ValueMappingException` with the conversion's error inside. **Behavior change:** a call that threw `InvalidCastException` now converts, or throws that exception. `ExecuteReturn<T>()` and `ExecuteReturnAsync<T>()` convert the same way. The overloads that take a `Func<object?, T>` are unchanged.