-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Native Library Loader API #27267
Labels
api-approved
API was approved in API review, it can be implemented
area-System.Runtime.InteropServices
Milestone
Comments
annaaniol
changed the title
NativeLibrary class for loading native libraries and funtion pointers, Dllmap specific events
NativeLibrary class for loading native libraries and funtion pointers, LoadNativeLibrary and GetNativeEntrypoint events
Aug 29, 2018
annaaniol
changed the title
NativeLibrary class for loading native libraries and funtion pointers, LoadNativeLibrary and GetNativeEntrypoint events
NativeLibrary class for loading native libraries and RegisterNativeLibraryLoadCallback
Sep 5, 2018
swaroop-sridhar
changed the title
NativeLibrary class for loading native libraries and RegisterNativeLibraryLoadCallback
Native Library Loader API
Oct 8, 2018
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 6, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: https://github.com/dotnet/corefx/issues/32015 In particular, it introduces a change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: * External callers likeAssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle * Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 7, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: https://github.com/dotnet/corefx/issues/32015 In particular, it introduces a change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: * External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle * Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. [PS: NDirect::LoadLibraryFromPath was already written to return the system handle instead of the PAL handle. This change extends the behavior to other private members.] There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 7, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: https://github.com/dotnet/corefx/issues/32015 In particular, it introduces a change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: * External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle * Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. [PS: NDirect::LoadLibraryFromPath was already written to return the system handle instead of the PAL handle. This change extends the behavior to other private members.] There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 8, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: https://github.com/dotnet/corefx/issues/32015 In particular, it introduces a change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: * External callers likeAssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle * Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 8, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 8, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 8, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 9, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Nov 9, 2018
This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit.
janvorli
referenced
this issue
in dotnet/coreclr
Nov 12, 2018
* Refactor LoadLibrary Methods This change refactors the code in DllImport in preparation for implementing the new NativeLibrary API here: dotnet/corefx#32015 The two main changes are: 1) A change in the semantics of the internal LoadLibrary helper functions. When a native library is loaded, there are two categories of callers expecting different return values: External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath() and the upcoming System.Runtime.Interop.Marshall.LoadLibrary() need the raw system handle Internal callers like LoadLibraryModule() need the PAL registered handle This change modifies the internal LoadLibraryModule* methods to work in terms of native system handles, so that external callers can obrain them directly. Methods requiring PAL-handles can register them explicitly. There is no change in external signature of DllImport class, or the native Dll cache in AppDomain class. 2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE This change defines NATIVE_LIBRARY_HANDLE type to represent raw system handles to native libraries that are not registered with the PAL (On Unix systems). The types on PAL and DlImport methods are adjusted to make this semantic distinction explicit. * Fix loading LibC via PAL_LoadLibraryDirect()
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Dec 15, 2018
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015 public static bool RegisterDllImportResolver( Assembly assembly, Func<string, Assembly, DllImportSearchPath, IntPtr> callback ); This API is not yet approved, and the API contracts in CoreFX will not be added until the API approval is complete. In the meantime, we want to have the code reviewed, tested, and avaiable in CoreCLR.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Dec 15, 2018
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015 public static bool RegisterDllImportResolver( Assembly assembly, Func<string, Assembly, DllImportSearchPath, IntPtr> callback ); This API is not yet approved, and the API contracts in CoreFX will not be added until the API approval is complete. In the meantime, we want to have the code reviewed, tested, and avaiable in CoreCLR.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/corefx
Jan 3, 2019
In API review: https://github.com/dotnet/corefx/issues/32015, The LoadLibrary APIs were originally Approved to live in System.Runtime.InteropServices.Marshal class. https://github.com/dotnet/corefx/issues/32015#issuecomment-428775858 However, recently the decision was changed such that the APIs are in a new NativeLibrary class. https://github.com/dotnet/corefx/issues/32015#issuecomment-448324606 Therefore, undoing the changes to Marshal API. I'll submit another PR for System.Runtime.InteropServices.NativeLibrary once the corresponding change in CoreCLR is checked in. This reverts commit 859351c.
jkotas
referenced
this issue
in dotnet/corefx
Jan 3, 2019
In API review: https://github.com/dotnet/corefx/issues/32015, The LoadLibrary APIs were originally Approved to live in System.Runtime.InteropServices.Marshal class. https://github.com/dotnet/corefx/issues/32015#issuecomment-428775858 However, recently the decision was changed such that the APIs are in a new NativeLibrary class. https://github.com/dotnet/corefx/issues/32015#issuecomment-448324606 Therefore, undoing the changes to Marshal API. I'll submit another PR for System.Runtime.InteropServices.NativeLibrary once the corresponding change in CoreCLR is checked in. This reverts commit 859351c.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 11, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015 public static bool RegisterDllImportResolver( Assembly assembly, Func<string, Assembly, DllImportSearchPath, IntPtr> callback ); This API is not yet approved, and the API contracts in CoreFX will not be added until the API approval is complete. In the meantime, we want to have the code reviewed, tested, and avaiable in CoreCLR.
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 11, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 11, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/corefx
Jan 12, 2019
Expose the System.Runtime.Interop.NativeLibrary APIs implemented in CoreCLR. API review: #32015 CoreCLR Change: dotnet/coreclr#21821
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 12, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 14, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 15, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 15, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 15, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 15, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 15, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/corefx
Jan 17, 2019
Expose the System.Runtime.Interop.NativeLibrary APIs implemented in CoreCLR. API review: #32015 CoreCLR Change: dotnet/coreclr#21821 Tests for the API are here: https://github.com/dotnet/coreclr/blob/master/tests/src/Interop/NativeLibrary/NativeLibraryTests.cs
jkotas
referenced
this issue
in dotnet/corefx
Jan 17, 2019
Expose the System.Runtime.Interop.NativeLibrary APIs implemented in CoreCLR. API review: #32015 CoreCLR Change: dotnet/coreclr#21821 Tests for the API are here: https://github.com/dotnet/coreclr/blob/master/tests/src/Interop/NativeLibrary/NativeLibraryTests.cs
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 17, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 17, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/coreclr
Jan 17, 2019
This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in dotnet/coreclr
Jan 18, 2019
Add Per-assembly Load Native Library callbacks This Change implements the Native Library resolution Call-backs proposed in https://github.com/dotnet/corefx/issues/32015
swaroop-sridhar
referenced
this issue
in swaroop-sridhar/corefx
Jan 18, 2019
Expose the APIs to set the Native Library resolver callback. API Review: https://github.com/dotnet/corefx/issues/32015 Implementation: https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/src/System/Runtime/InteropServices/NativeLibrary.cs Tests: https://github.com/dotnet/coreclr/blob/master/tests/src/Interop/NativeLibraryResolveCallback/CallbackTests.cs
ghost
locked as resolved and limited conversation to collaborators
Dec 10, 2020
This issue was closed.
This issue is being transferred. Timeline may not be complete until it finishes.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
api-approved
API was approved in API review, it can be implemented
area-System.Runtime.InteropServices
This issue introduces a NativeLibrary abstraction for loading native libraries from managed code in a platform independent way. It provides two key functionalities
Context
This API is introduced as part of implementing the Dllmap feature. This issue introduces a generic callback strategy, where DllMap is one specific implementation using the API.
Approved API
Related
Earlier Proposal
The text was updated successfully, but these errors were encountered: