Need to flesh out Office/VS integration scenarios

[JeremyKuhne]

#1565 cleans up the IMsoComponent OLE related code, but we don't have a clear understanding of the expected interop scenarios with Office and VS with WinForms on .NET Core.

We need to clearly answer:

1. How hosting is expected (or not expected) to work
2. What basic scenarios we want to validate/enable, if any
3. Level of Office support for OLE plugins (understood to be deprecated?)

[weltkante]

1. We have two scenarios we are implementing in our products in Desktop Framework and which we expect to be supported in .NET Core (or be offered an equivalent replacement). Both are based on native COM APIs and C# / .NET Core just happens to be the choice of implementing them.

a) Implement IDTExtensibility2 and register as a COM Office addin. On startup Office loads the addin through COM interop, this will implicitely load and activate the .NET Core runtime.

b) Make a COM visible class available for import into Office macros. The class will be created through COM interop and implicitely load and activate the .NET Core runtime. VBA macros then will call into the class and pass Office COM objects with which your class is supposed to work (for example to fill in an excel sheet with data)

Note that for both we do not need support from WinForms, .NET Core supports that by itself after having brought COM interop back in 3.0. Only if we want to show WinForms UI from our code (which you usually want to do for anything interactive) then WinForms needs to coordinate with Office.

2. WinForms interacts with Office by
a) integrating into the Office message loop so WinForms can peek into messages early when Office is running the message loop
b) sharing the message loop when WinForms pushes a modal loop, so Office can peek into messages early when WinForms is showing a modal form
c) communicating the intention of the message loop so e.g. modal forms can behave properly

What exactly needs to be validated is best communicated with the Office team. Basically WinForms doesn't want to break Office by implementing the interfaces incorrectly. The intention of the interfaces is to coordinate modality and sharing the message loop when 3rd parties show WinForms UI in the Office process. Before #1565 trying to show WinForms UI failed reliably so it is clear to any developer that its not a supported scenario yet. Merging it for 5.0 means you need to make sure that you either disable interop with Office or make sure it works reliably.

3. You'll have to ask the Office team what they want to support going forward, but as of now COM addins and COM interaction from macros are both working reliably over all supported generations of Office. I don't see VBA macros going away anytime soon and they are basically using the same API as COM addins (which is why they can pass Office objects for processing to COM classes).

I see two primary options to go for:
a) get someone from Office and coordinate how to use and test the ComponentManager API
b) get rid of the Office integration and let them handle things without coordinating message loops and modality (I think WPF does it this way? At least I never found a trace of Office integration in the reference source) - this may lead to regressions but at least you can't break Office by using their underdocumented interop in the wrong way.

The risk of not getting the Office team involved and still keeping the ComponentManager interop is that you may accidently break some contract during refactoring and if a 3rd party shows WinForms UI inside the Office process things misbehave. The Office end user may not have the technical knowledge to diagnose and report back when things go wrong, reducing the user experience of Office due to bugs in WinForms.

If the effort of getting the Office team involved is too high I'd recommend getting rid of the IMsoComponentManager integration.

[merriemcgaw]

@OliaG let's sync and discuss what our options are and what we want for the longer term.

[JeremyKuhne]

@merriemcgaw Please pull me in and I can give you some technical context on the runtime code.

[merriemcgaw]

Assigning to @OliaG so we can talk through it and make some support decisions.

[weltkante]

Any update on this? (Just asking because the labeling went from alpha to preview and it would be nice to have a resolution for 5.0 - either supporting ComponentManager/Office integration or removing it from the codebase if it is not required.)

[merriemcgaw]

Funny you should ask @weltkante 😃. @OliaG and I were just reaching out to the folks on the Office Team last night to start kicking off the conversations. We're going to have some management level discussions around what we want to do here as well. I'll keep you updated as we hear from folks.

[weltkante]

Any progress on this yet? I still very much would like to resolve this, either by removing it or implementing it properly.

(Let me remind you that the current codebase has a broken port of undocumented ComponentManager integration, see #247, fixing it is not possible to do reliable without feedback from the Office team since WinForms is using undocumented API here and Office is the only one with a working 64 bit version. Getting the implementation wrong in WinForms will break Office.)

[merriemcgaw]

Hey @weltkante , just wanted to pop in and let you know that there are internal discussions going on about this issue. @OliaG and I will keep you posted as things develop. We don't have an ETA just yet, but I didn't want to leave you hanging.

[weltkante]

I don't know the roadmap of WinForms, but with the runtime going to branch off master in August I'm going to ask again, whats the plan forward with this? Right now this crashes (#247), I'd prefer if .NET Core 5.0 decides to either have Office give direction of how to support (implement/test) the undocumented IComponentManager interface - or confirming WinForms can remove the Office-specific implementation.

[merriemcgaw]

Thanks for the ping @weltkante! We talked about this in a meeting today in fact. I'll have @JeremyKuhne take another look at #247 to see what needs to be done there. But for now, I don't think we're looking to remove any existing code in 5.0, though there's no official direction from Office one way or the other. The consensus is to leave everything as is until we get a specific scenario from a customer. If we leave the interfaces in the codebase it will be much easier to work with a customer that comes to us with a specific scenario that isn't working.

For now, the guidance from Office for Add-In developers is to use their JavaScript based Add-in engine and I haven't seen much appetite to do much with a .NET based approach. That may change in the future however, and that would be one reason to keep the status quo. We'll be able to identify and work through customer scenarios much easier with the interfaces present currently.

[govert]

Thank you for the follow-up @merriemcgaw and @JeremyKuhne
Despite the 'official' guidance around making cross-platform Office add-ins with JavaScript, there are many of us making existing and future Office add-ins on Windows with the .NET Framework, as we have for nearly 20 years now. I think the lack of 'appetite' you see for .NET in Office is a Microsoft internal matter. A big and exciting push for .NET 5 has been to fill out the COM feature set from .NET Framework 4.x for such scenarios, with much improved COM and related support on Windows.

While I can't comment about the particular WinForms issue, it would be very helpful to have NET 5 as a viable platform for making Office COM add-ins on Windows, and not leave some dangling issues and surprise crashes that could discourage anyone trying.

[govert]

As one case study about internal .NET use for Office, I would point to an article where @odhanson describes how the Excel team added Mac support for Power Query using .NET Core.

[weltkante]

Having reflected about the situation a bit more, I've opened #3536 to highlight alternatives. It would be appreciated if you'd reconsider the consensus if any of the options I'm presenting have not been considered yet.

Since Office isn't interested it doesn't feel right to continue discussion in an issue which focuses on scenarios when the feedback is to not actively support those scenarios, so thats why I'm splitting off into a separate discussion. I want to concentrate the new issue on keeping WinForms as a framework reliable even when invoked in scenarios that aren't actively supported.

Defaulting to going live in .NET Core 5 with an implementation that was broken before, has been refactored heavily, and is completely untested is not something I'm comfortable with. While we can work through porting some of our addins and that could discover obvious regressions, working through this by trial-and-error is likely not going to capture edge cases. It certainly won't make WinForms a reliable framework. (Also I repeat WPF doesn't seem to need ComponentManager integration, so I'm not convinced WinForms needs it either.)

The consensus is to leave everything as is until we get a specific scenario from a customer. If we leave the interfaces in the codebase it will be much easier to work with a customer that comes to us with a specific scenario that isn't working.

I'm sure you'll fix any obvious bugs like crashes, but most devs aren't really capable to rootcause subtile behavioral defects between WinForms and Office, both being Microsoft products, the defects happening without any interaction from their code. The end users will have to suffer the consequences, meaning it will fall back to Office in the first place and not the addin author. The devs you are referring to as customers may likely not be aware if WinForms is broken. Subtile bugs are likely going to take a long time to be brought to your attention.

[dreddy-work]

Team went over it with initial review and keep it for future milestone with respect to current priorities.