Solved

TSF_dotNET.exe versus TSF_CS.exe

  • 13 March 2019
  • 2 replies
  • 119 views

Userlevel 5
Badge +20
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?
icon

Best answer by Vincent Doppenberg 13 March 2019, 18:03

View original

2 replies

Userlevel 6
Badge +4
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.
Userlevel 2
Badge +1
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

Reply