Microsoft Office add-in deployment using MSIX

Iron Contributor

Hi,

we need to package a .NET desktop application and a COM add-in which extends Microsoft Office applications using MSIX.

 

What technology does MSIX and Desktop Bridge have to support creating such packages?

 

Our app and library currently defines two COM classes which must be registered in user registry and integration with MS Office apps requires us to write to registry at HKCU\Software\Microsoft\Office\AppName\Addins

15 Replies

Hi @Jozef IzsoWindows and Office are working hard to enable M365 Apps (e.g. Word, PowerPoint, Excel) to be packaged and delivered in MSIX format with the same full extensibility that customer enjoy in Click-to-Run and MSI. When the time comes,  we’ll communicate details and timelines as to when you will be able to package MSIX Office add-ins. 

@Dian Hartono What's the timeframe for this? We have lots of customers who's IT departments will prefer or require MSIX deployment over MSI.

@Jozef Izso We understand your excitement for this ask. Unfortunately this is all we can disclose and are unable to provide more timelines at this time.  Please follow Office and MSIX blog for a formal announcement as more becomes available.  

 

John Vintzel (@jvintzel)
PM Lead, MSIX

Hi @John Vintzel 

 

Just checking in as it's been a while without an update - I'm sure there still isn't any official announcements available but wanting to indicate existing enterprise environments with a heavy App-V implementation are also wondering how our applications will co-exist with a Click2Run or MSIX installed client.

 

We currently have the MSI installs for this reason (with an array of App-V packages that run 'on top' and semi-integrate or outright include really old Word 2003 installs to accommodate the legacy crap, for example). 

 

Installing a C2R client appears to have altered the COM interfaces even impacting the behaviour of App-V packages with internal conflicting Office installs which is interesting - Obviously we've got a bunch of development to do investigating this further, but having an MSIX footprint instead of C2R would indeed provide another avenue.

 

At this stage, it's looking like we'll need to retain another SOE for the legacy applications where the MSIs are installed, unfortunately and have a modern SOE for the small percentage of 'Office' workers...

Hi @John Vintzel,

Any update already about MSIX and Office 365 COM/Automation addins ?

Hi @Pollewops, no updates to provide yet.  

Why is this feature request not being implemented? This is super easy to be done on MSIX part (to declaratively define COM classes - there is already ability to disable virtualization for app packages) and it would be a safe way to create Office add-ins.

Instead we are forced to escape sandbox and create our own solutions to a problem which should not exists in the first place.

@Dian Hartono any updates on this?

Hi @Dian Hartono any update on this?
@Naveen_Nooka 

@Pollewops 

 

Bumping to @Naveen_Nooka as Dian hasn't been active here for a while (may have moved on?)

Is there an update to this? Microsoft are separately telling people that MSIX is ready for mainstream adoption - https://techcommunity.microsoft.com/t5/windows-events/msix-and-app-attach-made-easy/ev-p/3971565

But aren't prepared to back the new MSIX format with one of their own key application suites - this is sending out conflicting messsages to your customers.
@John Vintzel what is the link to the blog for Office that you suggest would track formal announcements for Office adopting MSIX, as this conversation is already in the MSIX discussion community area as there isn't a dedicated Blog for MSIX?
Seems I've found the Feedback hub for MSIX as it still exists.
https://techcommunity.microsoft.com/t5/msix-feedback/idb-p/MSIXIdeas
Although the MSIX discussions are now aligned under Windows IT Pro Blog, as part of this change:
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/realigning-the-msix-tech-community/ba-p/3...
Hi Jozef,
I'm in the same boat. Have you tried using the RegistryWriteVirtualization instruction to disable virtualisation for HKCU/Software/Classes, then having a MSIX-installed exe do the registration of the COM Addin dll as a post-installation step (either by directly writing the COM registry entries you need, or calling regasm)?