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

Support injecting NativeAOT-compiled DLLs (.NET 8) #13

Open
alexrp opened this issue Jul 6, 2022 · 2 comments
Open

Support injecting NativeAOT-compiled DLLs (.NET 8) #13

alexrp opened this issue Jul 6, 2022 · 2 comments
Assignees
Labels
area: analyzers Issues related to the diagnostic analyzers and source generators. area: build Issues related to the build system. area: documentation Issues related to the documentation. area: hosting Issues related to the hosting model. area: infrastructure Issues related to infrastructure (GitHub, CI, etc). area: injection Issues related to the assembly injection APIs. area: samples Issues related to the sample projects. state: approved Feature requests and housekeeping tasks that have been approved. type: feature Issues that are classified as feature requests.
Milestone

Comments

@alexrp
Copy link
Sponsor Member

alexrp commented Jul 6, 2022

In theory, Ruptura + NativeAOT is a match made in heaven. We could just inject a NativeAOT-compiled DLL and directly invoke an entry point method in it, skipping ruptura-<arch>.dll and all the ceremony around .NET hosting entirely.

For this to work, the source generator would need to export a function that we can invoke to pass in these parameters:

typedef struct
{
// Keep in sync with src/injection/AssemblyInjector.cs.
size_t size;
const wchar_t *nonnull *nonnull argument_vector;
uint32_t argument_count;
uint32_t injector_process_id;
uint32_t main_thread_id;
} ruptura_parameters;

That function would then do all the initialization that the native module currently does (e.g. calling InjectedProgramContext.Initialize()), and then call the user's IInjectedProgram.RunAsync() implementation.

NativeAOT does come with a number of disadvantages that are inherent to that model of compilation: Very limited reflection, no dynamic code generation, forced IL trimming, and more. This means that any NativeAOT support would exist alongside our current hosting model so that users can choose the approach that makes the most sense for them.

@alexrp alexrp added state: blocked Issues that are blocked on some other issue/work. type: feature Issues that are classified as feature requests. area: build Issues related to the build system. area: documentation Issues related to the documentation. area: infrastructure Issues related to infrastructure (GitHub, CI, etc). area: analyzers Issues related to the diagnostic analyzers and source generators. area: hosting Issues related to the hosting model. area: samples Issues related to the sample projects. area: injection Issues related to the assembly injection APIs. labels Jul 6, 2022
@alexrp alexrp added this to the v2.0 milestone Jul 6, 2022
@alexrp alexrp self-assigned this Jul 6, 2022
@alexrp alexrp added state: deliberation Issues that require considerable deliberation and/or discussion before a resolution can be found. and removed state: blocked Issues that are blocked on some other issue/work. labels Jul 6, 2022
@alexrp alexrp modified the milestones: v2.0, v3.0 Jul 23, 2022
@alexrp alexrp changed the title Explore possibilities regarding NativeAOT support in .NET 7 or 8 Explore possibilities regarding NativeAOT support (.NET 8+) Oct 30, 2022
@alexrp
Copy link
Sponsor Member Author

alexrp commented Aug 3, 2023

NativeAOT support in .NET 8 should be good enough that we can do this.

@alexrp alexrp added state: approved Feature requests and housekeeping tasks that have been approved. and removed state: deliberation Issues that require considerable deliberation and/or discussion before a resolution can be found. labels Aug 3, 2023
@alexrp alexrp changed the title Explore possibilities regarding NativeAOT support (.NET 8+) Support injecting NativeAOT-compiled DLLs (.NET 8) Aug 3, 2023
@alexrp alexrp removed their assignment Jan 27, 2024
@alexrp
Copy link
Sponsor Member Author

alexrp commented Apr 30, 2024

When we do this, we should just document the exported entry point that Vezel.Ruptura.Injection will support. That way, it can effectively be used to inject arbitrary native DLLs that conform to that signature. Something like:

typedef struct
{
    size_t size;
    const wchar_t *nonnull *nonnull argument_vector;
    uint32_t argument_count;
    uint32_t injector_process_id;
    uint32_t main_thread_id;
} ruptura_native_parameters;

__declspec(dllexport) uint32_t ruptura_native_main(ruptura_native_parameters *nonnull parameters);

@alexrp alexrp self-assigned this Apr 30, 2024
@alexrp alexrp modified the milestones: v4.0, v3.0 Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: analyzers Issues related to the diagnostic analyzers and source generators. area: build Issues related to the build system. area: documentation Issues related to the documentation. area: hosting Issues related to the hosting model. area: infrastructure Issues related to infrastructure (GitHub, CI, etc). area: injection Issues related to the assembly injection APIs. area: samples Issues related to the sample projects. state: approved Feature requests and housekeeping tasks that have been approved. type: feature Issues that are classified as feature requests.
Development

No branches or pull requests

1 participant