Shell menu Related Issues!
I am facing an issue wherein my package installs shell menu items (eg edit with...) to some of the build related progid's such as jpegfile.
These shell menu entries does not appear by our virtualized app. I crosschecked the package, it has all the relevant registry entries and OSD file also lists them. However, in OSD we ave it in progidlist not in fileextension list as it's already present on the build.
i tried merge with local but no luck in getting those menu options locally.
kindly advise.
These shell menu entries does not appear by our virtualized app. I crosschecked the package, it has all the relevant registry entries and OSD file also lists them. However, in OSD we ave it in progidlist not in fileextension list as it's already present on the build.
i tried merge with local but no luck in getting those menu options locally.
kindly advise.
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
pjgeutjens
13 years ago
hey Karjee,
we (my colleagues and myself) have litterally had this exact same discussion here about 30 minutes ago.. Our information tells us this is currently not supported in App-V.
Which kind of sucks since this basically means a whole class of applications (let's call them editors) that are pretty much only ever approached through their shell extensions fall out of scope for virtualisation.
PJ
we (my colleagues and myself) have litterally had this exact same discussion here about 30 minutes ago.. Our information tells us this is currently not supported in App-V.
Which kind of sucks since this basically means a whole class of applications (let's call them editors) that are pretty much only ever approached through their shell extensions fall out of scope for virtualisation.
PJ
Posted by:
Rheuvel
13 years ago
Indeed, this is still not supported, with some pre-defined exceptions.
What you could try however (I've never had the chance to try this), is have the OSD execute a vbscript to install these shell items locally, and tweak them a bit to start the correct OSD instead of the original executable. I have no clue if this will actually work or not, and it might be different for every app.
But to be honest, it sounds kind of cumbersome and it's much easier to just repackage to MSI if the shell extensions are needed.
What you could try however (I've never had the chance to try this), is have the OSD execute a vbscript to install these shell items locally, and tweak them a bit to start the correct OSD instead of the original executable. I have no clue if this will actually work or not, and it might be different for every app.
But to be honest, it sounds kind of cumbersome and it's much easier to just repackage to MSI if the shell extensions are needed.
Posted by:
pjgeutjens
13 years ago
What you could try however (I've never had the chance to try this), is have the OSD execute a vbscript to install these shell items locally, and tweak them a bit to start the correct OSD instead of the original executable. I have no clue if this will actually work or not, and it might be different for every app.
Rowan,
while this is, I believe, definitely an idea that has great merit, and if i EVER have the time for it I will definitely look into it, I think a distinction has to be made between a straight "open with list" type extension that uses the shell/open commands, and a shell extension that uses a custom DLL as an entry point (As is the case for example with Notepad++, the app that drew my attention to the issue). In the second case the 'command line' is just a reference to the DLL's registered class, much less straight forward to replace with another command line...
Still, like I said, if I ever find the time...
PJ
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
