-
Notifications
You must be signed in to change notification settings - Fork 94
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
Emit CCW entrypoint functions and populate vtbl #825
Conversation
@tannergooding one question I and @JeremyKuhne have for you particularly is whether I took the right approach for the CCW on methods that do not return HRESULT with regard to reporting errors to the caller. Is throwing managed exceptions back to them acceptable? If not, what is the alternative? |
On Windows it is supported via SEH. I'm not a fan of evangelizing that support because it won't be present on other platforms and writing .NET code that is platform specific is generally a code smell for me. I get the "this is only for Windows" but that, to me, is a cheap trick rather than just doing what is correct for COM and that is fail fast. COM has long held exceptions don't propagate across binary boundaries and .NET has done a poor job of enforcing that behavior. The TL;DR here is yes this will work but it is setting expectations that likely won't be met if we ever port to another platform. |
Thanks, @AaronRobinsonMSFT. |
Confirming here so we are on the same page, the implementation of the COM interface is in managed code, right? We are talking about CCWs.
Yes, I would prefer the fail fast on the managed side to throwing a managed exception and having it propagate. Coming back into unmanaged (i.e., native) code means we are assuming the caller is going to have set up a SEH handler. In my experience this is exceedingly rare and results in DMPs that aren't always that easy to root cause and if it was detected I'm not sure what the caller expects to do with that exception. It also assumes the transition from managed to SEH is something the caller thought about - also unlikely. COM interfaces that don't return an If we are looking to support COM, actual COM not any of the various "subsets", then a member either returns an |
The new elements are the
[UnmanagedCallersOnly]
functions, thePopulateVTable
method, and theComHelpers
class.The
PopulateVTable
method skips initializingIUnknown
andIDispatch
inherited members because we have nothing to forward them to. We count on ComWrappers or the app to supply these.Samples
Here is the
ComHelpers
class:Here is a relatively small and straightforward COM interface with just a couple unique methods:
The
ITypeInfo
interface is interesting because it defines methods that do not returnHRESULT
. In such cases, we throw and/or allow managed exceptions to propagate to the native caller:In another case, the emitted interface includes properties declared as properties, so we emit special code to handle that case too:
Closes #751