Skip to content

Comments

[Repo Assist] Fix #1453: Register CodePagesEncodingProvider on .NET 6+ for code-page encodings#1612

Merged
dsyme merged 1 commit intomainfrom
repo-assist/fix-encoding-codepages-1453-106c516555a0e005
Feb 22, 2026
Merged

[Repo Assist] Fix #1453: Register CodePagesEncodingProvider on .NET 6+ for code-page encodings#1612
dsyme merged 1 commit intomainfrom
repo-assist/fix-encoding-codepages-1453-106c516555a0e005

Conversation

@github-actions
Copy link
Contributor

🤖 This pull request was created by Repo Assist, an automated AI assistant.

Closes #1453

Root Cause

On .NET 6+ (the net8.0 design-time target), code-page encodings such as windows-1250 (cp1250) are not registered by default. Encoding.GetEncoding(1250) throws:

No data is available for encoding 1250. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.

The fix in PR #1503 (closed) correctly identified the problem but added the registration in the wrong location (CsvProvider.fs); encoding resolution actually happens in IO.fs's asyncRead when opening a local file with a non-default encoding.

Fix

In IO.fs, inside asyncRead, wrap the existing encodingStr resolution with a one-time CodePagesEncodingProvider registration, guarded by #if NET6_0_OR_GREATER:

+#if NET6_0_OR_GREATER
+                    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)
+#endif
                     HttpEncodings.getEncoding encodingStr

CodePagesEncodingProvider.Instance is available in-box on .NET 6+; the netstandard2.0 target is left unchanged (registering there would require the System.Text.Encoding.CodePages package which is not currently a dependency). RegisterProvider is idempotent so calling it per-read is harmless.

Trade-offs

  • Only fixes net8.0 target; netstandard2.0 remains limited to standard encodings without the extra package.
  • No new dependencies introduced.

Test Status

Build: ✅ dotnet build FSharp.Data.sln -c Release — 0 errors, 23 pre-existing warnings
Tests: ✅ 3,310 passed; 19 failures all pre-existing network failures (HTTP 403 in sandboxed CI) unrelated to this change

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@0d6e8cf9db90470cd5477c6a40b350fd9f9e1422. View source at https://github.com/githubnext/agentics/tree/0d6e8cf9db90470cd5477c6a40b350fd9f9e1422/workflows/repo-assist.md.

Warning

⚠️ Firewall blocked 3 domains

The following domains were blocked by the firewall during workflow execution:

  • schemas.microsoft.com
  • tomasp.net
  • www.google.com

…e encodings

On .NET 6+ (net8.0 target), code-page encodings such as windows-1250
are not available by default -- Encoding.GetEncoding(1250) throws.
Add a conditional (NET6_0_OR_GREATER) registration of
CodePagesEncodingProvider.Instance in asyncRead so that CsvProvider
(and other providers) can read files with non-UTF encodings on
modern .NET without requiring users to call RegisterProvider manually.

netstandard2.0 is unaffected: CodePagesEncodingProvider requires the
System.Text.Encoding.CodePages package there, so the #if guard skips
registration on that target.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Contributor Author

✅ Pull request created: #1612

@dsyme dsyme marked this pull request as ready for review February 22, 2026 16:55
@dsyme dsyme closed this Feb 22, 2026
@dsyme dsyme reopened this Feb 22, 2026
@dsyme dsyme closed this Feb 22, 2026
@dsyme dsyme reopened this Feb 22, 2026
@dsyme dsyme merged commit 732943a into main Feb 22, 2026
2 of 4 checks passed
@dsyme dsyme deleted the repo-assist/fix-encoding-codepages-1453-106c516555a0e005 branch February 22, 2026 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CsvProvider encoding is not recognized

1 participant