Release mode file sync issue - current source code different from the version built

Question

When running my C++ metro project in the debugger in release mode, I dialog pops up that says:

A copy of scenemanager.cpp was found in <long directory path> but the current source code is different from the version built into <the exact same long directory path>

It’s only complaining about the one file, which if it matters, is in a static lib that the main WinRT project is referencing.

I have already:

• Rebooted.
• Cleaned the project, both release and debug.
• Inspected both the project paths in the solution, as well as the output window for the build… everything appears to point to the right place.
• Inspected SceneManager.cpp’s file properties against other similar files in the project.
  1. Content = false
  2. File Type = C/C++ Code
  3. Included in Project =True
  4. Paths and name are correct

The only unique thing about the file SceneManager.cpp is that it has the same name as the static library project it is in, which I only bring up because

As a side note, at the same time this appeared I fail the certification “crash and hangs” test, but I have no proof these are related yet.

---

Jim Tomasko

Answer 1

As an update, the crash is fixed, but I still have the same problem... any time I place a breakpoint in scenemanager.cpp while in release mode, the compiler complaint still happens.  This is not giving me a warm feeling that I'm actually debugging the right content.

---

Jim Tomasko

Answer 2

Sorry for reviving an old thread,

I am currently encountering the exact issue today ( except mine is a normal c++ application VS2012) so  I was just wondering if you found any resolution ? 

thanks!

Answer 3

Suddenly I started having the same problem. Only I experience it in a Debug build. And VS2012 complains on a header file.

---

Dei nostra Matrix est.

Answer 4

I also started seeing this problem this afternoon. So far I have only performed Debug builds. It's a very simple project with only three cpp files and three header files, one of which is my precompiled header file. I looked at the properties for each of my cpp files and discovered that all three had "Precompiled Headers" set to "Create." I changed two of them to "Use" and I no longe get this pop-up.

---

Norm

Answer 5

the same thing with me, VS2012, Debug build,

it's a header file existing only once on disk. (which causes recompile of dozens of cpp files)

maybe update 2 related?

Answer 6

Same here, header file VS2012, debug build.

Had closed IDE and reopened, same problem.

At one point I had noticed (we have a large project) that everything had rebuilt even though I only changed a single line in a .cpp file.  Saw the error occurring after this.  It's like some internal state about dependencies got messed up.

Turns out this laptop is NOT running update 2 so that rules out update 2 as a cause.

Answer 7

possible solution:

this can occur if the file is hosted by a different filesystem where the system clock of that OS is out of sync with the development OS. this happens often for me where my source files are hosted by a linux VM share and its clock desyncs sometimes.

Answer 8

I have the same problem today and refer to this thread. My projects are C++, Debug Mode, and my app crashes due to this problem, with no call stack.

To clean all projects relating to the file, rebuild, then I no longer get the message "A copy of <file name> was found in <long directory path> but the current source code is different from the version built into <the exact same long directory path>", and the app doesn't crash anymore.

This is contrast to Jim Tomasko's comment above "Cleaned the project, both release and debug, but still have the issue"

I have log my attempts before having the fix:

_ I tried modifying the <file name> like adding a space to rebuilt that object but still got error

_ I checked the time of the objects, libraries, execution file, source codes, assured they were new and created correctly.

_ I skipped the lines causing crash but my app still crashed somewhere else with no call stack.

Besides, the comment of James Tomasko, Norm Bullen and ChuiChu bring some merits.

Answer 9

Still no solution?

My VS 2013 (Update 1) just started giving me this same message about one of my .cpp files. This occurs only with Release configuration. If I start debugging with Debug conf. all is OK.

Also confirming the OP's update: clearing all break points from the file in question gets rid of the message. The message shows even if the only break point in there is inactive. When present, the break pont seems to stop where it is supposed to, and step-by-step execution goes as expected.

Annoying it is, but is that all? Am I really debugging the code I think I am?

EDIT: Oh, and this is not really a WIndows Phone app development issue but more general Visual Studio issue. Maybe someone holding the powers might want to move this to a mode appropriate location.

Answer 10

I am experiencing this issue on VS2012 update 4 in native C++. After deleting all breakpoints, the error message no longer pops up, but I need to use those breakpoints! Any resolution in the works?

To clarify for other readers, this is not the same error message that occurs when the source has changed but has not been rebuilt for the current debug execution. That message is "The breakpoint will not currently be hit. The source code is different from the original version."

Answer 11

A few years late to the party, but it doesn't look like this thread has a solution. I was able to solve this issue, so thought I'd update.

I basically tried to completely nuke the offending file and replace it with a new file. Here are the steps I took.

• Back up the text of the file in a new file somewhere else on the computer (Desktop, documents). I'm also working with source control, so I shelved my current changelist as a secondary backup.
• Delete the source file from windows explorer.
• Delete the file in the solution explorer of Visual studio (it told me that it couldn't find it to delete it, since I had already deleted it, so you could probably just remove it from the project...just being thorough).
• I ran a build, fully expecting a bunch of errors because of the missing file, and I got them. Not sure how necessary this step is.
• Add a new blank file from the solution explorer, with the same name as the file you deleted.
• Copy and paste the text from your backup file from elsewhere on the computer.

So it seems to me what you should have now is a file that compiles with the same source code as your old file, but is otherwise unrelated to your original file. Any time stamp or file property weirdness should be gone. I don't know what the cause was, but this worked for me. I ran and added breakpoints and haven't gotten the error again.

Hope this helps anyone stumbling into this issue much later, like I did.