Skip to content
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

Skip NativeLibrary abstraction for Windows-specific system libraries #47013

Merged
merged 1 commit into from
Jan 15, 2021

Conversation

jkotas
Copy link
Member

@jkotas jkotas commented Jan 14, 2021

This is mostly cosmetic change to avoid hitting reflection and creating reflection objects on these paths.

@ghost
Copy link

ghost commented Jan 14, 2021

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

This is mostly cosmetic change to avoid hitting reflection and creating reflection objects on these paths.

Author: jkotas
Assignees: -
Labels:

area-System.Net

Milestone: -

Copy link
Member

@wfurt wfurt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jkotas jkotas merged commit ce4423a into dotnet:master Jan 15, 2021
@karelz karelz added this to the 6.0.0 milestone Jan 26, 2021
@jkotas jkotas deleted the nativelibrary branch January 27, 2021 02:16
monojenkins pushed a commit to monojenkins/mono that referenced this pull request Feb 1, 2021
…Library.*Load* on Mono.

dotnet/runtime#47013 changed how kernel32.dll and Ws2_32.dll gets loaded on Windows. Instead of loading using NativeLibrary.Load these system libraries are now loaded directly using LoadLibraryEx, but symbols are still handled through NativeLibrary. This short-circuits some logic in Mono that assumes all libraries gets loaded through NativeLibrary.Load.

Fix adds ability to use use OS handle in calls to NativeLibrary.GetExport/Free regardless if that handle was retrieved through a call to NativeLibrary.*Load* or not. Fix is not platform specific since the same scenarios can apply to other platforms as well.
lateralusX added a commit to lateralusX/runtime that referenced this pull request Feb 2, 2021
…oadLibraryEx.

dotnet#47013 changed how kernel32.dll
and Ws2_32.dll gets loaded on Windows. Instead of loading using
NativeLibrary.Load these system libraries are now loaded directly using
LoadLibraryEx, but symbols are still handled through NativeLibrary.
This short-circuits some logic in Mono that assumes all libraries gets
loaded through NativeLibrary.Load.

Fix adds ability to use passed in HMODULE when not finding a matching
library in our native library cache and use it directly in call to
GetProcAddress on Windows, inline with CoreClr behavior.
lateralusX added a commit that referenced this pull request Feb 4, 2021
…Library.*Load* on Mono. (#47705)

Handle NativeLibrary.GetExport on libs loaded with Interop.Kernel32.LoadLibraryEx.

#47013 changed how kernel32.dll
and Ws2_32.dll gets loaded on Windows. Instead of loading using
NativeLibrary.Load these system libraries are now loaded directly using
LoadLibraryEx, but symbols are still handled through NativeLibrary.
This short-circuits some logic in Mono that assumes all libraries gets
loaded through NativeLibrary.Load.

Fix adds ability to use passed in HMODULE when not finding a matching
library in our native library cache and use it directly, inline with CoreClr behavior.

* Handle NativeLibrary GetExport/Free using IntPtr library OS handle xplat.

* Disable additional System.Drawing.Common tests due to missing COM support.
@ghost ghost locked as resolved and limited conversation to collaborators Feb 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants