Visual Studio warning about copies of files with different contents

The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.

I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General

I solved it:

1. Close the window of the .h file in Visual Studio if it's open.
2. Close Visual Studio.
3. CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
4. Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
5. Paste the .h file back into its original location.
6. Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)

This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.

This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.

It took me quite a while to figure this out.

To fix this:

1. Right-click your header file in Solution Explorer and select Properties.

2. Select All Configurations, All Platforms.

3. Under General, change Item Type to C/C++ Header.

4. Press OK.

5. Force-recompile any file that #includes your header (or just Rebuild the solution).

Try removing breakpoints from the file in question. This worked for me when it occurred with Visual Studio 2013 for a header file in debug build. Source: Release mode file sync issue - current source code different from the version built

Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.