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

Hi... :)

I'm using Visual Studio 2008 + Window XP.
There are 2 projects in my solution. 1st for main project. 2nd for unit test.

I'm trying to debugging and found that break point doesn't work and and pop up the detail as below:

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

I have checked all the properties and they are all in debug mode. Also already try to clean solution rebuilt, restart VS, restart computer, delete pdb file in debug folder and still doesn't work. In release mode breakpoint works. In debug mode breakpoint doesn't work. It is so weird. :(

What I observe is ...
I have a button and caption is "XXX" and I use this sentense to change the button's name.

m_ctrlDelCom.SetWindowTextA(_T("Delete Component"));

If I change to release mode and rebuilt. The text will change from "XXX" to "Delete Component"
If it is still in debug mode and rebuilt. The text will still remain "XXX".

Please kindly help.
Thank you very much in advance. :)
chang2008Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DhaestCommented:
Perhaps you're problem can also be solved with the help of this article

Debugging .Net Applications: Stopping The "Breakpoint Will Not Currently Be Hit" Message
http://it.toolbox.com/blogs/programming-life/debugging-net-applications-stopping-the-breakpoint-will-not-currently-be-hit-message-26262
0
chang2008Author Commented:

For this website : http://it.toolbox.com/blogs/programming-life/debugging-net-applications-stopping-the-breakpoint-will-not-currently-be-hit-message-26262

1st solution : The pop-up detail change from "The breakpoint will not currently be hit. The source code is different from the original version." to "The breakpoint will not currently be hit. No symbols have been loaded for this document."

2nd solution : I don't know how to do it. Please kindly explain.

3rd solution : There is no obj or bin folders.

4th solution : doesn't work.

5th solution : doesn't work.

6th solution : Active(Debug), Active(Win32)

7th solution : What is Web.config? I don't do anything about web apps. I'm using MFC.

8th solution : I don't use ASP.Net

9th solution : Project Properties -> Configuration Properties -> Build (There is no Build there. Under Configuration Properties, there are General, Debugging, C/C++, Linker, Manifest Tool, Resources, MIDL, XML Document Generator, Browse Information, Build Events, Custom Build Step.) Which one?

10th solution : doesn't work.

11th solution : Debugger type I have set to "Auto".

12th solution : I don't understand.

13th solution : I don't understand, too.

14th solution : How could I check it?

14.1th solution : I don't understand.

14.2th solution : I think that it is not related to my project.

14.3th solution : This one seem possible because I have 2 projects in 1 solution but how could I check it?

14.4th solution : ASP.NET ... I don't use it.

What should I do now?
0
chang2008Author Commented:
Also I have another project. Debugging works fine. (But this one has 1 project in 1 solution.) Another one, which has problem is the one has 2 projects in 1 solution. I still can't solve the problem.
0
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

DhaestCommented:
Are the projects referenced ?
0
chang2008Author Commented:
Yes, test project reference to main project.
0
itsmeandnobodyelseCommented:
>>>> In release mode breakpoint works. In debug mode breakpoint doesn't work. It is so weird.

That must be a misunderstanding or you mixed up the configurations somehow. In Release mode all breakpoints were ignored. If a program breaks when the active configuration is (the) 'Release configuration', the configuration actually is a Debug configuration, i. e. the Optimization was switched off, the runtime dlls in the Code Generation were debug runtime dlls and the _DEBUG was defined in the Preprocessor macros (Release: NDEBUG).

That hardly could be achieved by accident, so I would assume the statement 'In release mode breakpoint works' should mean, 'In Release mode the statement of the line where I put a breakpoint at,  was successfully executed while in Debug mode it doesn't break there'.

>>>> m_ctrlDelCom.SetWindowTextA(_T("Delete Component"));

First, if calling SetWindowTextA explicitly you definitively should *NOT* use the _T macro. The SetWindowTextA takes a const char* (LPCSTR) what would require a call like

     m_ctrlDelCom.SetWindowTextA("Delete Component");

By using the _T macro the statement wouldn't compile after switching to MS UNICODE character set.

Where did you call that statement?

It either should be called in OnInitDialog (or OnInitialUpdate in case of a form view), or in a handler function, e. g. when handling a button.

In both cases breakpoints *MUST* apply when putting them immediately after the initial curly opening bracket { of the handler function. If the Studio editor doesn't accept the breakpoint there, one reason for that is that the source you were editing is not the same as the debugger was refering to. To verify that

  - Close all documents
  - open the file from the project tree by double-clicking on it
  - hover with mouse over the label of the file in the edit tab
  - check that the filepath is the one you expect
  - check whether the statement where you want to set the breakpoint
    still is in the file you opened freshly and that setting the breakpoint
    still doesn't work.

If still the issue wasn't gone, close the Visual Studio and

   - delete folders Debug and Release below project directory
   - delete temporary files project.ncb, project.aps, project.bsc, project.pdb

Restart Visual Studio and rebuild both Release and Debug version.

If still the issue wasn't gone, the function you were trying to set the breakpoint probably is in a dll (and not in main project). Then, it is quite normal that the IDE firstly says that the breakpoint couldn't be applied as at compile time the connection to the dll could be unknown. But, at runtime you should be able to set a breakpoint in your main project where the dll firstly was invoked and *after* that you should be able to set a breakpoint to any function of the dll as it now was known by the debugger.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
chang2008Author Commented:
My project was UNICODE. That's why I use _T().
But it doesn't compatible to other plug-in. So, I have changed to Multi-byte.

I will summerize what happen.
1.) Debug run normally with UNICODE.
2.) Combine with other pluging has memory leak in strcore. So, I have chaned to Multi-bye. (Debug still run normally)
3.) Add unit test (C++) project. Create 2 classes for test. Change those 2 new classes property from "No Common Language Runtime support" to "Common Language Runtime Support (/Clr). Add reference of unit test to the main project. (Debug problem occures here)

4.) 1st Observation :

Debugging .....
m_ctrlDelCom.SetWindowTextA("Delete Component");  (Debug reach to the point)

Edit something, for example change "Delete Component" to "Delete". Then Debugging .....
m_ctrlDelCom.SetWindowTextA("Delete");   (Debug doesn't reach to the point)

Change back to "Delete Component". Then Debugging .....
m_ctrlDelCom.SetWindowTextA("Delete Component");  (Debug again can reach to the point)

5.) 2nd Observation :

Debugging .....
m_ctrlDelCom.SetWindowTextA("Delete Component");  (Debug reach to the point)

Edit something, for example change "Delete Component" to "Delete". Then Debugging .....
m_ctrlDelCom.SetWindowTextA("Delete");   (Debug doesn't reach to the point)

Release .....
m_ctrlDelCom.SetWindowTextA("Delete");

Then Debugging ..... again
m_ctrlDelCom.SetWindowTextA("Delete");   (Debug reach to the point)

By the way, I will try the solution that "itsmeandnobodyelse" suggest. Thanks. :)
0
chang2008Author Commented:
I have solved the problem.

The problem comes from I mix the native and clr because I have to use unit test. Then it calls regasm instead of regsvr32. (I don't know why.)

1.) So, I use post-build event regsvr32 to call regsvr32 .../Debug/my.dll in debug folder and turn off the register output in linker.
2.) and also I config the normal debug with excluded unit test reference code and config the debug test with included unit test reference code.
0
chang2008Author Commented:
Thanks :)
0
itsmeandnobodyelseCommented:
>>>> Then it calls regasm instead of regsvr32.
The regasm is to register .NET assemblies while regsvr32 calls entry DllRegisterServer in the dll. If you have a mixed assembly these options were not combinable. But you could call the DllRegisterServer function yourself after loading the dll (what probably was made before you changed to /clr).
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.