This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Runtime support for upcoming .NET Core WinRT Host#23402
Merged
jkoritzinsky merged 13 commits intodotnet:masterfrom Apr 4, 2019
Merged
Runtime support for upcoming .NET Core WinRT Host#23402jkoritzinsky merged 13 commits intodotnet:masterfrom
jkoritzinsky merged 13 commits intodotnet:masterfrom
Conversation
…osted-interop so just return the HResult instead.
…and initialize it.
…n isolated load context.
… type exported from a winmd.
Member
Author
|
@AaronRobinsonMSFT @vitek-karas can you take a review pass when you get a chance? |
vitek-karas
approved these changes
Apr 4, 2019
Member
vitek-karas
left a comment
There was a problem hiding this comment.
Looks good to me, but @AaronRobinsonMSFT should also confirm, I'm not an expert in the WinRT related logic.
AaronRobinsonMSFT
approved these changes
Apr 4, 2019
Member
Author
|
Test failures are caused by #23552 and are tracked by #23730. |
jkoritzinsky
added a commit
to dotnet/core-setup
that referenced
this pull request
Apr 5, 2019
Implement a WinRT host for .NET Core so users can write WinRT WinMDs that target and build on .NET Core. We can't accurately test this E2E in CI until we have a test machine running a version of Windows with the Reg-Free WinRT support (requires at least Windows 10 19H1 Build 18309). Runtime side of the host work is in dotnet/coreclr#23402
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
* First pass at adding winrt host entry-point. * There's no way to specify HResult-swapping on a function called via hosted-interop so just return the HResult instead. * Use the WindowsRuntimeMarshal class to create the activation factory and initialize it. * Implement loading the dependent assemblies of a WinRT assembly into an isolated load context. * PR Feedback. * Fail to get the activation factory if the found type is not a managed type exported from a winmd. * Rearrange parameters based on PR feedback. * Remove unneeded include. * Make ActivationFactoryLoader internal. * Fix null-ref in WinRT-dependent-assembly loading * Remove extraneous "System." Commit migrated from dotnet/coreclr@fdc9998
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Add
ActivationFactoryLoader.GetActivationFactoryentrypoint for the upcoming .NET Core WinRT host (dotnet/core-setup#5527).Enable assemblies that a WinRT assembly depends on to be loaded into an AssemblyLoadContext other than the default (required since the WinRT components do not necessarily own the TPA).
Ensure that COM is started correctly before marshalling to or from COM interfaces in the COM interface marshaler.