Forum Discussion
Bad experience with app container virtualization and workarounds
Hi MikeH
Yeah, the MSI package is built with Advanced Installer. You can build a similar package with the freeware edition and use it for as long as you want. This isn't a separate download, it's the same full version, the freeware features are included in the Simple project.
We've built a lightweight MSI because admins using the tool were asking us to provide something with the smallest footprint possible. Some even asked us for a ZIP because they don't want to use additional tools on their packaging/testing machines. So, we are testing this "ZIP deployment" for another tool now, the MSIX Troubleshooter, we'll see how this goes.
Of course, we evaluated packaging it as an MSIX but this just wasn't the best option for our users at that time. We will probably re-evaluate it.
For the command line arguments, we use our own launcher. It is a custom version that also integrates the PSF launcher from Microsoft. We had it before PSF was launched so we kept on improving that with what Microsoft released.
For accessing files from inside the package with an external process, like Notepad, we rely on the package support framework. Here is an example where a process from the container launches Notepad and gives it as param the file path from the container. I don't have the details on this implementation as the colleague that worked on it is on vacation.
Re: running inside the container. We don't know anything more than what is documented in the public docs. We don't use any Win32 API.
The only problem/limitation I had with it was that it could not launch explorer.exe inside the container, but in other cases, it usually worked.
Re: The moment I sign it, the app breaks. Have you tested the signed application without packaging it as an MSIX? It is strange for an app to crash just because it is digitally signed. The container, on the other hand, could be a source of headaches. We would all love a better debugging experience and I fully support your feedback to Microsoft, that is why I just added my feedback on the parts where I considered useful.
I've found a workaround for the subprocess/VFS issues. If sub-processes are run in the redirected path then they seem to work properly, or at least cmd.exe does. So that leaves the question of how to know where the redirected path is.
My solution is to, at startup in native code, change the values of the LOCALAPPDATA and APPDATA environment vars (which my app uses) to be the output of SHGetKnownFolderPath with the KF_FLAG_RETURN_FILTER_REDIRECTION_TARGET flag. This returns the path that Windows is redirecting writes to. By using this location directly instead of relying on the redirection, it appears to have fixed my issue. The nice thing about this is, it will automatically work for any program that uses the right environment variables in the process tree.
This preserves the VFS functionality whilst working around whatever bug is breaking things.