When updating an existing package, you must consider the existing sandbox. In many situations, you might want to preserve the users' settings and therefore reuse the existing sandbox. Make sure the new version of the package uses the same SandboxName
and SandboxPath
values, and the existing sandbox will be used, that is, if the new version of the virtualized application can handle the settings from the old version of the application. There is not much ThinApp can do if the application cannot handle existing settings. Luckily, most applications can handle previous versions' settings. If the old sandbox contains conflicting elements, your new package must use a new sandbox. Currently, there is no method to update the existing sandbox content with content from the read-only data. A typical example of this behavior is Mozilla Firefox. By simply launching a packaged Mozilla Firefox, the sandbox will be populated with many files. Most of them are settings files.
As you can see in the previous screenshot, the prefs.js file is created in the user's sandbox. pref.js holds many Mozilla Firefox settings. One of the settings is the homepage. You can't enforce a new homepage in a new Mozilla Firefox package. Since prefs.js is already present in the sandbox, the version stored in the package will not be used. There are a couple of different methods you can use as workarounds for this.
%AppData%
. This way, you can use traditional, physical methods to change users' settings.The most important thing is that you are aware of a certain package's behavior. That is why it's so important to investigate the sandbox when you're test running a package. You must know what will end up in the sandbox and investigate if it will be an issue later on when updating.
18.221.111.22