Forum Discussion
MSIX Shared Package Container for normal user
If would be nice to combine an AppX with a MSIX package as well.
Example: AppX Power BI Desktop and an MSIX package with the middleware for the AppX package, like Oracle, Teradata etc connector drivers for Power BI Desktop
Under App-V we tended to use Connection Groups with middleware. But that is mostly because we were dealing with middleware (like javaws.exe) that might be used by multiple applications and have backwards-compatibility issues with newer versions of the middleware that might be needed by other packaged apps.
Seeing less of this these days, rather than resorting to SPC, I find it possible to package the middleware using an ApplicationAlias inside the middleware package, which works more like the App-V RunVirtual key but has the advantage of being directly part of the Middleware package.
- Hi Tim, was thinking about your ApplicationAlias option. Could you explain more how this will work? Would like to try this out.
I am still searching for a possible replacement for RunVirtual add-ins with msix.An AppExecutionAlias is an application level extension that may be added to an application in an AppXManifest file. When that package is installed, it allows anything that wants to request the shell to launch that name to get the exe to start-up. The exe will start in the context of the container that the aliased command lives in. This is often used to help other software find that exe without having to know the path to it, but the name of the alias doesn't have to match the name of the target exe.
For example, in my TMEditX MSIX package, I have a secondary application called "MSIXDeploy.exe". Originally it was named "TMMsixDeploy.exe", but at one point the name was shortened. So I added an AppExecutionAlias for the application so that a third party tool that called it wouldn't have to be changed. Here is the relevant entry in the AppXManifest file:
<uap5:Extension Category="windows.appExecutionAlias" Executable="MSIXDeploy.exe" EntryPoint="Windows.FullTrustApplication"><uap5:AppExecutionAlias><uap8:ExecutionAlias Alias="TMMSIXDeploy.exe"/></uap5:AppExecutionAlias></uap5:Extension>
This could maybe help when added to the middleware package so that primary packages don't need to know where middleware.exe is, or that it is containerized. I'm not saying this will help your situation, but this is how it might be used. It is only OK for cases where it is OK that the middleware is then run in its separate container from the caller (or SPC in use). So if the middleware must be passed a file, it needs to get the full file path. And if that the primary app tries to be smart and figure out where the middleware is to launch it full path it will probably mess up.By the way, traditional windows apps did this using the "App Paths" key in the Windows Registry (something that doesn't work for MSIX packages), but this is the modern app replacement. App-V supported virtual "App Paths" registrations, but MSIX ignores them in the package.
For an example of the "traditional App Paths" case, just go to a command prompt and type "write". This is a traditional App Paths registered to Wordpad.exe. Just look in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WRITE.EXE
There is a (possibly true) story behind that alias that goes back to the old DOS days when Microsoft and IBM weren't getting along too well and wanted users to switch from IBM Write to their new "notepad.exe" program.TIMOTHY_MANGAN thanks for the nice explaination. But looking at it I could no see a way to get this used for replacing RunVirtual, e.g. add-ins (created MSIX format) started and included in e.g. Word, Excel when those are started.
If Word, Excel was MSIX, then I guess a Modification Package would work. Since then the add-in binaries and the registry key to start the add-in would be merged in the Word, Excel MSIX package.But since that is not the case I guess we have to wait for Microsoft to create a possible solution for it. (If it ever will be there). Up until then I guess we need to install Office add-ins just as local applications. I guess that is the only way I see now.