I’d love to say this was my idea, but this was all Oren Werker – props to you for asking for what we didn’t know we needed!
What to do when you have App-V 5 (sp1) and want to deliver ActiveX controls for poorly built websites?
You sure don’t want to install them natively and have to deal with conflicting .DLLs! (Its not like we had a view of all that the business was using, so we containerised by default)
We found that one doesn’t have to use a common published ‘extension point’ to instantiate an appv. Additionally, one doesn’t have to publish a shortcut that refers to one if the main ApplicationIDs in the appv XML…
Any EXE in the integration root or package root is launched ‘in the bubbles context’ (the caveat here is, of course, unless it’s from another appv – no spelunkers allowed!)
So what’s to do? Build an .EXE that takes arguments and promptly runs them of course!
I bodged an AHK that does just that, RunIE.EXE would take any URL and throw it at IE9 (the natively installed browser). If we chuck this .EXE in an appv with any old JRE or crystal reports .DLLs, it’ll load and render approximately. This kept the process in its own sandbox and allowed users to run many conflicting JRE’s as required.
No app silo based on the 1.6 JRE any more!
This eventually grew, we wanted a RunEXE.EXE as well (great for access databases needing horrible old runtimes).
These tools soon merged together and a bitmask argument was added for window handling (hidden, minimised etc) or IE in ‘app mode’ (with no address or toolbars).
Turned out to be a great tool, crucial to the delivery of many horrible old systems and applications the businesses were stuck on.
I’ll post the code, but with some experimentation in AHK or AU3, one should be able to emulate this…
We would often hold launch scripts on remote drives that the .EXE would call. PowerShell swapping .INI files onto the PVAD and all sorts.
Get creative, what could go wrong? (We were already in a hospital…)