-
Notifications
You must be signed in to change notification settings - Fork 317
Cleanup | Preparation for OS-independent builds #3844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
edwardneal
wants to merge
6
commits into
dotnet:main
Choose a base branch
from
edwardneal:target-single-platform/01-infrastructure-and-public-apis
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Cleanup | Preparation for OS-independent builds #3844
edwardneal
wants to merge
6
commits into
dotnet:main
from
edwardneal:target-single-platform/01-infrastructure-and-public-apis
+80
−341
Conversation
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
Also clean up the netfx-only s_isWindowsNT variable - this was originally used to distinguish between Windows 9x and Windows NT!
We only throw a PlatformNotSupportedException in the constructor; if this throws, there's no way execution can reach a property or method.
This is necessary because when an application using SqlClient is being published, the IL trimmer doesn't see that the throw helper throws an exception, and thus doesn't eliminate the code paths which call Windows-specific APIs. As a result, the Windows-specific API paths aren't removed from executables published for a Linux platform.
paulmedynski
requested changes
Dec 15, 2025
Contributor
paulmedynski
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, with a couple of comments.
src/Microsoft.Data.SqlClient/src/Microsoft/Data/Common/AdapterUtil.cs
Outdated
Show resolved
Hide resolved
paulmedynski
approved these changes
Dec 15, 2025
Contributor
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This PR lays the groundwork to enable a single build of SqlClient to work for both Windows and non-Windows platforms. It also tests the water on the approach.
#3810 helped the shared SqlClient project to build by using the
_WINDOWSand_UNIXconditional compilation symbols; this enables the merge to proceed, but we can move these checks to run-time and make the build process simpler.I've started this process with a simple
IsWindowsmember inADP, and using this to throwPlatformNotSupportedExceptionsin the three Windows-specific public types:SqlColumnEncryptionCngProvider,SqlColumnEncryptionCspProviderandSqlFileStream. As a result of this, the Unix-specific files are no longer necessary and we can remove them.SqlFileStream makes a handful of pinvokes, and as a result I've removed the
_WINDOWSguard on these pinvokes and their associated types to enable the project to compile. I expect that eventually, this'll happen to the entirety of the interop layer.I've put some focus here on IL trimming, making sure that publishing for Unix will strip away the Windows interop layer. This procedure seems a little limited: I can't use my preferred approach of using a throw helper, because the trimmer can't see that the method throws, so keeps the code paths which use the Windows interop layer around.
@benrr101 @paulmedynski this intersects with the conversations around
TargetOsgoing on in #3837.Issues
None.
Testing
While SqlFileStream doesn't have any unit tests to verify that it throws a PNSE on Unix, SqlColumnEncryptionCngProvider and SqlColumnEncryptionCspProvider do. These pass.
I also created a sample application which instantiates a SqlFileStream, then published this using a Linux target with trimming enabled and viewed the result in ILSpy. Every code path except for the one which throws PlatformNotSupportedException was removed, and this led to the Windows interop layer also being removed.