How to run Client Server application with MSIX

Copper Contributor

I am trying to make an MSIX run with a client/server application. Why, we want to run multiple versions with different network  share next to each other. They use the same registrykeys and therefor we want to use MSIX. The application runs from a networkshare and arranges the connect/actions to a SQL database and license. Locally on the pc only HKLM, HKCU registrykeys and a shortcut to the exe on the share are needed to run the application. The MSIX contains the registrykeys and I added the PSFLauncher32.exe with Config.json to the MSIX where the config.json is pointing to the \\share\folder\subfolder\application.exe. I can see the exe from the share launching but it seems that the legacy exe starting has no access to the virtual registry of the MSIX. This seems logical maybe but in this case it is not what I want. Anybody here with experience or knowhow to handle this?

11 Replies

Hi Rudi,

Thanks for reaching out, can you please clarify your scenario. What are you trying to achieve? Why do you need the .exe to be on a network share and not inside the MSIX package? You can create a separate MSIX package for each version and run them in parallel. 

 

Regards,

Vlad

 

Hi Vlad,

 

Sorry for the late response but I had an issue with signing on from our company.

The application is installed according to the supplier’s rules. Which means that the main application is on a network share folder like \\server\share\applicationfolder. This contains a small client installation which only installs a few dll’s, fonts, shortcuts to the server-side exe’s and registrykeys on the client machine.

The exe file is on the server share and moving this to the client side is no option because of the way it works (multiuser, locking) and support from the vendor. For different departments in our company we have a few different versions running from different shares. And there are also a few people that need both versions. Now we have a switch mechanism for these people to adjust the registry each time.

What do I want to achieve. Create an MSIX that installs the client side so we can run them parallel. This part is clear and no problem to achieve that.

But the fact that the server-side exe is outside the container means it has no access to the registry and files in the container. And my guess is that there is no solution for at the moment. At least I can’t find it. I need a way to give the exe outside the container access to the registry/files in the container.

 

Kind Regards,

Rudi

Hi Rudi,

 

Thanks for the details, few more clarification please;

Do you know how the .exe on share is launched from the client application? (e.g. CreateProcess)

Do you have the code for the application or have an ability to change it? (I know typically the code is not available but I want to make sure here)

 

Thanks again,

Vlad

Hi Vlad,

 

I do not have the code since it is a third party product we use. The exe on the share is started with a simple shortcut that is locally on the pc. I put the shortcut into the MSIX file.

Maybe it makes sense that an external exe has no access to the containers registry or files in terms of security.

 

/Rudi

Hi Rudi,

 

Thanks for clarifying, we don't support it via a shortcut today, can you please share how do you run the shortcut from within the MSIX package?

As an FYI - We do support running an .exe from outside the package within the container via CreateProcessAsUser function via the PROC_THREAD_ATTRIBUTE_DESKTOP_APP_POLICY attribute but it is more of a developer scenario - https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880(v=vs.85).aspx 

 

Vlad

Hi Vlad,

 

The shortcut is launched by the user and points directly to the exe on the fileshare like "\\server\share\folder\subfolder\runthis.exe". I read the developer info but think that is a bit to far for us. Also I am not fond of using all kind of custom things. If things change which will be the case with MSIX it might not work anymore. I think the conclusion for now is that this is not suitable yet to use in an enterprise environment.

Or am I wrong?

Yes, you are right, we don't support this scenario yet. I will capture it.
One more clarification please, how the user finds the shortcut if you deploy it with the MSIX package (it will be under the WindowsApps folder that a regular user don't have permissions for)? Are you coping it to the desktop when the app starts?

Thanks,
Vlad

Hi Vlad,

 

I forgot to say that for the shortcut I use a man in the middle exe made by Winbatch compiler. It only contains the exepath and wortking folder and runs that. So the shortcut points towards an exe local in the container and that exe starts the exe on the share.

That is how I got the shortcut.

Hi Rudi,

Did you create the shortcut outside the MSIX package on the desktop? (Otherwise if it is inside the MSIX package the user won't have access to it). Also, to point to the man in the middle .exe inside the MSIX package you have to create an appExecutionAlias for the application and set it is the Targetpath in the shortcut - https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#elements-a...

Thanks,
Vlad

@RRobesin have you tried PSFLauncher64.exe?

@Dan Gough PsfLauncher (currently) would use the standard process launcher causing the exe to run outside of the container and not see the needed registry settings.

 

Vlad's note opens the possibility that in the future we could add a PsfLauncher option in the config.json to allow support for this scenario.  I might look into adding it to the Psf over the summer, but I'd first have to verify that it does not require developer mode (which is the problem with the PowerShell command to launch inside the container).