Your comments

Seriously, can this please be re-implemented and released. It is extrodinary that absolutely nothing has actually been done in over 2 years other than bouncing around the status of this 'feature request' that is technically a bug fix.


'Considering for future release' really isn't good enough as this is functionality that existed and worked in version 5.4 but was removed. It should not be hard to implement an app.config setting to allow the pre V5.5 behaviour enabling it to work in enterprise and locked down scenarios again.


Please get this pushed through rather than procrastinating on it.

Can this please be escalated so that a fix for this issue can be implemented into the next release.


It is still an ongoing issue that frankly should have been fixed long ago. I cannot see any technical reason why it could not be easily implemented with two app.config settings so that we can modify the default save location (away from the user's Document folder) and whether to clean up the folder on exit or not.


It is really tedious having to copy/paste files into a session because the toolbox logic is broken.

We just hit this issue upgrading from version 5.4 to 5.6. We are having issues when logged in as a locked down user (documents directory is not writeable) but mostly when user documents are redirected to a UNC path (causes issues with some scripts and also issues with standard user accounts elevating a tool to admin [the admin user cannot acess the user's documents directory]. Also it is annoying having to redownload a tool when switching users on the PC you are remote controlling (as each user cannot access the other user's documents).


Previously we had toolbox items going to C:\temp\support which worked great and I wrongly assumed that the 'FilesDirectory' setting in the App.Config would still override this 'new' methodology. To me this is a bug [FilesDirectory should override this still] but support fobbed it off stating it as a 'feature' and to post as a feature request here.


I would lile to see two new App.config options introduced - one to set the path of the toolbox items (or to follow the existing FilesDirectory setting like it used to) and another to enable or disable the automatic deletion of the tool after being run and closed. I see no reason programmatically why this could not be easily and quickly introduced to fix these issues.