fix(csharp): support spec-correct driver manifests#4341
Merged
Conversation
Closes apache#4329 The driver manager was parsing every TOML file as a connection profile, so real driver manifests (with `manifest_version = 1` and a string `version`) were rejected with "The 'profile_version' field has an invalid value '1.5.2'. It must be an integer." Add a proper DriverManifest parser per docs/source/format/driver_manifests.rst, with [Driver.shared] as either a single string or a platform-tuple table. Managed (.NET) driver selection moves from the C#-specific `driver_type` field on connection profiles to a scheme-prefixed entrypoint on the manifest: `dotnet:Type` for modern .NET, `netfx:Type` for .NET Framework. The host rejects a manifest whose scheme doesn't match its runtime, so mismatches fail with a clear error instead of an assembly-loader mystery. Profile-driven managed loading uses the same scheme via an `entrypoint` option in `[Options]`, which the driver manager consumes and does not forward to the driver. Also aligns env_var placeholder support with the spec syntax `{{ env_var(NAME) }}` per docs/source/format/connection_profiles.rst: placeholders may be embedded anywhere in a value, repeated, missing vars expand to "" (matching the C/C++ driver manager), and unknown functions are rejected. End-to-end coverage against DuckDB lives in DriverManifestTests.FindLoadDriver_WithRealDriverManifest_LoadsDuckDbDriver. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CurtHagenlocher
commented
May 21, 2026
Comment on lines
+59
to
+64
| Managed .NET drivers use a scheme-prefixed `entrypoint`: | ||
|
|
||
| - `dotnet:` for modern .NET (.NET 5 and later, including .NET 8 / .NET 10) | ||
| - `netfx:` for .NET Framework 4.x | ||
|
|
||
| The host process rejects a manifest whose scheme doesn't match its runtime, so a `dotnet:` manifest on a .NET Framework process (or vice versa) fails with a clear error rather than mysteriously failing inside the assembly loader. |
Contributor
Author
There was a problem hiding this comment.
@ianmcook, @davidhcoe, @esadek I've taken the liberty to amend the Driver Manager spec to accommodate drivers which are .NET assemblies and non-AOT compiled. This scheme could further be generalized to e.g. reference a .jar file or a Python-based implementation, if there ever were such a thing. Use of a scheme here is a backwards-compatible way to tell the driver manager how to consume the driver -- or perhaps that it is unable to. One could imagine (implausible as it likely is) that the C++ driver manager could see dotnet: and try to load the .NET runtime to load the driver. And of course, a naive examination of the entrypoint as written would fail to find the symbol in the library.
Member
There was a problem hiding this comment.
Thanks Curt, looks reasonable to me.
davidhcoe
approved these changes
May 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #4329
The driver manager was parsing every TOML file as a connection profile, so real driver manifests (with
manifest_version = 1and a stringversion) were rejected with "The 'profile_version' field has an invalid value '1.5.2'. It must be an integer." Add a proper DriverManifest parser per docs/source/format/driver_manifests.rst, with [Driver.shared] as either a single string or a platform-tuple table.Managed (.NET) driver selection moves from the C#-specific
driver_typefield on connection profiles to a scheme-prefixed entrypoint on the manifest:dotnet:Typefor modern .NET,netfx:Typefor .NET Framework. The host rejects a manifest whose scheme doesn't match its runtime, so mismatches fail with a clear error instead of an assembly-loader mystery. Profile-driven managed loading uses the same scheme via anentrypointoption in[Options], which the driver manager consumes and does not forward to the driver.Also aligns env_var placeholder support with the spec syntax
{{ env_var(NAME) }}per docs/source/format/connection_profiles.rst: placeholders may be embedded anywhere in a value, repeated, missing vars expand to "" (matching the C/C++ driver manager), and unknown functions are rejected.End-to-end coverage against DuckDB lives in
DriverManifestTests.FindLoadDriver_WithRealDriverManifest_LoadsDuckDbDriver.