C++
Solved: The (Visual Studio) project file * has been moved, renamed or is not on your computer.
I renamed my Visual Studio 2010 (VS2010) Solution (.sln) and Project (.vcxproj) files today. When I opened the Solution, it could not find the Project file, thinking it was still in the old location. To solve this, I had to exit VS2010, delete the project’s .suo file, restart VS2010, open the Solution, and then re-add the Project file.
I found this answer here, in reference to VS2005.
Display Unicode Characters on the Windows Console
Even in today’s mostly-Unicode world on Windows, the console (i.e. cmd.exe) still defaults to using OEM code pages (i.e. multibyte characters). To set the console to Unicode mode, use the following code:
#include <fcntl.h>
#include <io.h>
#include <stdio.h>
int main(void)
{
_setmode(_fileno(stdout), _O_U16TEXT);
wprintf(L"\x043a\x043e\x0448\x043a\x0430 \x65e5\x672c\x56fd\n");
return 0;
}
This information came from two great articles by Michael Kaplan:
How to install VC++ update KB2455033
Head to the Visual C++ Team’s blog entry entitled “MS11-025 Visual C++ Update Issue“, scroll down to the section entitled “Visual Studio 2010 RTM with Windows SDK”, and follow the instructions there. For completeness sake, here they are:
If you have Visual Studio 2010 RTM and Windows SDK 7.1 installed on an x64 machine, then the Visual Studio 2010 update (KB2455033) fails to install on your machine.
Workaround
|
C++ Casting Operators
I often get confused about the different types of C++ casts:
- dynamic_cast can be used for “upcasting” or “downcasting”
-
Upcasting: A* pA = dynamic_cast<A*>(pB) when B inherits from A
-
Downcasting: B* pB = dynamic_cast<B*>(pA) when B inherits from A
-
- static_cast
- static_cast conversions are not as safe as dynamic_cast conversions, because static_cast does no run-time type check, while dynamic_cast does.
- A dynamic_cast to an ambiguous pointer will fail, while a static_cast returns as if nothing were wrong; this can be dangerous.
- Although dynamic_cast conversions are safer, dynamic_cast only works on pointers or references, and the run-time type check is an overhead. (http://msdn.microsoft.com/en-us/library/5f6c9f8h%28v=VS.100%29.aspx)
- reinterpret_cast
- Allows any pointer to be converted into any other pointer type. Also allows any integral type to be converted into any pointer type and vice versa. (http://msdn.microsoft.com/en-us/library/e0w9f63b.aspx)
Integrate the Windows SDK v7.1 with VS2010
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)