This has to be a common problem, but the discussion topics are not quite the same scenarios. I must be using the wrong search terms to search by in the forums.
First, the issue in simple terms.. and then greater detail: I'm having an issue where a very simple app is created, but if the app is re-built with only a couple of changes, not all files in the "existing" users's Sandbox will be updated to reflect the change. Meaning, if I maintain the same Sandbox path, and it is reused on the updated app, the sandbox will sometimes continue to use the old files from the prior build.
Example: Let's say the package consists of...
ThinApp_Package.exe (living in \\networkshare\AppHome)
App.exe (original)
xxx.dll
yyy.dll
user_settings.ini
another_config.ini (original)
SandboxPath=D:\SandboxFolder\
SandboxName=App-Saved-Files (Sandbox shows the original files above just fine)
Now, if our developer creates a new "app.exe" and it uses a new statement to Read/Write in the "config.ini", I will recompile the app with those two files updated.
- When the new ThinApp package is launched, the new binary "App.exe" will be correct, but the "config.ini" that is being referenced is the OLD, prior file that exists in the Sandbox. The Sandbox never updates it.
- If I delete the Sandbox, it will be recreated with the new and proper "config.ini" (but, of course all other custom settings for that user is lost).
Rebuilt_and_Updated_ThinApp_Package.exe (living in \\networkshare\AppHome)
App.exe (updated)
xxx.dll
yyy.dll
user_settings.ini
another_config.ini (updated)
SandboxPath=D:\SandboxFolder\
SandboxName=App-Saved-Files
(The updated"App.exe" runs fine and as expected, but continues to refer to the original"another_config.ini" in the Sandbox from the prior build and does not update... so I have no choice but to delete the Sandbox and lose the users settings)
More details: If this is not a common, simple issue (which, I'm sure it is, and I'm overlooking something... I'm not too skilled with ThinApp).
- The App is centrally hosted on a network share (has run this way since Thinstall days), I don't recall the issue before, so I must be triggering it somehow.
- The overall age of the sandbox is not that old. I can recreate the issue starting with a new Sandbox and then updating the package once.
- The Sandbox is a forced path to the Local User's D_Drive, in a common accessible area for all.
- The Package is WRITECOPY, except for the one sub-folder where the EXE and INI exist, that one folder is FULL (This is due to the App needing to be on the C: drive, but the current company Administrative rules won't allow writing to the C: Drive.
- It is an older 32bit, Visual Basic compiled app, running on Windows 7 (64bit).
- Just as a quick test I have asked the developer to always write a new "config.ini" that creates a time entry on launch, so that the file is forced to be changed (thinking a forced change in the file should force it to the sandbox... but that has no affect, it still does not update the sandbox.
We have several, similar programs of that hosted in the same manner.. and have for years. But, it appears that this one is giving me a hassle and I cannot pinpoint the change that causes this behavior.
So, I guess a general question is, "What is the decision process within ThinApp that would direct the application to view Sandbox Content over -internal- compiled content if the internal content is newer or different size?" The only common thing between the compiled content and sandbox content is the file name.
Thanks for helping an amateur.