We use the stats package SPSS through App-V however although it allows use of custom dialogs and macros, these must be placed in a sub folder within the app installation and so this means that users cannot add new macros.
Is it possible to have an App-V package include a symbolically linked folder to point to a different place so that this remote folder could be updated easily without necessitating a rebuild and redeployment of the package?
Thanks
I had a similar problem with another application. We are presenting ours via RDS and RemoteApps. Ended up creating a duplicate folder structure on the root OS C:\folder of the App-V client system. Only the folders! The used a symbolic link on one of the sub-folders to the share location where the updated files were being kept.
I sequenced the App-V package C:\folder. In VFS I merged the folder structures. Since the local folder was an symbolic link to the location where the files were updated/new the app-v package saw the files.
You can deploy the mklink via computer startup script since it runs with system account privs.
On App-V 4.6 SP2 the sequencer "goes haywire" then crashes when I tried to create a file and folder symlink in an application directory. So I think it's fairly safe to say this doesn't work.
Side note: users can modify sub folders within the apps, subject to normal NTFS permissions. They can't navigate to those folders from outside the application, but I've used the "Open" dialog of an application more than once to modify the files within the application's folder structure. Also, these changes are saved to a separate store from the cached sft.
Using App-V 5.x you should be able to achieve this by doing the following:
The virtualized app should then "see" a merge of the "macro folder" that contains both what's in the virtualized and local filesystem folder.
You might want to look at this Q&A to help you achieve the behavior you're looking for.
SPSS_CDIALOGS_PATH sounds like the best avenue. It sounds to me like @user765827 is on the money here.
You could also consider re-cutting the package so it looks 'externally' for these files and deploy them in a managed fashion.
If they're just 'flat' data and it's a simple copy job, most deployment tools ought to handle it. You could just about have a GPO preference script run on startup as this avoids elevating (or on login if you ACL the path).