Cleanup | Preparation for OS-independent builds#3844
Open
edwardneal wants to merge 6 commits intodotnet:mainfrom
Open
Cleanup | Preparation for OS-independent builds#3844edwardneal wants to merge 6 commits intodotnet:mainfrom
edwardneal wants to merge 6 commits intodotnet:mainfrom
Conversation
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
paulmedynski
left a comment
There was a problem hiding this comment.
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). |
|
This pull request has been marked as stale due to inactivity for more than 30 days. If you would like to keep this pull request open, please provide an update or respond to any comments. Otherwise, it will be closed automatically in 7 days. |
github-actions
bot
added
the
Stale
Contributor
Author
|
This PR is not stale. |
github-actions
bot
removed
the
Stale
Contributor
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
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
2 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.
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.