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.
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
Load C++/CLI DLLs built against .NET 7.0+ in default ALC #66486
Load C++/CLI DLLs built against .NET 7.0+ in default ALC #66486
Changes from 3 commits
a3bb8a5
61ec887
2ccb5ba
73d6bd6
d703fa9
bb8d6ae
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
We could go either with the same mechanism as with the
LoadInMemoryAssembly
(remove the RUC on this method, suppress it inside).Or since this is internal API we could root it conditionally based on the same feature switch the
IsSupported
uses - in that case linker would remove this entire method in trimmed apps (better for size).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.
I thought we had intentionally rooted the native hosting APIs unconditionally, so that users can actually get an error message, since the component doesn't have a say in trimming / the app might not 'know' it is loading a component via hosting APIs?
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.
Oh, I guess we changed that based on #62903? But just for ComponentActivator and not COM or C++/CLI.
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.
So I'd also need to update the sdk so that if you set
EnableCppCLIHostActivation=true
, it also sets_EnableConsumingManagedCodeFromNativeHosting=true
(orEnableNativeHostActivation
since it is being renamed) for an app to at least try to go through C++/CLI activation.And then with the default settings (
EnableCppCLIHostActivation=false
), even withLoadInMemoryAssemblyInContext
rooted unconditionally as I have it right now, users won't get a nice message. Unless I also rootComponentActivator.GetFunctionPointer
whenSystem.Runtime.InteropServices.EnableCppCLIHostActivation=true
and do some sort of handling so thatruntime/src/libraries/System.Private.CoreLib/src/Internal/Runtime/InteropServices/ComponentActivator.cs
Lines 117 to 118 in ba962fd
also enables support when C++/CLI activation is supported.
The non-nice message is:
for trying to call a native entry point (which then calls into managed) in a C++/CLI library.
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.
Hmm - that's a good point - I didn't realize that by relying on the
get_function_pointer
it breaks the existing assumptions around feature switches... I told you there are some dragons hidden here 😇 .Is this because C++/CLI is the only hosting which can propagate full error messages?
I guess what you describe would be a solution - enable native hosting if CPP/CLI is enabled. I would probably do it fully - if you want C++/CLI, you also get full native hosting support - I would not try to do magic in the ComponentActivator. Trimming with C++/CLI activation enabled is a very bad idea anyway.
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.
I think COM also would get the full error message propagated when it is a managed app loading a managed COM component (didn't test it though).
I definitely don't want to do any magic in
ComponentActivator
- my thought for potentially having to do something there would purely be for trying to get a nice error message when someone tries to use C++/CLI when it is disabled. Reread my comment above and realized that this is not at all what I actually wrote... I was trying to say that becauseComponentActivator
entry points are no longer rooted, we don't get a nice error. So unless we always root them (or at least GetFunctionPointer) on Windows and somehow make it do something other than just return the error code, we will just have theSEHException
when activating C++/CLI when it is trimmed/disabled.🐉 🐉 🐉
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.
I think I finally understand it - if the feature switches are off, we remove the main entry point and that leads to bad error experience. I think it would make sense to keep the
GetFunctionPointer
always. I like it a lot as the main entry point for all native->managed (even though that's not what it does today), and as such we should keep it. On Windows eventually we could migrate all hosts to use that, in which case we could completely remove COM/C++/CLI entry points if the feature switches are off, since we would only need theGetFunctionPointer
to fail. That would actually be an overall size win. On non-Windows this will be a very small size regression, but I think it's worth it.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.
I definitely agree that
GetFunctionPointer
is nice as the main entry point. In order to have the nicer error experience (like the managed exception with an informative message), we would probably still need it to have some hook to do something for the COM and C++/CLI cases other than just return an error code if the native hosting feature switch is off.We could also only keep it for Windows, since those are the provided host scenarios we currently have and only do it for non-Windows when we need to - not sure if it is worth the split/discrepancy .
I'll try always keeping
GetFunctionPointer
and working out a decent error experience.