locked
SDK 2008 C++ Compilers refusing to install RRS feed

  • Question

  • I have a computer with the following configuration:

    • Visual Studio 2005 Professional Edition SP1
    • Visual Studio 2008 Professional Edition SP1
    • Microsoft Windows SDK for Windows Server 2008
    • Microsoft Visual C++ 2008 Redistributable x86
    • Microsoft Visual C++ Compilers 2008 Standard Edition

    I need to support both Visual Studio 2005 and 2008 on my machine at the same time - not all projects are 2008 yet and won't be converted in the short term.

     

    What I would like is for both VS 2005 and 2008 to use the "updated" headers, libraries, compilers, and tools from the latest SDK (Server 2008).

     

    Before I installed the SDK, I uninstalled the "Microsoft Visual C++ Compilers 2008 Standard Edition" item from add/remove programs - the same one that was installed along with VS2008. I then installed the SDK, hoping to get the "SDK" version of that component.

     

    The SDK installs successfully, but when I look in add/remove programs "Microsoft Visual C++ 2008 Redistributable x86" has re-appeared. Even after "registering" the SDK with both 2005 and 2008, both compile with the Visual Studio versions of the compilers - VS2005 with it's older version that can crash XP RTM with Manifest issues, and VS2008 with it's nerfed "no /analyze" restriction.

     

    The SDK release notes says that the compiler supports /analyze, but no matter what I do I can't get the SDK to install *it's* version of the compilers - for some mysterious reason it always reinstalls the VS2008 version. This has the effect that:

    • My VS2005 builds break because they no longer have an up to date SDK compiler to use
    • My VS2008 builds can't use /analyze, even though the SDK supports it.

    It's a complete mystery to me why BUYING Visual Studio 2008 gives you LESS features than the free SDK - in this case /analyze. As long as VS2008 is on my machine, /analyze is nerfed! It's insane.

     

    Can anyone shed some light on this situation? How can I force the SDK compilers to install and work with both VS2005 and 2008?

    Friday, October 10, 2008 9:07 PM

Answers

  • Eric, thanks for giving a great explanation of your scenario and problem.  It makes troubleshooting a lot easier.  I understand your scenario – I have the same on my computer.

     

    The compilers installed with Windows SDK for Windows Server 2008 are the same as those installed with VS2008.  Likewise, the compilers that install with the Windows SDK for Windows Vista Update and .NET Framework 3.0 are the same as the Visual Studio 2005 SP1 compilers.  The SDK shares that component with VS, just like the SDK shares the Document Explorer.

     

    The compilers that the SDK installs are installed to the same location that Visual Studio installs them: C:\Program Files\Microsoft Visual Studio 9.0\VC.  The shared compiler package supports vertical integration with the all Visual Studio 2008 SKUs that install the compilers.

     

    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. 

     

    Uninstalling the VS compilers before installing the SDKs won’t change anything.  The SDK will just install the same compilers again. 

     

    The Windows SDK Configuration Tool won’t show the compilers as an “Installed Component.” The only thing this tool is designed to do is to set the version of Windows headers, libs and tools you wish to use in a particular installation of Visual Studio.  The compiler tools are installed with the compiler component to the VS path C:\Program Files\Microsoft Visual Studio 9.0\VC, and are not affected by using the Windows SDK Configuration Tool.

     

    You can learn more about the SDK Configuration Tool in the Windows SDK Blog post Integrating Windows SDK and VS with new SDK Configuration tool, but be warned that the Tool has a couple of very annoying bugs that you’ll need to workaround before it will actually work .  So read How to get the WinSDK Configuration Tool to work before you get too frustrated. 

     

    I don’t have an answer for the problem you’re seeing in the VS 2008 compilers.  I’m not aware of the lack of /analyze support in the VS2008 compilers.  I do know of an /analyze problem with the VS 2005 SP1 compilers.  When the Windows SDK team released the Windows SDK for Windows Vista Update and .NET Framework 3.0, it shipped with the VS2005 SP1 compilers that do not support /analyze.  There’s a note on the download page that explains:

     

    Note: the C++ compilers in this SDK release are the same that shipped with Visual Studio 2005 Service Pack 1, however it does not support the /analyze switch. If you need that capability and do not wish to upgrade to the latest Windows SDK, you can obtain that functionality by installing the C++ compiler from the older Microsoft Windows Software Development Kit for Windows Vista and .NET Framework 3.0 Runtime Components.

     

    That means you’re using the compilers without /analyze support with VS2005.  If you want to get the earlier compilers, you should download the Vista SDK (as opposed to the Vista UPDATE SDK).

     

    I’m sorry for all the frustration you’re feeling and don’t blame you.  I hope this helps a bit.

     

    --Karin

     

    ||Karin Meier||Windows SDK PM||Build Environment.Samples.Community||http://blogs.msdn.com/KarinM||

     

    Sunday, October 12, 2008 6:35 AM

All replies

  • I should also point out that of I go into the Windows SDK Configuration Tool for v6.1, it doesn't show anything listed as "Compilers" under the "Installed Components:" list.

     

    Here's the original sequence of actions:

    • Install Visual Studio 2005
    • Install Visual Studio 2005 SP1
    • Install Visual Studio 2008
    • Install Visual Studio 2008 SP1
    • Uninstall the SDK components that came with 2008 (6.0A)
    • Install 6.1 SDK (Server 2008/.net 3.5). Make sure "Visual C++ Compilers" is checked

    The 6.1 SDK is installed, but the 6.1 SDK compilers are not. The Visual Studio 2008 SP1 compilers are installed, and if I go back into the SDK "change install" dialog, Visual C++ Compilers is grayed out because it has detected the Visual 2008 version.

     

     

    My WiX compiles are now failing in VS2005 because they don't support the additional debug metadata in the LIB files. I need the new compiler, not the VS2008/specific/limited one.

    Friday, October 10, 2008 9:19 PM
  • Eric, thanks for giving a great explanation of your scenario and problem.  It makes troubleshooting a lot easier.  I understand your scenario – I have the same on my computer.

     

    The compilers installed with Windows SDK for Windows Server 2008 are the same as those installed with VS2008.  Likewise, the compilers that install with the Windows SDK for Windows Vista Update and .NET Framework 3.0 are the same as the Visual Studio 2005 SP1 compilers.  The SDK shares that component with VS, just like the SDK shares the Document Explorer.

     

    The compilers that the SDK installs are installed to the same location that Visual Studio installs them: C:\Program Files\Microsoft Visual Studio 9.0\VC.  The shared compiler package supports vertical integration with the all Visual Studio 2008 SKUs that install the compilers.

     

    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. 

     

    Uninstalling the VS compilers before installing the SDKs won’t change anything.  The SDK will just install the same compilers again. 

     

    The Windows SDK Configuration Tool won’t show the compilers as an “Installed Component.” The only thing this tool is designed to do is to set the version of Windows headers, libs and tools you wish to use in a particular installation of Visual Studio.  The compiler tools are installed with the compiler component to the VS path C:\Program Files\Microsoft Visual Studio 9.0\VC, and are not affected by using the Windows SDK Configuration Tool.

     

    You can learn more about the SDK Configuration Tool in the Windows SDK Blog post Integrating Windows SDK and VS with new SDK Configuration tool, but be warned that the Tool has a couple of very annoying bugs that you’ll need to workaround before it will actually work .  So read How to get the WinSDK Configuration Tool to work before you get too frustrated. 

     

    I don’t have an answer for the problem you’re seeing in the VS 2008 compilers.  I’m not aware of the lack of /analyze support in the VS2008 compilers.  I do know of an /analyze problem with the VS 2005 SP1 compilers.  When the Windows SDK team released the Windows SDK for Windows Vista Update and .NET Framework 3.0, it shipped with the VS2005 SP1 compilers that do not support /analyze.  There’s a note on the download page that explains:

     

    Note: the C++ compilers in this SDK release are the same that shipped with Visual Studio 2005 Service Pack 1, however it does not support the /analyze switch. If you need that capability and do not wish to upgrade to the latest Windows SDK, you can obtain that functionality by installing the C++ compiler from the older Microsoft Windows Software Development Kit for Windows Vista and .NET Framework 3.0 Runtime Components.

     

    That means you’re using the compilers without /analyze support with VS2005.  If you want to get the earlier compilers, you should download the Vista SDK (as opposed to the Vista UPDATE SDK).

     

    I’m sorry for all the frustration you’re feeling and don’t blame you.  I hope this helps a bit.

     

    --Karin

     

    ||Karin Meier||Windows SDK PM||Build Environment.Samples.Community||http://blogs.msdn.com/KarinM||

     

    Sunday, October 12, 2008 6:35 AM
  •  

    Thanks for the great response Karin, it perfectly explains the behavior I was seeing.

     

    Although I was frustrated trying to get VS2005 compiling with the 6.1 SDK C++ compilers, overall I think the SDK experience is a massive improvement:

    • SDK directory structure is predicable and versioned (C:\Program Files\Microsoft SDKs\Windows\6.1)
    • Visual Studio 2008 automatically picks up the latest SDK without having to change (or use a tool to change) the library/include/etc paths. (it uses $(WindowsSdkDir) now)
    • I can uninstall the tools, compilers, libraries, and headers that ship with Visual Studio completely and install the latest SDK. This means that I can ensure that my development machine and build server contains only one copy of the SDK - I don't need to worry about Visual Studio or the build server accidentally picking up the wrong compiler and libraries.

    Visual Studio 2005 shipped with a version of mt.exe that could generate a corrupt manifest that would cause XP RTM to crash with a blue screen / stop error if you tried to compile a Vista manifest a certain way. The "6.0" SDK mysteriously included a new version of mt.exe (with the same version number!) that corrected this behavior. If we ever compiled with the wrong compiler tools, we risk crashing our customer's computers every time our application started.

     

    With the new SDK structure, I don't need to worry - with only one set of tools, libraries, and headers installed - I know it will either compile with the correct version, or not compile at all.

    • The fact the C++ tools are shared between VS2008 and the SDK means that if the compiler ever gets upgraded in the SDK, I don't need to worry about Visual Studio compiling with an older version of the tools than our build server.

     

    The lack of "/analyze" support in VS2008 compared to VS2005 makes sense if the compilers are shared. Previously, we could install the 6.0 SDK and put "/analyze" in the command line switches to allow VS2005 Professional to "analyze". If the C++ compiler is shared in VS2008 with the SDK, that means that "/analyze" is always there - it's now an IDE restriction that stops it from working, rather than a different "build" of the compiler. It's still frustrating that Visual Studio limits something that ships for free, but at least I understand what's happening now.

     

    The only problem I'm still facing is getting VS2005 working with the 6.1 compiler:

    • With VS2005, I could install the 6.0 SDK and have Visual Studio use the SDK's compiler and tools. This was important due to the mt.exe bug I explained earlier.
    • The 6.1 SDK "registers" it's libraries and headers with VS2005, but not the compilers. This means that migrating from the 6.0 to the 6.1 SDK introduces a "breaking change" in support:
      • VS 2005 + SDK 6.0:
        • SDK 6.0 C++ Compiler and Tools
        • SDK 6.0 Libraries and Headers
      • VS 2005 + SDK 6.1:
        • VS2005 C++ Compiler and Tools (old version with mt.exe issue)
        • SDK 6.0 Libraries and Headers

    I couldn't find anything on the SDK Release Notes mentioning this fact - I'm not sure if it's a bug, an issue on my end, or expected behavior that wasn't documented in the Release Notes.

     

    It's easy to reproduce - uninstall all of the SDKs except 6.1, then run the registration tool to hook it up to VS2005. Go into Tools->Options->Projects and Solutions->VC++ Directories. For "Executable Files" you'll see the path "C:\Program FIles\Microsoft SDKs\Windows\6.1\bin" registered. Although the compilers used to be located in the bin directory, they were moved to C:\Program Files\Microsoft Visual Studio 9.0\VC\bin.

     

    I also noticed another bug in the registration tool. I'm not sure if your team is aware of it, but the 6.1 registration tool has a bug or behavioral change that wasn't present in previous SDKs.

    Go to the VC++ Directories in VS2005, select "Win32" as the platform and show directories for "Include Files". Add a new directory to the list - "C:\Test".

     

    Run the registration tool, then re-open Visual Studio. The "C:\Test" entry was deleted, meaning that the registration tool resets the complete list of libraries and include directories. This broke things on our end, since we depend on 3rd party libraries such as WiX (Windows Installer for XML).

     

    Thanks again for your great reply Karin. I hope this sheds a bit more light into the situation we're facing.

    It's not a show stopper, it just makes the VS2005->VS2008 migration a bit trickier in terms of planning.

    Tuesday, October 14, 2008 4:54 PM
  • I made a mistake in my previous post - in the 6.0 SDK version the VC build files lived in C:\Program Files\Microsoft SDKs\Windows\v6.0\VC\Bin, not v6.0\Bin.

     

    Reading this post helped quite a bit: http://blogs.msdn.com/vcblog/archive/2007/12/30/using-different-toolsets-for-vc-build.aspx

     

    I didn't realize "vcvars.bat" was how Visual Studio configured and ran the tools. I thought there was some sort of internal magic used to select the binaries, not the path environment variable!

     

    Placing "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin" at the top of the "Executable Files" list in VS2005 caused the new version of compiler to be executed instead of the original VS2005 one.

     

    Should the Windows SDK configure Visual Studio to always use the latest compiler?

     

    Tuesday, October 14, 2008 6:47 PM