## Start all Command Prompts as Visual Studio Developer Command prompt

When developing you often need to use the Command Prompt (cmd.exe) to do something for which there is no easy UI. Visual Studio and Windows SDKs include many CLI applications. It also includes the Visual Studio Command Prompt. This command prompt calls a script that sets all kinds of environment variables so that the CLI apps can be easily started.

Windows provides all kinds of ways to start a Command Prompt: start cmd.exe, Shift+right click a folder, from the File menu in windows 8 etc. But only when the special "Developer Command Prompt" link is used the Command prompt is actually started with the spacial environment.

That makes it very cumbersome to use the Command prompt, because it is easy to open it from all kinds of places, but when you need to use a CLI app from Visual Studio you need to start another Command Prompt and do your stuff again. Especially when starting the Command Prompt as Administrator is not easy, because the path is never correct. I wanted to fix that.

Under the hood the "Developer Command Prompt" starts a batch file that does all the magic:

code:
 1  "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"

Whenever this batch file is called inside a Command Prompt it loads all the environment variables needed. In order to have all Command Prompts do this automatically this batch file needs to be started when cmd.exe is started.

cmd.exe contains a feature named AutoRun. In the registry you can add a key with a reference to a batch file that will be executed for every cmd instance. That's what we want! The Registry key is located here:

code:
 1 2  Path: HKLM\SOFTWARE\Microsoft\Command Processor Key: AutoRun as Reg_SZ / String

I tried puting the VsDevCmd.bat directly in the registry, but this does not work. The batch file starts another instance of cmd, with in turn autoruns the VsDevCmd batch file. This is a never ending loop. So you will need a special batch file that breaks the loop. I have created the following batch file and saved that to my document folder. This batch file is referenced in the registry in the AutoRun key

code: CmdAutoRun.bat
 1 2 3 4 5  @ECHO OFF IF "%VsDevCmdRan%" EQU "1" GOTO :EOF SET VsDevCmdRan=1 "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"

Basically this batch file sets an environment variable when it started to run, each new instance of CMD will check this variable and if it is set it will not rerun VsDevCmd.bat. Set this files full path as the AutoRun-key in the registry, do not forget to add quotes (") around the path. Problem solved!

Now whenever a Command Prompt is started under the hood the VsDevCmd.bat is called and I always have a Developer Command Line. It also works as administrator.

Maybe you might want to start a Command Prompt without the VsDevCmd.bat started. This is possible without changing the Registry. You can run the following command:

code:
 1  cmd.exe /d

The /d-option indicated to suppress the AutoRun configuration.

Happy developing!

Thanks. This is exactly what I always wanted but never knew I wanted. Now I cannot live without it anymore.

What a coincidence...
It's only a few days ago I found out from a colleague about the extra entries in the context menu when using shift + right click in Explorer and I had the same moment:
Beaker wrote on Thursday 23 October 2014 @ 17:36:
Thanks. This is exactly what I always wanted but never knew I wanted. Now I cannot live without it anymore.
So far it has been sufficient, but if I start to experience the issues mentioned above I'll take some time to go through the steps listed to get the same experience.

What have we been doing all this time... windows + R -> cmd -> enter -> CD to right path...

Why haven't they moved on to powershell yet? Why does MS keep working with the command prompt when they have a much more powerfull tool at hand?

why in fucks name are you

> first testing if var exist,
> than set var
> than try and exucte command,

> test if the the proper vulues are loaded (instead of just an interger / random meaning les velue ... for example, in that VS2014.bat file there must be a link like $special parth = so you could for examle do. if isset$supervaluestring goto eof

test to see if the bat can be loaded, than print: welcome to your develorshel ...

if error than print error and exit.

surely ms cmd.exe should support these, i know bash does, and it works superb.

> test if the the proper vulues are loaded (instead of just an interger / random meaning les velue ... for example, in that VS2014.bat file there must be a link like \$special parth =
Yes that would be a nice solution, and the first thing I tried. Unfortunately the first sting the batch file does is call a second batch file, which causes the loop. So there are no variables set to do the test on. Therefore I introduced my own var

Also Batch is still very backward compared to Bash or PowerHell it does not have an isset or similar Nor is there realy a decent way to handle exceptions, other then checking the exit code / %errorlevel% from an executable.

[Comment edited on Thursday 23 October 2014 21:33]

remyblok wrote on Thursday 23 October 2014 @ 21:32:
[...]

Yes that would be a nice solution, and the first thing I tried. Unfortunately the first sting the batch file does is call a second batch file, which causes the loop. So there are no variables set to do the test on. Therefore I introduced my own var

Also Batch is still very backward compared to Bash or PowerHell it does not have an isset or similar Nor is there realy a decent way to handle exceptions, other then checking the exit code / %errorlevel% from an executable.
thnx for you reply in all honesty i havend raally used windows since server 2003, other than win7 on a private pc (But that hardly counts), i couldn't have emagined that
isset and
if require "c:\path\to\script.bat"

are stil no part of cmd.exe, reading this i can only hope for people all over the world that bat and cmd.exe will be permanently and fully replaced by powershell in win10.

well at least you got it to work +1