Let me try to re-phrase the ask for you (please correct me if I am wrong).
"You would like the ability to have an MSIX package containing a plugin to some other application, which is packaged and delivered separately, and want the plugin to appear when the user runs the app no matter how they start it."
Obviously, if the primary app was in MSIX we can accomplish this today by using a Modification Package (assuming we have VFS pathing in the primary package).
But you'd also like to have support for a natively installed app (from an MSI for example) with an MSIX plugin also work. As we don't have a MSIX office option today, your example fits in this category, but there are plenty of other cases as well.
I agree with how @TIMOTHY MANGANphrased the requirement, and want to add that this is critical to my organization moving from App-V to MSIX. In our case, we use an XML editor which is designed to be customized. 20 years of customization are involved, such as .NET code, Perl code, and many other integrations. A lot more than what is normally considered a plug-in. The editor is a Win32 app which rarely changes, but the customization package changes often to meet requirements. To handle the deployment challenges, we package the customization package into App-V, and integrate it with the editor using RunVirtual. The editor is developed by a third-party and is not ready for MSIX. The only other option is to use a stub executable to start the virtual environment and launch the non-virtualized executable, but it is hard to enforce this. If the user adds the non-virtualized executable to the taskbar, then the next time they launch it the virtual environment will not start.
Having said all that, RunVirtual is not necessarily the ideal solution. It would be easier if the executable could be identified in the MSIX package, and automatically get applied when publishing. This flips Tim's other idea on its head, and allows a plug-in to modify a parent process, rather than a child process. Still, we've automated the RunVirtual modification in Powershell, and are happy enough with it, as long as we can use it with MSIX.
@Thom_Cole While this doesn't cover all the cases that you likely want, in my branch of the PSF (TimMangan/MSIX-PackageSupportFramework: The Package Support Framework (PSF) is a kit for applying co... ) I have enabled you to include shortcuts to native exes in your MSIX package that will (with the help of PsfLauncher) allow those native exe processes to run inside of the container. This support is included in PsfTooling 5.2 and above and TMEditX 2.2 and above.
Keep in mind that the external program needs to be able to run inside a container also. So things like Notepad are great but don't even think about Office working that way!
@TIMOTHY MANGAN Thanks for the tip, and that would get us part of the way there. I think the problem would be the same as a launcher program though--if the user adds the executable to the taskbar, then the virtual environment won't start up when the program is launched from the taskbar. I really like the fact that the RunVirtual key starts the virtual environment no matter how a user starts the program, which is exactly what we need.
First off, I'm pretty sure we should talk about individual Office365 Apps being MSIX or not, versus all of Office365 being MSIX. Each of the components under the Ofice365 brand have independent development teams within Microsoft, with their own set of requirements and priorities. Just think back to how the "ribbon" got added to office apps one at a time last decade.
There are, as of today, no Office 365 Apps that are released in MSIX form. Teams has been released as MSIX, but that's not part of Office 365 and was relatively new code. Microsoft has often said things along the lines of 'we realize how important it is for Microsoft to release Office 365 as MSIX', and 'The Office 365 teams are working hard on this', and 'we have nothing to say about when a release of Office 365 in MSIX will happen at this time'.
These statements are old. Surely there are issues with the teams getting this done. On a grand scale, existing first and third -party plugins would have to be redeveloped for a component to go to MSIX. Even the mechanism of attaching the plugins, which are currently in-process dlls, needs to be overhauled. For security reasons alone, these should be integrated as separate processes in the future to harden the office platform.
But whether the dev teams within the Office 365 org have the appropriate level of executive pressure to get something done in this space immediately is an open question, given the lack of externally visible progress.
Specifically, to answer the @Pollewops question, a modification package for plugins would be the most appropriate method to package up a new style plugin, but only if it is a dll loaded into the Office 365 component process directly. The Shared Package Container (SPC) might be needed instead if exe plugins are the future. SPC is only available on Windows 11, so time would be needed to make that feasible anyway.
@Tim Mangan thanks for you reply. Makes some clear to me now. You last section is exactly what is required or wanted here.
Would be nice to be able to create a Modification Package which does copy some files (which basically an add-in is) and set the registry key e.g. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Word\<COM Add-in>
But that, of course, only is possible for MSIX/AppX packages.
The SPC can't be used right now since it is only available for logged on administrators :(
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
