Advice for planning our MSIX migration / Complex legacy application

[JoeHae365]

Hi folks,

we are planning to migrate our application to MSIX very soon, and at this point we have a couple of questions regarding the architecture of our future MSIX installer.

First, some information about our application which we currently deploy via WIX & MSI:

- It is the client application of a Client/Server solution

- C# WPF Main application and administrative console (currently migrating to .NET Core 3.1)

- Main application heavily relies on Plug-Ins

- C++ configuration application

- OpenJDK runtime for some JAR workloads we start from within the main application

- we register an own URL protocol handler in HKCU, which starts a small EXE which in turn starts our main app

- The main application, admin application and config application should be in the start menu

- Not every user should have access to all applications (most only the main application). 

Now some points we don't see very clearly at the moment:
Q1: When we package all application into one MSIX each independently, can the applications still start each other from within the code?

Q2: When we package all applications into one MSIX, can we "turn off" (hide from the start menu) applications a specific user should not be able to use?

Q3: Would it be better to package the admin and the config app as an optional package to the main application and if yes, can an optional package still have a start menu entry? (if I read this article right, I think the answer is 'no' https://techcommunity.microsoft.com/t5/windows-dev-appconsult/supporting-a-modular-windows-applicati...)

Q4: Our protocol handler command is registered to "C:\Program Files\...\ourhandler.exe". How would that have to change in order to find the new install location?

Q5: When we package the OpenJDK as a depencendy with our main application, are we able to call it from there?

Sorry if these might be trivial questions for some of you, but we are just starting. Any help appreciated, also links to good further reading. We might just not have found the right spots in the MSIX Docs.

[#2]

@JoeHae365  You'll probably get a better answer from someone at Microsoft, but here are a few thoughts...

Currently, Microsoft does not have a way for two separate independent MSIX packages to work together in the same container that is similar to the App-V Connection Group, although there have been hints that there may someday be that support.

MSIX does have the ability today for limited plug-in like packages, called dependent packages in some areas but known as Modification packages in the MSIX Packaging Tool.  These secondary packages cannot have shortcuts, so I'm not sure they work like you want.

Looking at the documentation you pointed to, you could probably change your approach to meet your needs, by implementing a single shortcut for the end user, and embedding access to restricted functionality by the presence of an add-in.  So everyone gets the main app, but only those users requiring the additional functionality having the extra package applied. 

Since you already are supporting plug-ins for other purposes, this might not be too hard. If you create a new "admin" plugin, it could be as simple as a button that launches a new process; you can even probably just use the admin exe as a file in that plugin msix package.  The key here is just in eliminating the extra shortcut and using the existence of the admin plugin package to provide access.

As to Protocol handlers, those seem to be working, but you'll have to test yours to be sure.