Pros and Cons of Shared Compilers in Win SDK and VS2008

  • Article

 

About the shared compilers in the Windows SDK

The compiler installed with Windows SDK for Windows Server 2008 support vertical integration with the all other VS SKUs that install the compilers. (A 'SKU' or 'Stock Keeping Unit' is an identification assigned to an individual product.)

Vertical integration means that a feature is shared among different SKUs.  The VC compilers feature is common to many VS SKUs.  For example, the compilers can be installed by the Visual Studio Team System SKU, the VC Express SKU, VS Pro SKU, or the Windows SDK.  Vertical integration means that no matter how many SKUs may install a feature, the feature is always installed to the location specified, or defaulted to in the case of the SDK, when the first SKU was installed. 

If you were to install the compilers first from VSTS, and then from the Windows SDK, both sets of compilers would be installed to the same location. In this case, the location would be specified when VSTS was installed, since it was installed first.  The installation of the Windows SDK would overwrite the files installed by the VSTS.  The compilers at the VSTS location on disk would then be shared, or vertically integrated, between the Windows SDK and VSTS.

This is usually a good thing for users with multiple versions of the SDK and Visual Studio installed because it reduces the number of files installed to disk, and simplifies configuration.  However, can also cause the occasional problem, as with the two issues described here.

Problem #1: Installing Windows SDK after installing VS 2008 breaks VS command line build environment

If you install the Windows SDK for Windows Server 2008 and .NET Framework after installing Visual Studio 2008, you'll likely have problems using command like CSC, VBC, and MSBUILD.  VCbuild will likely still work, and the Visual Studio IDE works fine.

So what's going on?  The culprit is the VC++ compilers that install with the Windows SDK.  When the SDK is installed after VS, this compiler package improperly overwrites the file %\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat, pointing to a bad FrameworkDir location, and not specifying a .NET Framework version.  (This is a bug, will be fixed in the next SDK release.)

The best and easiest way to repair the VS 2008 command line build environment is to edit the file VCvars32.bat manually. Only a few lines need to be changed. Here's how:

1.  Close all instances of Visual Studio:

2.  Use Notepad or your favorite editor to change the file %\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat.  You'll need to change the top few lines where the variables are set, to set the correct path to the FrameworkDir.

Change these lines:

@SET VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0
@SET VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 9.0\VC
@SET FrameworkDir=Framework32
@SET FrameworkVersion=v2.0.50727

@if "%VSINSTALLDIR%"=="" goto error_no_VSINSTALLDIR
@if "%VCINSTALLDIR%"=="" goto error_no_VCINSTALLDIR

to this:

@SET VSINSTALLDIR=c:\Program Files\Microsoft Visual Studio 9.0
@SET VCINSTALLDIR=c:\Program Files\Microsoft Visual Studio 9.0\VC
@SET FrameworkDir=c:\Windows\Microsoft.NET\Framework
@SET FrameworkVersion=v2.0.50727
@SET Framework35Version=v3.5

@if "%VSINSTALLDIR%"=="" goto error_no_VSINSTALLDIR
@if "%VCINSTALLDIR%"=="" goto error_no_VCINSTALLDIR

Now open the VS command line build environment and verify that you can build successfully.

Problem #2: VS2008 overwrites Windows 64-bit compilers

Another rarely noticed issue with sharing compiler components happens on 64-bit computers when Visual Studio 2008 is installed after the Windows SDK for Windows Server 2008 and .NET Framework 3.5.   In this case, Visual Studio 2008overwrites the files ADM64.VCPlatform.config and Itanium.VCPlatform.config. This will cause the SDK build environment will use the 64-bit cross compilers instead the 64-bit native compilers.  A user will likely not even notice the difference, because the desired 64-bit application is created without errors. 

Visual Studio 2008 overwrites the files ADM64.VCPlatform.config and Itaniumn.VCPlatform.config that are installed by the Windows SDK. The SDK versions of the config files point to the native compilers. The Visual Studio 2008 config file points to the cross compilers.

When using the Windows SDK, the native compilers are, by design, the primary compiler used on any given computer, and the cross compilers are installed on all three platforms so you can create an application to support any platform architecture (X86, X64 or IA64).  With Visual Studio (Retail SKUs), the primary compiler used to build 64-bit applications is, by design, the cross compilers.  Using the native X64 compiler in VS requires customization, and installing VS 2008 on IA64 is not supported.

If VS 2008 has overwritten the Windows SDK and switched your build environment to the corss-compilers, you can switch back to the native 64-bit compilers fairly easily:

On an x64 computer, modify the file c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\AMD64.VCPlatform.config.

Replace:

Path="$(VCInstallDir)bin\x86_amd64;$(VCInstallDir)bin;$(WindowsSdkDir)\bin;$(VSInstallDir)Common7\Tools\bin;$(VSInstallDir)Common7\tools;$(VSInstallDir)Common7\ide;$(ProgramFiles)\HTML Help Workshop;$(FrameworkSDKDir)bin;$(FrameworkSDKDir)lib\win64;$(FrameworkDir)$(FrameworkVersion);$(FxCopDir);$(PATH)"

With:

Path="$(VCInstallDir)bin\amd64;$(VCInstallDir)bin;$(WindowsSdkDir)\bin;$(VSInstallDir)Common7\Tools\bin;$(VSInstallDir)Common7\tools;$(VSInstallDir)Common7\ide;$(ProgramFiles)\HTML Help Workshop;$(FrameworkSDKDir)bin;$(FrameworkSDKDir)lib\win64;$(FrameworkDir)$(FrameworkVersion);$(FxCopDir);$(PATH)"

On an IA64 computer, modify file c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\ia64\Itanium.VCPlatform.config.

Replace:

Path="$(VCInstallDir)bin\x86_ia64;$(VCInstallDir)bin;$(WindowsSdkDir)\bin;$(VSInstallDir)Common7\Tools\bin;$(VSInstallDir)Common7\tools;$(VSInstallDir)Common7\ide;$(ProgramFiles)\HTML Help Workshop;$(FrameworkSDKDir)bin;$(FrameworkSDKDir)lib\win64;$(FrameworkDir)$(FrameworkVersion);$(FxCopDir);$(PATH)"

With:

Path="$(VCInstallDir)bin\ia64;$(VCInstallDir)bin;$(WindowsSdkDir)\bin;$(VSInstallDir)Common7\Tools\bin;$(VSInstallDir)Common7\tools;$(VSInstallDir)Common7\ide;$(ProgramFiles)\HTML Help Workshop;$(FrameworkSDKDir)bin;$(FrameworkSDKDir)lib\win64;$(FrameworkDir)$(FrameworkVersion);$(FxCopDir);$(PATH)"

Uninstalling shared compilers

Uninstalling shared components like the VC compilers requires a little extra thought.  When you uninstall the Windows SDK, most of the SDK will be uninstalled automatically. However, a few components (like the compilers, FxCop and the MS Document Explorer) will need to be uninstalled separately. This is so that you don't break another application that depends on those shared components.  If the shared compilers were uninstalled automatically when you uninstalled an SDK, any Visual Studio SKUs depending on those compilers would be broken.  Read more about this in my blog post, Uninstalling SDK components.

Late breaking issues

Up-to-date Release Notes that discuss issues found after the SDK shipped are available on the MSDN Windows SDK Development Center.