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.

---

In 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

---

Hi ​@Henk Nicolai ,

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?

 

---

Hello 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

---

​@Harm Horstman I’ve done some more analysis on this, and I’m wondering, does it help to put the following line in your INI file:

globalconfiguration = (default)

If it does, then it confirms a hypothesis of mine as to why this used to work and doesn’t anymore.

---

Hi ​@Henk Nicolai ,

Thanks for sorting that out, I will try later this week.

 

---

Hi 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

---

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

---

Hi 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

---

​@Henk Nicolai , ​@Harm Horstman  - I’m not entirely sure that this only occurs in 2025.1, we just switched to 2025.1 and looking at older versions of our (network shared) GUI client directories, I do see cache directories which should not be there. You may want to look at the hotfix code for 2025.1 and compare the code in you 2024.x IAM and draw your conclusions from there.

---

​@Ricky Thanks. I was indeed looking at the 2024.3 IAM database in our archive, but this is only the LTS version. Based on the information I can find I can’t rule out that the issue was introduced in some 2024.3 STS version, but in that case an upgrade to 2025.1 and applying this week’s hotfix will fix it, while adding globalconfiguration = (default) to INI files works as a temporary workaround. Maybe ​@Mark Jongeling ​can improve on my answer?

Kind regards,

Henk

---