UPDATE: 2015-07-30 - Works correctly in Windows 10 RTM (10.0.10240) with VS2013 and VS2015.
UPDATE: 2015-06-29 - Added Visual Studio 2015 version to GitHub repo in VS2015 folder.
UPDATE: 2015-04-13 - changed to prevent command window from showing at all - you just need to update your shortcuts to call the .vbs file.
Summary
If you're running Windows 7, 8, 8.1 or 101 and you don't want to disable User Account Control (UAC) - which you shouldn't and quite possibly can't in a corporate environment - then you get an annoying prompt every time you try to run anything as an administrator.
Making sure that a certain application always runs with elevated permissions and doesn't pester you with a UAC prompt is easier said than done. Or it was, until now.
Download the fix from here: https://github.com/TomChantler/Always-Admin-VS, have a look at the files (never just blithely install stuff you have downloaded off the internet) and then install it by right-clicking on install.bat and choosing Run as administrator.
NOTE: If you have any existing shortcuts, you will need to update them manually by making them point to "%ProgramFiles(x86)%\TomSSL\VS2013.vbs".
Whilst this example is specific to running Visual Studio, it can easily be adapted for other applications.
Background
If you use Visual Studio a lot then you probably know that it works best if you Run as administrator, which is most easily accomplished by right-clicking on the icon and choosing that option.
If you're anything like me then it's quite likely you'll keep forgetting to do this so you'll probably right-click on the taskbar icon, then choose Properties -> Shortcut -> Advanced... and tick Run as administrator.
This works quite well, but you are still pestered by the UAC prompt.
Worse still, if you click on any other Visual Studio shortcut - including the solution shortcuts shown when you right-click on the Visual Studio shortcut on your taskbar - it won't run with elevated permissions.
At this point you could locate the devenv.exe executable at %ProgramFiles(x86)%\Microsoft Visual Studio 12.0\Common7\IDE\, right-click and choose Troubleshoot compatibility -> Troubleshoot Program -> This program requires additional permissions and that would be pretty good as it would work when clicking any shortcuts and even on .sln files in Windows Explorer.
But you'd still get the annoying UAC prompt every time you ran Visual Studio.
Absurd as it may seem, a quick search suggests that the only way to run a program with elevated permissions without a UAC prompt is to create a Windows Scheduled Task and run that.
I duly tried that, first calling the shortcut and when that failed running the executable directly from the scheduled task, but was unable to pass any parameters successfully. I tried all of the obvious stuff, but it was as if the parameters being passed were hard-coded at the time of task creation. After a few attempts where it complained that it was unable to find the file %1 and the other errors you might expect I gave up and moved on. In practice this meant that whilst I could run Visual Studio on its own, I couldn't run it by clicking on a solution file.
I wondered if the parameters (in my case just the path of the file I wanted to open) might be picked up if I called a batch file from the scheduled task instead, but had similar results to when I tried to call the .exe directly.
At this point I realised that any solution I came up with might not be very elegant.
Next I decided to try calling a batch file which would set an environment variable, then call a scheduled task which would call another batch file which would read the environment variable and then call the executable, passing the parameter through. It didn't work.
Finally, I came up with something that did work.
A solution
Eventually I ended up associating a batch file with the application. This batch file writes the path of the selected file to disk. Then it calls a scheduled task which calls a different batch file which reads the text file, gets the required file and then calls the application passing this as a parameter. Very convoluted, but it works. Update 2015-04-13: I have wrapped the batch file calls with VBScript to prevent the command window from popping up at all. You can download it here.
How does it work
There are four six files of note:
install.bat
RunVisualStudioAsAdminNoUACPrompt.xml
VS2013.bat
VS2013.vbs
RunVS.bat
RunVS.vbs
Let's have a quick look at what they do.
install.bat
REM By Tom Chantler - https:
mkdir "%ProgramFiles(x86)%\TomSSL"
mkdir "%ProgramData%\TomSSL"
cd %~dp0
copy RunVS.bat "%ProgramFiles(x86)%\TomSSL"
copy RunVS.vbs "%ProgramFiles(x86)%\TomSSL"
copy VS2013.bat "%ProgramFiles(x86)%\TomSSL"
copy VS2013.vbs "%ProgramFiles(x86)%\TomSSL"
schtasks /create /XML "RunVisualStudioAsAdminNoUACPrompt.xml" /TN "Run Visual Studio As Admin - no UAC Prompt"
ftype VisualStudio.Launcher.sln="%SystemRoot%\System32\WScript.exe" "%ProgramFiles(x86)%\TomSSL\VS2013.vbs" "%%1" %%*
ftype VisualStudio.sln.12.0="%SystemRoot%\System32\WScript.exe" "%ProgramFiles(x86)%\TomSSL\VS2013.vbs" "%%1" %%*
pause
The batch files which are used to run the program are stored in %ProgramFiles(x86)%\TomSSL which on my machine translates to C:\Program Files (x86)\TomSSL.
The temporary file used to remember which file you want to open is stored in %ProgramData%\TomSSL which similarly translates to C:\ProgramData\TomSSL for me. It's not appropriate to store files which are in a constant state of flux in the Program Files directory and you can't edit them without elevated privileges in any case. We shouldn't try to subvert that, hence storing the temporary file elsewhere.
install.bat creates these directories, copies the batch files into them, imports the scheduled task and then changes the file associations.
ASSOC and FTYPE
If you want to know which files are associated with which file extensions, open a command prompt and type something like this:
>assoc .sln
.sln=VisualStudio.Launcher.sln
This gives you the association for this file extension.
Next you can see the program which will be used to open files with this association (i.e. with this extension) by doing this:
<code>
>ftype VisualStudio.Launcher.sln
VisualStudio.Launcher.sln="C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv\VSLauncher.exe" "%1"</code>
We are going to change this. Don't actually do this bit; it's all taken care of by the installation file. Note the two % symbols in "%%1"; that's not a typo, we need to escape the % when calling the function from within a batch file.
<code>ftype VisualStudio.Launcher.sln="%SystemRoot%\System32\WScript.exe" "%ProgramFiles(x86)%\TomSSL\VS2013.vbs" "%%1" %%*</code>
When I did this on my Windows 7 machine, everything worked fine. On my Windows 8.1 machine it didn't work. I managed to fix it by adding this extra association:
<code>ftype VisualStudio.sln.12.0="%SystemRoot%\System32\WScript.exe" "%ProgramFiles(x86)%\TomSSL\VS2013.vbs" "%%1" %%*</code>
You will note that we are specifying that WScript.exe should be used to run the the .vbs file, despite the fact that this should not be necessary as an association already exists between WScript.exe and .vbs files. For some reason I needed to do this to make it work on my Windows 8.1 machine.
You can use a combination of ASSOC and FTYPE to assign other filetypes in a similar fashion.
RunVisualStudioAsAdminNoUACPrompt.xml
This is the scheduled task definition which is imported by install.bat. There are lots of examples of scheduled tasks with XML definitions on MSDN.
VS2013.bat
This is the file that is called instead of Visual Studio. It decides whether or not you want to load a file and then saves this information to a temporary file at %ProgramData%\TomSSL\VSFileToOpen.txt. This file either contains NONE or the full path to the file you want to open. Next it calls the scheduled task.
RunVS.bat
This is called by the scheduled task with elevated privileges, but without bugging you about that fact. It examines the temporary file VSFileToOpen.txt and then calls the Visual Studio executable, passing in the file to open if applicable.
VS2013.vbs and RunVS.vbs
These are small VBScript wrapper files which suppress the command window when running their associated batch files. More about that here.
Dim shell,command
command = """%ProgramFiles(x86)%\TomSSL\RunVS.bat"""
set shell = CreateObject("WScript.Shell")
shell.Run command, 0
Conclusion
Running applications with elevated privileges without being prompted by UAC or turning it off altogether is hard. You might be tempted to disable UAC, but you shouldn't do this. The above represents the only way I have found to get round it in all cases. It may not look pretty, but it's easy to install (grab the code here and remember to update any existing shortcuts afterwards), it works and it doesn't compromise the overall security of your system.
