Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, November 7, 2018 5:22 PM
Hi all,
We're testing Windows Applocker at my company to prevent users running exes,scripts etc in their c:\users\username profile directory.
Visual Studio 2017 pro is apparently using c:\users\username\appdata\local\temp\ to dump randomly named cmd files and then execute them as part of deployment. So that's directly in opposition to what we're trying to accomplish with Applocker.
To work around this, clearly we'd like to change the output directory VS is using for these cmd files during deployment, and I've searched quite a bit and have not yet found a setting that will allow me to do that. It literally looks like VS is using %TEMP% from the user environment variable.
Does anyone know how to change this?
Thanks
All replies (2)
Wednesday, November 7, 2018 7:26 PM
Users of Visual Studio do not need to be nannied this way. Consider that they can make any executable or script under any writable location, outside of %USERPROFILE%, and run that.
-- pa
Thursday, November 8, 2018 2:52 AM
Hi Peteski,
Welcome to the MSDN forum.
*>> Visual Studio 2017 pro is apparently using c:\users\username\appdata\local\temp\ to dump randomly named cmd files and then execute them as part of deployment. *
Usually, the c:\users\username\appdata\local\temp folder to store some temp cache files, how do you know VS 2017 used it to dump files and works for the deployment? Do you mean the VS 2017 use the temp folder during the VS 2017 installation process?
If you want to change the build output folder of the VS solutions, please check this doc, it defaults under the solution folder.
Best regards.
Sara
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]