"The source code is different from the original version."

Question

I just started having problems debugging my multi-project C# solution in VS 2005 (Windows Forms with a couple class libraries). When I put a breakpoint on a method header and hit debug, the breakpoint gets hollowed out and a yellow exclamation point is added. The tooltip explains:

"The breakpoint will not currently be hit. The source code is different from the original version."

While not debugging, I noticed that the tooltip for the breakpoint shows a 12 line difference:

"At MyClass.cs line, 48 ('MyNamespace.MyClass', line 36)."

Now, if I put a breakpoint thats not on a method header, it appears to work just fine. It breaks at the correct location and I'm able to step through the code line by line. I don't have any weird situations such as "stepping" through blank lines of code that would usually accompany a mismatch between source code and debugger files. However, when I get to a certain line in my code, it crashes. The line?

myButton.Enabled = false;

The error? An IndexOutOfRange exception.

So it appears that even though I'm stepping through my source code, it's getting muddled up somewhere.

I've tried deleting all /bin and /obj folders, and I have rebuilt the entire solution half a dozen times. Still the same problem. There was another thread on this forum with this same problem, and the solution was to uncheck the "Require source code to match up exactly..." option in the Debugger options. I've tried that and it still doesn't work (doesn't break).

Are there some temporary files I need to clear?

Thanks,
Johann MacDonagh

Answer 1

That error means that your build actually failed, but it started to debug the last successful build.  At least, that's what it means when I see it.

 

Answer 2

Thanks for the reply.

I'm able to expliticly hit "Rebuild" on each project and they all succeed. Could there still be some strange build error?

Answer 3

No, if the builds all succeed, then they have succeeded.  In my case, I just look at the error list nad there are errors there.

 

Answer 4

Yeah, unfortuantly I'm not seeing any errors at all. I may just roll back the changes I've made and get the latest working copy from the source control and redo my work.

Answer 5

I had the same problem and found that you have run the command

Biuld->clean solution

and

Biuld -> clean (name of the proyect)

in the Biuld menu. the command clean all the resource and exe, dll, etc from the

head of the proyect netx you need rebuild your aplication

 

sorry for my bad english

Answer 6

I just came across this error but Visual Studio Express C# edition didn't have the:  Build-->Clean option. 

For those using XNA stuff...make sure that your CPU is set correctly.  When I explicitly set it to X86...everything worked fine.

Answer 7

I was just having the same problem using VB in VS 2005.  I'm thinking it's a bug in Visual Studio.  Everytime I tried to debug my code it would appear to compile but the results were from a previously compiled solution.  When I tried to debug to find out why old code was being executed I got that "The source code is different from the original version" message.  After I commented out the new code, it would build the new solution.  Then I just uncommented the code and it worked again.  Very strange.   It must be a bug because this is the code it appeared to have a problem with:

rtb.Text = Date.Now

go figure...

Although I didn't try it, another solution might be to delete the files in the /bin/debug folder or where you have your debug files set to build to.

 

 

Answer 8

Are any of the class libraries you are using Gaced? If the source code is from a gaced assembly, you have to update the gac after building in order for the dll to match.

Answer 9

Did you happen to move some folders in your solution directory?  This happened to me as a result of "re-organizing" my solution directory which had a number of project folders.  I guess one project that had a reference to a class library (another project in the solution) lost its mapping when I moved it so it re-mapped the reference to the copy of the dll in its own bin directory instead of the one in the dll's project directory.  Basically, to fix the problem, I removed the reference to the other project and re-added it.

Answer 10

Hey Guys,

 

I had a very similar issue,

 

I did nothing out of the ordinary just changed some code and all of a sudden it wouldn't build my new changes.

 

What was really alarming was my changes were full of errors as I had copied the code from somewhere else in my project and when I built the project it would say build succeeded.

 

I also noticed that project would build lighting fast indicating that it wasn't building at all.

 

What worked for me was running the code analysis utility under Build\Run Code Anaylsis on [Your Project Name]

 

I'm not sure if this utililty is in the express edition

 

Hope this helps

Answer 11

I had similiar problem. I solved it by deleting obj\Debug and obj\Release content and *.csproj.FileList.txt file. Don't forget to backup your solution earlier

Edit: I am working in VC#2005 EE

Answer 12

Hi,

 

"At MyClass.cs line, 48 ('MyNamespace.MyClass', line 36)." is the key. You might have 2 identical names.

Try renaming one of your source-files, and see if it helps.

 

/Philip L. Nielsen

 

Answer 13

Just do the method that Ragnarsun said.

 

Go to Build -----> Clean [Project name]

 

And that is all.

Answer 14

my solution was to replace 'CodeBehind' page directive with the new 'CodeFile' directive.
After I replaced that I was able to use Intellisense to set the path to the source file.
For some reason, VS 2005 uses 'CodeBehind' page directive by default when it generates the markup page

Answer 15

This just happened to me while writing an asp.net application in VS2005.

The solution for me was to make a simple change to my web.config file.  The code analysis didn't work, nothing else worked.  I updated the web.config, rebuilt the project, and it actually rebuilt instead of the "lightning-fast" build, and now it's hitting the breakpoints.

I've had a similar issue before when updating code on a precompiled site.  For some reason IIS will sometimes not refresh its cached reference to the precompiled .dll of your code.  So if you just copy over a new precompiled version of your site, IIS will look for the cached name of your precompiled assembly and when it's not there, you get a cryptic error.  Our solution again was to always make an update to the web.config.  If any change is made to this file, IIS will always detect it and refresh its cache.

I would image there is a similar issue on Windows forms apps, but I'm more familiar with asp.net apps.

Answer 16

Hello

I tried deleting the obj/debug and obj/release folder and it worked..The rebuilded code works and break points set do not

give any error message. Thanks for the help.

 

 

 

Answer 17

 

I had the same problem, but the reason was that while coding, i changed my date back by 2 months to test stuff and then whatever code changes i made was probably seen as an older file being chucked in somehow and was then ignored by V.Studio.

(Was using C# Express 2005)

Answer 18

I had the same error and my problem was that not all projects were being rebuilt.  Check out the Build, Configuration Manager menu item and verify that either all projects are being rebuilt or at least the projects that have been changed.

Answer 19

 I am using VS.Net 2008 and I am facing the same Problem "source code is different from original version" and I am not able to debug my project...

I did not find the code analysis utility under Build so Could you please help me ...

Thanks in Advance...

---

amr sinan

Answer 20

older code is being loaded at runtime.

this issue happened to me because i forgot to set the output directory back to my main output folder for a sub project (it was building to its own /bin)

my main project was loading an outdated assembly.

Answer 21

For me, the solution to this issue was to make sure that "Enable Optimizations" was unchecked in Project Properties->Compile->Advanced Compile Options...

A better error description would have been appreciated - VS had no business telling me the source code was different when it clearly wasn't.

Answer 22

I tried the following, but none of them worked in my case :

* restart the computer
* clean build
* rebuild solution
* empty temporary asp.net folder
* ...and more...

The final thing that solved the problem for me was to go to IIS manager and delete the site, then go to the applications properties in VS and under the web-tab click Create Virtual Folder...Finally I can debug. Maybe in VS 2018 web-developing will finally be as easy as windows developing. I HATE developing web-apps....

Answer 23

...and now it stopped working again, can't I be allowed to be happy for more than couple of minutes!!! Now I really hate web developing...

Answer 24

Using Visual Studio 2008, I encountered the same problem. 

In my case, I had created a new Solution Platform (x86), and changed my active Solution Platform to this new one.  After that, I was not able to debug anymore.  What I had to do was to revert back to the old Solution Platform (Any CPU), go in Debug mode (right there, the breakpoints were hit), stop debugging, change the Solution Platform to x86, and that's it, I was now able to debug normally.

Answer 25

Seems like that is not a permanent solution. After a change, I am back to the same issue.  While the trick of switching Solution Platforms still works, there must be something else to do...

Answer 26

i have fix it easy.
right click solution > properties> configuration and check that field  "build " is checked for all entities.

Answer 27

Deleting \obj\Release + \obj\Debug and the SolutionName.suo file then reopening the solution did the trick for me.

Answer 28

If you have two projects with the same base output names, such as proj.exe and proj.dll and you are using a shared output dir - $(SolutionDir)\$(ConfigurationName) then both projects will try to create proj.ilk. Same issue happens with proj.pdb.

If this is your scenario, explicitly set intermediate and debugging file names.