Apr 13 2020 08:09 AM
Apr 13 2020 08:09 AM
I have built an MSIX package for installing DB2 Connect. It is a complex install, that requires configuration file execution, manual license activation and a registry merge post install of the App itself. I was able (after numerous attempts) to get this install working using powershell execution. It installs cleanly on the Hyper-V I built it on and all post install steps clearly worked before I close the installer and generate the package. The package installs without error on a test machine, but the post-install pieces are not there, when checked. There are no errors in the log. The Windows App Certification Kit will not open MSIX files. Any help or suggestions are appreciated.
Apr 17 2020 02:37 AM
Where are these 'post install pieces'? If they are config files under %APPDATA% for example, they get captured by the MSIX Packaging Tool, but the MSIX runtime redirects app requests for appdata to a different location. Use the PSF to work around this, I recommend PsfTooling or try to capture using Advanced Installer.
Apr 21 2020 10:45 AM
I appreciate the reply. While that tool is helpful to know about, it does not help in my situation. I have reached out directly to someone I know on the Microsoft MSIX Team.
Apr 21 2020 02:06 PM
Hi @David Hed,
Could you clarify what you mean when you say the post install pieces are not there? Do you mean they are not in the package at all, or do you mean they are in the package but don't have any effect when you install it? You can check this by opening the package for editing in the MSIX Packaging Tool and looking for the files and registry keys added post install.
If the post install pieces are not in the package, please double check the settings in the packaging tool to make sure they are not in the exclusions list.
If they are in the package but don't have the expected effect when installed, please make sure they are in a location that is merged with the filesystem or registry at runtime. You can see a list of supported locations at https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes
If the post install involves creating file type associations or services or any other registration like that, it should be translated to an entry in your app's manifest. If it is not being translated, please let us know what information is missing so that we can investigate.
Apr 22 2020 12:06 PM
I have verified that all pieces are in the package. The part that is not coming through are the registry entries. The entries are in the Virtual Registry in the package. I have set the package to run with elevated privileges.
Apr 22 2020 12:35 PM
Where in the registry are the entries that are not coming through? Only keys under HKLM\Software are read from the package; keys under HKCU or other parts of the registry are not.
Apr 22 2020 12:39 PM
One set is under HKLM\Software. The other is under HKCU\Software. Neither are coming through. They are ODBC definitions.
Apr 23 2020 12:59 AM
@David Hed How are you verifying the registry entries are not being seen in the container? Have you tried to open regedit and/or odbcad32 inside the package (e.g. by using Hover)?
Apr 23 2020 05:12 AM
I do see the registry entries in the package. When I run the package on a test machine, I don't see the entries there (check using regedit).
Apr 23 2020 06:12 AM
Here are screen captures of the Virtual Registry in the package and what the registry on the machine I install the package on after installation.
Apr 23 2020 01:00 PM
@David Hed How did you launch RegEdit? (as I don't see you have Powershell or any other tools open)
If you launch it normally, it won't be able to see any of the registry entries, that is expected behaviour. To launch a local exe like regedit inside the container, you would need to enable developer mode and then use the Invoke-CommandInDesktopPackage command, or a 3rd party tool like Hover, MSIX Hero or MSIX Commander.
Apr 23 2020 01:32 PM
To reiterate what Dan Gough already said, it is expected that you do not see the registry keys from your package when you run Regedit normally. Packaged apps run inside a container and you will only be able to see the keys from inside the app's container.
To see what the registry looks like for your app, you would need to launch Regedit inside the container. You can do "Invoke-CommandInDesktopPackage -PackageFamilyName <your package's family name> -Command regedit.exe", or use one of the tools Dan suggested. You should see the expected keys under HKLM\Software\ODBC.
I'm not familiar with ODBC, but if what reads the registry keys is outside of your package, it will not be able to see the keys in it. To see them it would have to be inside the container.
Apr 24 2020 06:14 AM
The whole App is created within powershell. I use the invoke-(cmd) for regedit with an argument pointing to a .reg file I created with the needed entries (exported from a clean machine with the App fully installed manually).
Apr 24 2020 10:29 AM
@David Hed et al,
Any time their is doubt as to if a process is running inside or outside of the container, looking at the Job details help. The container is implement using a Job Object, and when a process like ps or regedit jumps out of the container it won't have one. May be seen as a hidden column of Task Manager or in the process properties when using ProcessExplorer.
Apr 24 2020 07:36 PM
I assume what you say about how you call regedit is about the Powershell script you use for installing the application?
After you create the MSIX package and install it, how are you launching Regedit to see the changes to the registry? The keys from HKLM\Software\ODBC should be present if you view the registry from inside the packaged app's container.
Apr 27 2020 07:53 AM
Tried using CommandInDesktopPackage from powershell. Error attached.
Installed MSIX Commander and ran. Error attached.
I assume my methodology is not working. I copy a folder called DB2 to the Desktop of my Hyper-V I use building packages. When I create the package, I launch Powershell ISE and run the commands below. Can you suggest a better way to accomplish what I'm trying to do?
Start-Process -FilePath "C:\Users\Dave\Desktop\DB2\setup.exe" # *Installs the App
Copy-Item -Path "\Users\Dave\Desktop\DB2\db2consv_zs.lic" -Destination "C:\Program Files\ibm\SQLLIB\BIN\db2consv_zs.lic" *Copies license file
Start-Process -FilePath "C:\Program Files\ibm\SQLLIB\BIN\db2licm.exe" -ArgumentList '-a db2consv_zs.lic' *Activates license
Start-Process -FilePath "C:\Windows\regedit.exe" -ArgumentList "/s C:\Users\Dave\Desktop\DB2\systemodbc.reg" # *Install System ODBC connections
Start-Process -FilePath "C:\Windows\regedit.exe" -ArgumentList "/s C:\Users\Dave\Desktop\DB2\userodbc.reg" # *Install User ODBC connections
Apr 27 2020 09:25 AM
@David Hed Perhaps do the following to help us understand:
Apr 27 2020 10:32 AM
Machine is in developer mode. App did not generate a Manifest file. Recreated package, again no Manifest file. Have attached log.
Apr 27 2020 02:40 PM
I couldn't see any attached logs. Could you double check?
The manifest file is inside the package. You can view it by unpacking your .msix, e.g. by using the Package editor in the MSIX Packaging Tool, or using any zip extraction utility. If you unpack the .msix, the file name will be AppxManifest.xml.
You can also find the manifest generated by the MSIX Packaging Tool in its logs folder. It will be a file with a .Manifest extension.
The way you are installing and packaging your application seems correct to me overall. I think to solve your problem we need to focus more on what happens after you install the .msix and run it.
Could you try Invoke-CommandInDesktopPackage or MSIX Commander again, if possible in a different machine?
Apr 27 2020 03:49 PM
I have tried Invoke-CommandInDesktopPackage on 3 machines. I have tried MSIX Commander on 2.
Still cannot locate an appmanifest.xml file when unpacking the package. I have attached copies of 2 .manifest files from the Log folder.