Final Solution: I figured it out! Open your project in VS2010, select the Project menu and choose Properties…, and click the dropdown next to Platform Toolset. You can select between v100 (VS2010), v90 (VS2008), and Windows7.1SDK. Select the 7.1 SDK and click OK. Now you’re all set. Note that you can use v90 to build apps that compile for older versions of Windows as long as you have VS2008 already installed on your machine.
———
The information below is just kept to remind me what I did. It isn’t terribly important.
———
Update: I have found that the best way to utilize the V7.1 SDK is to launch VS2010 from a Windows V7.1 SDK Command Prompt. If I find a better way, I will post it here.
So, I realized today that I’m still building against the v7.0A SDK that ships with Visual Studio 2010 (VS2010). While not a crime, I wanted to make sure that I was building against the latest and greatest SDK. To change the version of the current SDK in VS2010, follow these directions:
- In Visual Studio 2010, open a solution (.sln) file or create a solution.
- In Solution Explorer, right-click the solution node and then click Properties.
- In the Configuration list, select All Configurations.
- Under Configuration Properties, select General.
- As the Platform Toolset option, select Windows7.1SDK.
- Click OK.
(Copied from MSDN : http://bit.ly/do5OLY)
However, I found that this didn’t completely solve my problem. I had converted this VS2008 project to VS2010 before setting the SDK version and some of the project settings still pointed to the SDK V7.0A directories! How frustrating!
The following environment variable directories within VS2010 had been updated correctly or added:
- $(ExcludePath)
- $(ExecutablePath)
- $(IncludePath) — mostly correct
- $(LibraryPath)
- $(PlatformToolset)
- $(PlatformToolsetVersion)
- $(WindowsSdkDir)
- $(WindowsSdkMSBuildTools)
- $(WindowsSdkNetFx35ToolsDir)
- $(WindowsSdkNetFx40ToolsDir)
- $(WindowsSDKVersionOverride)
But the following had not:
- $(FrameworkSDKRoot)
- $(SDK35ToolsPath)
- $(SDK40ToolsPath)
I did find hard-coded references to the V7.0A directory in my solution’s .suo file, so I deleted it; this did not correct the problem.
I found the following entries in the registry that pointed to my V7.0A entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
- FrameworkSDKRoot (REG_SZ)
- $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A@InstallationFolder)
- SDK35ToolsPath (REG_SZ)
- $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx35Tools-x86@InstallationFolder)
- SDK40ToolsPath (REG_SZ)
- $(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx40Tools-x86@InstallationFolder)