Visual Studio warning about copies of files with different contents

Question

When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:

A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.

I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.

The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.

Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).

[You are not alone.](https://social.msdn.microsoft.com/Forums/windowsapps/en-US/fc14870d-60b2-4701-abd0-fe541ac90e72/release-mode-file-sync-issue-current-source-code-different-from-the-version-built?forum=toolsforwinapps) — Daniel Daranas, Apr 28 '15 at 08:12
Hmm interesting. I didn't find anything on Google. What did you search to find that? — brads3290, Apr 28 '15 at 08:15
Literal messages (omitting the particular file and variable names, of course) are usually the best bet. In this case, I searched for ["but the current source code is different from the version built into"](https://www.google.es/search?q="but+the+current+source+code+is+different+from+the+version+built+into"). — Daniel Daranas, Apr 28 '15 at 08:48
There are even [two results](http://stackoverflow.com/search?q=%22the+current+source+code+is+different+from+the+version%22) in this site, but to find them you need to omit "but", because the two posters didn't bother to paste the full message: [1](http://stackoverflow.com/q/22685026/96780), [2](http://stackoverflow.com/q/27106626/96780). — Daniel Daranas, Apr 28 '15 at 08:51
In my case I had multiple projects in the solution and I had forgotten to change the *Startup Project* in the Solution Explorer before starting the new project file from the editor. The two projects had the same `MainWindow` class (no difference could be seen on the screen). VS was comparing the file in the editor (belonging to the new project) with the one stored in the old project which was still the Startup Project and which was the one actually launched. — mins, Nov 07 '19 at 14:21

Greg · Answer 1 · 2016-03-21T07:17:45.680

48

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.

edited Mar 21 '16 at 07:17

answered Mar 09 '16 at 06:53

Greg

1,181
13
13

2

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 – Jon Watte Jul 04 '16 at 17:00
2

I had breakpoints in the .H file that it was barking at (set on inline functions), running the debugger in VS2013. I removed the breakpoints and the nag message no longer appeared. – David Carr Mar 22 '17 at 01:39
deleting all breakpoints fixed the issue for me. I had one on the header file being flagged. Great tip. – edwinc Sep 19 '18 at 19:29
2

All this does is hide the issue, it still comes up you'll still be unable to step through it... -1 – user541686 Nov 01 '20 at 21:22

score 21 · Answer 2 · answered Nov 24 '16 at 03:50

21

I solved it:

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

answered Nov 24 '16 at 03:50

UserX

485
5
12

2

This still doesn't prevent the problem from happening again (i.e. it still happens the next time you edit the file). – user541686 Nov 01 '20 at 21:24

score 8 · Answer 3 · answered Nov 01 '20 at 21:33

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:

Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).

score 5 · Answer 4 · answered Jul 04 '16 at 17:01

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

The difference may be more than just whitespaces! – lalitm Apr 02 '18 at 03:10 — lalitm, Apr 02 '18 at 03:10

score 2 · Accepted Answer · edited Jun 20 '20 at 09:12

2

Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.

TargetPath

This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 28 '15 at 08:17

Rudolfs Bundulis

11,636
6
33
71

2

I managed to make the warning disappear by running the Clean operation on the solution. I'm not sure about the semantics of the operation so I imagine it would have done something similar to what you suggested. Thanks for the response :) – brads3290 Apr 28 '15 at 08:26
@BradSullivan well, if it comes back, make a comment, we can try to sort it out:) There are not that many reasons it can come from. – Rudolfs Bundulis Apr 28 '15 at 08:39
**If this doesn't work for you, [see my answer below](/a/64637231/541686)!** – user541686 Nov 01 '20 at 21:35

score 2 · Answer 6 · answered Jun 17 '16 at 12:41

2

The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.

answered Jun 17 '16 at 12:41

bloom256

21
2

score 1 · Answer 7 · answered Sep 03 '17 at 08:34

I see the real reason of this question is not answered. So for someone still looking, here it goes... The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying. This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.

score 0 · Answer 8 · edited Jan 30 '17 at 16:10

0

this worked for me:

close VS
delete *.vcxproj.filters file
restart VS

problem should be gone.

edited Jan 30 '17 at 16:10

Martin Ueding

8,245
6
46
92

answered Jan 30 '17 at 15:26

Henry Berger

1

Nope it isn't gone, still the same problem. – user541686 Nov 01 '20 at 21:26

score 0 · Answer 9 · answered Jun 11 '17 at 12:05

0

this worked for me:

clean project
debug/delete all breakpoints :)

answered Jun 11 '17 at 12:05

Qasem

119
1
8

This only fixes it one time. – user541686 Nov 01 '20 at 21:26

score 0 · Answer 10 · answered Mar 03 '19 at 03:20

0

This worked for me (as of March 2019):

Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'

answered Mar 03 '19 at 03:20

TheCyberWarden

1

This only fixes it one time. – user541686 Nov 01 '20 at 21:26

score 0 · Answer 11 · answered Mar 03 '19 at 10:11

0

I've changed the file name and it works now.

answered Mar 03 '19 at 10:11

yunus celik

111
1
7

This is a red herring, it's not the issue. – user541686 Nov 01 '20 at 21:28

score 0 · Answer 12 · answered Aug 23 '20 at 19:07

Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.

I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.

This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.
(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)

score 0 · Answer 13 · answered Dec 15 '20 at 02:59

0

My solutiion:

Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration

answered Dec 15 '20 at 02:59

Люблю вино

21
1
4

score 0 · Answer 14 · answered Apr 19 '22 at 16:53

It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.

The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it

Visual Studio warning about copies of files with different contents

14 Answers14

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

Linked

Visual Studio warning about copies of files with different contents

14 Answers14

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

Linked

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