SOLVED

MSIX - FTA and Dependency handling

Brass Contributor

Hi,

2 quick questions:

 

  • Does MSIX support multiple FTA? Example, if my application derives FTA for 2 file types via 2 different executable (.exe), does this work with MSIX? I believe it does not support FTA for apps that derives it from a .dll file instead of .exe file.
  • If I have 2 or more apps that depend on each other, how can I deploy them as separate packages but ensure they are able to use each other's resource. In case of App-V, we could achieve this via Connection Group. How can we achieve this in case of MSIX packages

Thank You!

6 Replies
best response confirmed by DS2803 (Brass Contributor)
Solution

@DS2803 Some possible answers.

1) An application may have more than one FTA.

2) Support for Shell Extensions (FTA items under ShellEx that point to dlls to be loaded by the windows shell "windows explorer" process) is sketchy at present.  Some types work and some don't.  I'm unaware of a published list, but context menus are the most popular type and they seem OK.

3) The equivalent of the App-V Connection group has been discussed as a possible (likely?) future for MSIX.  Of course it has to have a different name when it comes out.  There is a also a different concept called the Modification package.  A modification package depends on a primary package and may contain files and registry, but no outward publishing extensions like shortcuts/FTAs/Protocol Handlers.

@TIMOTHY MANGAN Thank you for your response Tim.  Notepad++ which derives it FTA via .dll file seems to be one of those apps.

 

Yeah something similar to connection group should be there for MSIX as well. Thank you for shedding some light on which type of apps are ideal to be created as optional packages via Modification package approach.

@DS2803 Modification packages seem good as:

  • a way to separate out app configuration files/registry settings from the primary package. Thus allowing one package with multiple configurations, but each used by different users.
  •  a way to separate out app plugins (dlls often registered by file location of registry). This allows for many plugins to be package separately with any combination desired delivered to a given user.

 

When it comes to files, Modification packages (currently) require VFS pathing to be used for the overlay to work. So you don't tell the packaging tool where notepad++ is going to be installed so that all files are VFS'd.  Due to an implementation oversite, this overlay does not work on operating systems prior to 1904.

Hi @DS2803,

 

Another option you can look at for sharing resources between two applications deployed as separate packages is packaging them as a related set.

 

You can find more details here:

 

Cheers,

Tanaka

 

@TIMOTHY MANGAN Thank You for your reply Tim. Noticed something strange though... If my main package is removed, the optional packages related to them also gets removed. Is this expected?

I see within the manifest.xml of the optional package, I have the name of the main package as reference. If I build the next version of the main package with the same Name (Not referring to the display name here), my optional package should auto link with that. 

With optional package getting auto-removed when main package is removed, it will mean I have to install optional package everytime alongside main package, which kind of beats the purpose of optional package.

 

Any thoughts?

@DS2803 Yes, removal of main package automatically removed the optional packages.

 

However, if you upgrade the main package, the optional packages stay even though the old version is removed as part of that process.

1 best response

Accepted Solutions
best response confirmed by DS2803 (Brass Contributor)
Solution

@DS2803 Some possible answers.

1) An application may have more than one FTA.

2) Support for Shell Extensions (FTA items under ShellEx that point to dlls to be loaded by the windows shell "windows explorer" process) is sketchy at present.  Some types work and some don't.  I'm unaware of a published list, but context menus are the most popular type and they seem OK.

3) The equivalent of the App-V Connection group has been discussed as a possible (likely?) future for MSIX.  Of course it has to have a different name when it comes out.  There is a also a different concept called the Modification package.  A modification package depends on a primary package and may contain files and registry, but no outward publishing extensions like shortcuts/FTAs/Protocol Handlers.

View solution in original post