search

dotnet / winforms

Windows Forms is a .NET UI framework for building Windows desktop applications.
MIT License
4.41k stars 981 forks source link

RuntimeEnvironment.GetRuntimeInterfaceAsObject is not supported #247

Open kevingosse opened 5 years ago

kevingosse commented 5 years ago

Running the Microsoft.DotNet.Analyzers.Compatibility, I found one occurence of API that is not supported on .NET Core. In ComponentManagerBroker we call RuntimeEnvironment.GetRuntimeInterfaceAsObject. This method throws a PlatformNotSupportedException.

I wasn't actually capable of writing a repro. This code is hit only in the case where there is a "native component manager" . Since we're trying to retrieve a IMsoComponentManager, I'm guessing this is specific to hosting scenarios in Microsoft Office.

weltkante commented 5 years ago

Besides Office this is also used in Visual Studio (called IOleComponentManager but its the same interface) and in VB6. Maybe more of the "older" languages support it, especially if they were compatible with Office back then (VB6 was able to implement Office addins, which is probably the reason why it supports the interface).

Note that the interface declaration used by WinForms is actually wrong, but apparently it slips through the cracks and doesn't crash anything. (Arguments that should be pointers are commented out and specified as int, which is wrong for 64 bit or when the pointer is to a COM object which needs reference counting.)

I don't know what the plans for .NET Core + Office are. If you can define a ComVisible class in .NET Core and register it, then Office would be able to call into your addin, and if you make usage of WinForms the IMsoComponentManager integration is vital to coordinate the message loop and form modailty with Office.

Any modifications on the implementation probably need to be coordinated with Office since they are the major consumer/provider of this interface, and its semi-undocumented. It was included in the VS 2010 SDK (which included Office headers for this interface) and in the Office documentation you linked, but Office 2010 documentation is outdated and I didn't see newer documentation (have been researching this interface because I had to move our Office addin out of process, and needed to communicate cross process modality with Office).

The VS version of the interface probably can't be used authoritively because VS has no 64 bit implementation but Office does.

merriemcgaw commented 5 years ago

Issue moved to dotnet/corefx #36488 via ZenHub

weltkante commented 5 years ago

@merriemcgaw probably should reopen as corefx doesn't support multiple AppDomains and the unsupported API is used to determine the default AppDomain. You can assume you always are in the default AppDomain and refactor the code accordingly.

Since coreclr can now host COM objects nothing prevents users from attempting to implement an Office Addin in .NET Core and showing WinForms UI from it - they'll run in above error for now, which is probably ok to communicate its unsupported. But once AppDomains have been removed from the codebase (#839) this would suddenly start working, so you probably want to make sure that the cleanup is performed in a way that doesn't break Office.

If you require tests during AppDomain refactoring (which I'd strongly advise since the current interface definitions appear to be wrong in some places) you'd ideally bring in someone from the Office team to help building proper tests, as said above they maintain the major relevant implementation of that interface and the only one I'm aware of which has a working 64 bit implementation. Alternatively Visual Studio also has an implementation and may be able to assist in providing tests.

merriemcgaw commented 5 years ago

Fair point.. We will reopen for now. I'll find an office contact to help us test this scenario.

RussKie commented 5 years ago

/cc: @JeremyKuhne - if you have a spare cycle or two, could you cast your eye... may be give a hint on how to correct IMsoComponentManager definitions

JeremyKuhne commented 5 years ago

I've actually rewritten some of them to be correct. I need to look at the VS implementations and make sure they're actually using the right definitions. I'll poke a bit into this later today.

weltkante commented 5 years ago

I still highly recommend checking with the Office team, they are the main consumers/providers of it besides VS, and as far as I know the only ones with a 64 bit implementation which is actually used in practice (VS still being 32 bit only)

weltkante commented 4 years ago

Since Office is not interested into coordinating usage of ComponentManager API (see #1763) I opened #3536 for discussion of alternatives. I prefer removal or disabling of ComponentManager integration since WPF seems to do fine without it. Not starting the discussion here because this issue can be fixed independently before discussion in #3536 yields results, but if consensus is achieved first then of course both issues can be resolved together.