Forum Discussion
SajidRavat
Apr 11, 2023Copper Contributor
Isolating JRE within an MSIX container.
I have packaged a legacy version of Java (1.6.27) for a browser application that requires a specific version.
The MSIX package works using Edge in Internet Explorer mode.
However if there is a locally installed version of Java which is a later version, the packaged version no longer works, Edge launches the locally installed Java instead. I have tried using Tim Mangan's JREBlock, but that has not worked either.
Could this be due to MSIX not having merge/override settings that App-V does?
Any ideas?
- Fiza_Azmi
Microsoft
Hi SajidRavat
Please share the JRE packaged application on this thread using the drag and drop feature and we will investigate into it further.
Thanks,
Fiza Azmi
PM, MSIX Team- SajidRavatCopper Contributor
Hi Fiza_Azmi
There is no application. The JRE is required in Edge within a session running in Internet Explorer mode.
- Fiza_Azmi
Microsoft
Hi SajidRavat
Which is the MSIX package in question in this case?
Thanks,
Fiza Azmi
PM, MSIX
- Aniket_Banerjee
Microsoft
There's no such setting or an option to do that yet. However, you can submit this as an idea on MSIX feedback - Microsoft Community Hub.
Meanwhile, if you can share the installer for your app, we can check if there's a workaround available.
- You mis-characterized the cause, but yeah. When looking for the version of Java to use, it enumerates the Classes keys for java (which are version encoded numbers, not "real GUIDS").
Under App-V, we used JREBlock in the capture to cause deletion markers inside the package virtual registry. So the deletion marker was a merge overlay hiding the local value (not override in the traditional App-V sense) but those hide the local registry entries.
The MSIX virtual registry does not have a similar deletion marker strategy in the virtual registry. But there is a new capability available in the AppXManifest file that allows for the specification of deleted registry items there.
At this time there is no automated way to create those entries, and I'm sure that you've seen how many that can be; more than you'd want to manually add (in the hundreds).
Your best option today may be to get rid of the native install of Java. Does it really need to be in the image any more?- SajidRavatCopper ContributorOh that's interesting... Have you an example of using the deletion marker strategy in the AppXManifest? Could try to specifically set the markers for only the version we have installed.
And no, getting rid of Java is a no go at this point for our client.- I did have an idea, but it is more work for YOU. When you packaged Java in App-V you probably used JavaBlock to create the deletion markers in the registry. As I mentioned, Microsoft did not bring along virtual registry deletion markers to MSIX. But it should be possible to create all of the additional CLSID keys for future Java versions, but point them to the Java in your package.
So rather than run JavaBlock with the addkeys option prior to packaging and then run again with the delete keys while packaging, but before you install crusty java version, you do the following:
1) Edit a version of JavaBlock for the add keys case that looks for existing keys and adds future keys with the content you find in your last found key.
2) No pre-package script needed.
3) While packaging, install crusty java first, then run that script to add in the future keys.
As I said, Java should die, so I'm not planning a script update myself. Good luck!