xavier roche's homework

random thoughts and sometimes pieces of code

Fancy Standalone Visual C++ Compiler

A Fancy Standalone Compiler ?

Yes. Many people like me are developing on multiple platforms, including Windows, but do not necessarily work on Windows for their primary platform. Besides, you may log-in on a random Windows machine with a very minimalistic setup (say, a new virtual machine, for example), and do not want to have a full compiler installed. You may also use multiple versions of a compiler (playing with Visual C++ 2008, 2010, 2012, 2013..), and switching between them may become a real burden.

For these many reasons, having a standalone compiler, say, ready-to-use on a network drive, is often a very handy solution.

Can We Do That ?

Technically, using a full Visual C++ install deported on an external location, without actually installing anything, is not really supported (I would say rather untested, though)

Fortunately enough, Visual C++ is nice and well-educated enough to accept being used in a standalone fashion ; at least for the commandline tools, such as cl.exe or link.exe. Yay!

The Recipe

The recipe is almost the same for all Visual C++ releases (tested from 2005 to 2013): blindly copying important directories in a safe place, adjusting some DLL’s. I will describe the rough necessary steps for 2013 and 2010 - you’ll need to adapt a bit to fit your needs, sometimes find a bit in subfolders to catch some DLL’s, but this should not be too cumbersome.

  • Start on a fresh machine. Preferably on a virtual machine, up-to-date (service packs). The machine can be trashed after creating the remote compiler, of course. Having a fresh install is quite handy to spot what has been installed, and to avoid being polluted by external DLL’s (such as external redistributables)

  • Install a regular Visual C++ Express version. Yes, I’m using the Express flavor, as it is simpler to use, and has probably less licensing issues than the “paid” release. You will miss some components, though, such as ATL and MFC (but who use them nowadays ? Err, I may have still some MFC code lying around by the way …)


  • Create a standalone directory with compiler binaries (to be placed later on a network drive, for example, or on an USB key):
    • vssrc is generally something like C:\Program Files (x86)\Microsoft Visual Studio 12.0 or C:\Program Files (x86)\Microsoft Visual Studio 10.0
    • mssdk is generally something like C:\Program Files\Microsoft SDKs\Windows
    • programfiles is generally something like C:\Program Files

Do not forget to install every possible updates, patches, service packs…

Visual C++ 2013

Source Destination
vssrc\VC VC
vssrc\Common7\IDE 10.0\Common7\IDE\{mspdb*.dll} VC\bin\
vssrc\VC\redist\x86\Microsoft.VC120.CRT\*.dll VC\bin\
vssrc\VC\redist\x86\Microsoft.VC120.CRT\*.dll VC\bin\amd64
vssrc\VC\bin\{mspdb*.*} VC\bin\amd64
vssrc\VC\bin\msobj120.dll VC\bin\amd64
programfiles\Microsoft SDKs\Windows\v7.1A\Bin bin
programfiles\Microsoft SDKs\Windows\v7.1A\Include include
programfiles\Microsoft SDKs\Windows\v7.1A\Lib lib
programfiles\MSBuild\12.0\Bin NET\Framework
programfiles\MSBuild\12.0\Bin\amd64 NET\Framework64



Visual C++ 2010

Source Destination
vssrc\VC VC
vssrc\Common7\IDE\msobj100.dll VC\bin\
vssrc\Common7\IDE\mspdb100.dll VC\bin\
vssrc\Common7\IDE\mspdbcore.dll VC\bin\
vssrc\Common7\IDE\mspdbsrv.exe VC\bin\
mssdk\v7.1\Redist\VC..\msvcr100.dll VC\bin\
mssdk\v7.1\Redist\VC..\x64\msvcr100.dll VC\bin\amd64
programfiles\Microsoft SDKs\Windows\v7.1\Bin bin
programfiles\Microsoft SDKs\Windows\v7.1\Include include
programfiles\Microsoft SDKs\Windows\v7.1\Lib lib
C:\Windows\Microsoft.NET\Framework NET\Framework
C:\Windows\Microsoft.NET\Framework64 NET\Framework64


In all cases, you may also want to have Process Explorer and Dependency Walker within the same place, as they are really useful tools for a developer.

Watch out: 64-bit binaries may be placed in different subfolders:

  • x86_x64
  • x64
  • amd64
  • x86_amd64

Yes, Microsoft had some troubles using a single naming scheme for 64-bit :)

After that, you only need to set environment variables to have the 64-bit or 32-bit directories in your PATH in some kind of cmd script ; eg:

@SET VSINSTALLDIR=X:\data\my-standalone-compiler
@SET VCINSTALLDIR=%VSINSTALLDIR%\VC
@SET WindowsSdkDir=%VSINSTALLDIR%\

@set PATH=%VCINSTALLDIR%\BIN\x86_amd64;%VCINSTALLDIR%\BIN;%VSINSTALLDIR%\bin\x64;%PATH%
@set LIB=%VCINSTALLDIR%\LIB\amd64;%VSINSTALLDIR%\LIB\x64
@set INCLUDE=%VCINSTALLDIR%\INCLUDE;%VSINSTALLDIR%\INCLUDE
@set LIBPATH=%VCINSTALLDIR%\LIB\amd64;%VSINSTALLDIR%\LIB\x64

You may deploy Visual C++ redistributables (32-bit or 64-bit) depending on your needs.

After that, you’re done - enjoying the simplicity of having a ready-to-use build setup anywhere.

A last note: I’m not fan of .NET, but apparently some tools will cause you some headache if you are using this solution. You have been warned! :)

TL;DR: Who needs to install a compiler on every machine ?

Comments