-
Notifications
You must be signed in to change notification settings - Fork 321
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
base: main
Are you sure you want to change the base?
Cleanup | Preparation for OS-independent builds #3844
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
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
|
/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. |
|
This PR is not stale. |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
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.