I have an app where I need to inject an encrypted file into the User Profile Local Settings\Application Data\[AppName] directory. The app will create this file if it doesn't exist but there will be no server connection info (IPs/Ports that are too complicated for a user to enter). To establish a baseline I have a pre-launch script that will copy a baseline file there if it is newer than any existing file. That's working fine. (I did not find a way to get this to work by removing the Local Settings folder from the exclusion list during sequencing. It still didn't add the file to the sequence.)

My question is regarding the Repair operation. Is there a way to issue a command to delete that file in the user profile when a repair is triggered so that the pre-launch script will revert that file in the user profile to the baseline file?

I am also concerned (although to a lesser degree) about how to delete that file should the app be deleted so I don't leave junk behind in the User Profile.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
App-V Client does not offer any extensibility points for triggering custom commands on repair, delete or any other options available in Applications -node, so in that regards you cannot automate file deletion the way you describe. But what I couldn't understood is why you want to delete the file during repair, as your pre-launch script already keeps it up-to-date?

ps, there's actually two different exclusion items in the Sequencer for local appdata so maybe you should have deleted both of those?
Answered 09/27/2011 by: ksaunam
Orange Senior Belt

Please log in to comment
0
The problem is that it isn't a static file. The app updates that file on every use. The pre-launch script will only add a baseline file if it doesn't exist or is older. Once the pre-launch script drops the baseline in the app will start updating it from there, which means connection IPs and ports can become modified or deleted. The idea is that should this happen I'd like a repair to return that file to the baseline and not follow the usual behavior of leaving it because it is newer than the baseline.
Answered 09/28/2011 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
Okay, I got it.

Maybe you could enhance your script so that it writes marker value in the virtual registry after initial deployment of that file. The idea being that if repair is done for package, virtual registry is reset to one from the package so if the script doesn't see the marker value already in the registry it knows to override the file?

This of course requires that your script is run PROTECT="TRUE"..
Answered 09/28/2011 by: ksaunam
Orange Senior Belt

Please log in to comment
Answer this question or Comment on this question for clarity