We consider using TSF_dotNET.exe instead of TSF_CS.exe from a network share for starting the Windows GUI in a terminal server setup. This way we want to avoid the growth of the App Data folder.
Are there any disadvantages to this idea?
Solved
TSF_dotNET.exe versus TSF_CS.exe
+21- Superhero
Best answer by Mark Jongeling
Internally we release a Short-term supported (STS) version of the SF and IAM, so we can develop, test and release more successfully. However, these STS versions are not released publically, but Ricky needed it for important reasons.
GUI's are backwards compatible down to the last supported platform version, so if you run platform version 2024.3, any GUI from 2024.3.10 to today will work on it.
There are two sets of Extended properties, one from Runtime configurations/Applications, and one set from a Global configuration. Not all extended properties work via this latter method I believe, some only can be an Application extended property.
For 2024.3, leaving the globalconfiguration out of the INI should work.
The disadvantage of running TSF_dotNET.exe directly from a network share is that it will be impossible to replace the Windows GUI's binaries while it is in use by anyone. TSF_CS.exe circumvents this problem by copying the binaries of the Windows GUI to the user's AppData folder before running it from there.
However, the AppData folder should not grow endlessly when using TSF_CS.exe. TSF_CS.exe will always copy the Windows GUI's binaries to a folder with the same name as the folder on the network share. In doing so, it will overwrite the files at the target location, meaning that the size should always remain roughly 300MB. The only reason for the AppData folder to grow endlessly is that the name of folder containing the Windows GUI binaries on the network share is changed every time it is replaced by a new version. The best practice here is to replace the binaries in the folder, rather than deleting the folder and replacing it with a new one.
However, the AppData folder should not grow endlessly when using TSF_CS.exe. TSF_CS.exe will always copy the Windows GUI's binaries to a folder with the same name as the folder on the network share. In doing so, it will overwrite the files at the target location, meaning that the size should always remain roughly 300MB. The only reason for the AppData folder to grow endlessly is that the name of folder containing the Windows GUI binaries on the network share is changed every time it is replaced by a new version. The best practice here is to replace the binaries in the folder, rather than deleting the folder and replacing it with a new one.
+1In such deployment scenarios it's a good idea to use the CachePath extended property. In the latest release (2018.3.18), environment variables such as %USERPROFILE% and %LOCALAPPDATA% are properly resolved.
See also: Extended properties - Thinkwise Docs
See also: Extended properties - Thinkwise Docs
1 person likes this
+21- Superhero
Hi
Do you know if the CachePath extended property can still be used?
We try to make a terminal server setup, without ClickStart, and we want to save the application in a read-only folder and need the Cache data to be saved in a User folder.
I have added a CachePath record in the Extended Properties with a value %LOCALAPPDATA%\Thinkwise\TEST\Cache
For some reason cache data is still saved in the in the application folder. Can you explain this?
Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
1 person likes this
+1Hello Harm,
I have confirmed that CachePath still works, as well as adding placeholders for environment variables to it, such as %LOCALAPPDATA%. If this is not the case, it is best to create a ticket in TCP.
Best regards,
Henk
1 person likes this
+1
globalconfiguration = (default)
If it does, then it confirms a hypothesis of mine as to why this used to work and doesn’t anymore.
+21- Superhero
Hi
Thanks for sorting that out, I will try later this week.
Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
+1Hi Harm,
Yesterday we’ve released a 2025.1 hotfix to fix the issue that default global configurations didn’t load anymore. Since `CachePath` is one of the available properties I assume this will fix it for you as well.
Kind regards,
Henk
+21- Superhero
Goodmorning Henk,
Ok, this means it should work for a 2025.1 setup and all hotfixes are applied?
The customer where this is currently a topic is still on 2024.3 but we upgrade soon.
BR,
Harm
+1Hi Harm, the issue with global configurations I mentioned only occurs in 2025.1, so 2024.3 should still work. If it doesn’t, I don’t think that upgrading to 2025.1 will fix it, since only the default global configuration is affected. Instead, I suggest filing a ticket in TCP because from here I can’t tell what else might be going on.
Henk
+8- Superhero
1 person likes this
+1globalconfiguration = (default) to INI files works as a temporary workaround. Maybe
Kind regards,
Henk
1 person likes this
+23Hi everyone, the change was processed in January and released with the 2024.3.14 STS version. Which means in the 2024.3.14 and 2024.3.15 versions, this error persists. However, these versions are not supported anymore. So in 2024.3 it should work, and in 2025.1 too. If it doesn't, then a ticket is the way to go.
Difference being between 2024.3 and 2025.1, is that in 2025.1 the global configuration ID returned is equal to "(default)”.
Adding globalconfiguration = (default) to INI file should do the job.
As a user, you should not have to add this property in your INI file if you want to use the Default global configuration. Whether or not global_configuration_id is NULL or (default), should not matter from a user perspective.
"Wake me up before you low-code"
+21- Superhero
It confuses me all a little...
What does 2024.3.14 STS stand for?
Is any WindowsGUI 2025.1.XX version compatible with the 2024.3 platform version?
With Extender Properties you mean the one under Global Configurations?
Does the GUI create folders which do not exist yet, when using CachePath?
For example: %LOCALAPPDATA%\Thinkwise Software\Cache\Test
So what would be the best setup now, if the platform version is 2024.3?
Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
+23Internally we release a Short-term supported (STS) version of the SF and IAM, so we can develop, test and release more successfully. However, these STS versions are not released publically, but Ricky needed it for important reasons.
GUI's are backwards compatible down to the last supported platform version, so if you run platform version 2024.3, any GUI from 2024.3.10 to today will work on it.
There are two sets of Extended properties, one from Runtime configurations/Applications, and one set from a Global configuration. Not all extended properties work via this latter method I believe, some only can be an Application extended property.
For 2024.3, leaving the globalconfiguration out of the INI should work.
+21- Superhero
Pfff, finally, clear and it now seems to work :-)
Running WinGUI 20251.1.13 on Platform version 2024.3
globalconfiguration removed from INI
And CachePath set as below
Logic will get you from A to B. Imagination will take you everywhere (Albert Einstein)
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.