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


Some strange things happened today while I was testing some new code. The first problem was that the new code that I wrote wasn’t compiling when I attempted to debug. There were no compiler errors and the build was successful but upon debugging, the changes to the code that I made were not being executed. So, I tried to put a breakpoint at the location of the new code only to be confronted with the below error:

I have seen this error when you have compiler errors but decide to continue debugging using the last successfully compiled version, but this wasn’t the issue as everything was compiling correctly.

I figured something got corrupted in my project configuration so I built the project by right clicking on the project name in the Solution Explorer and clicking Rebuild. This will delete all temporary and intermediate files that are created while compiling and then compile the application from the ground up.

This solved my problem for a while but I was soon confronted with the same situation. I was baffled as I had never seen this problem occur and I didn’t want to have to rebuild the project every time I debugged as that took quite a bit longer. It was then that I realized that what I was doing during my testing was effecting the compilation process.

I was working on a clock in/out system that hooked into the SystemEvents.TimeChanged event so that I could detect changes in the system clock. During my debugging I would change the date and time on my computer to future and past dates, stop debugging, make some more changes, and then run my application again. From what I could gather, Visual Studio was getting confused as the modified date on the source code files were all out of wack. I would save my changes with the correct date and time, then change the system clock during testing, make more changes and save again but this time it saved as a date in the past. Thus, when compiling, Visual Studio would think the previous build was actually more current and not take into account the changes I made. This explains why the Rebuild command worked as it got rid of any files that had been created in previous builds and Visual Studio had no date reference to use when deciding which files to compile.

If you are messing with the date and time during debugging, be aware of this issue.

VS 2008: Registering 32-bit ActiveX Control in Windows 7 64-bit


I got my new Dell Studio XPS 16 laptop a couple of weeks ago with Windows 7 64-bit. The transition from Windows Vista 32-bit was pretty painless and everything seemed to work great. I did have some issues migrating my VS 2008 projects due to references to some dlls that were loacted in the C:\Program Files\ directory on my Vista machine but that are now located in the C:\Program Files (x86)\ directory. After fixing those issues everything seemed to run great and all my projects built successfully. I thought I was home free until I built and ran an Installer package that registered an ActiveX control. Depsite the fact that the control was registered on installation, I kept getting the following error when opening the form that utilized the ActiveX control:

System.Runtime.InteropServices.COMException (0x80040154): Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
at System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance(Guid& clsid, Object punkOuter, Int32 context, Guid& iid)
at System.Windows.Forms.AxHost.CreateWithoutLicense(Guid clsid)
at System.Windows.Forms.AxHost.CreateWithLicense(String license, Guid clsid)
at System.Windows.Forms.AxHost.CreateInstanceCore(Guid clsid)
at System.Windows.Forms.AxHost.CreateInstance()
at System.Windows.Forms.AxHost.GetOcxCreate()
at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
at System.Windows.Forms.AxHost.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.AxHost.EndInit()
...

I scoured the web and tried many different solutions including:

  • Manually registering the dll
  • Copying the dll to the C:\Windows\SysWOW64\ directory
  • Registering the dll in the C:\Windows\SysWOW64\ directory
  • And a bunch of other things that proved useless

The answer came from a blog post by Theo Gray. The issue was that VS 2008 was building the project to compile on “Any CPU” and apparently the ActiveX control is intended for x86 systems only. Given such, the project needed to be compiled for x86 systems only as well. Do the following to resolve the issue:

  1. Right click on the project title in the Solution Explorer.
  2. Click Properties.
  3. Click the Build tab.
  4. Select x86 from the Traget Platform ComboBox for both Debug and Release configuration.
  5. Build the project.

Alternatively, if you have multiple projects in a solution you can do the following to set this across all projects:

  1. Right click on the solution title in the Solution Explorer.
  2. Click Configuration Manager…
  3. In the Active solution platform select New…
  4. Select x86 from the first ComboBox
  5. Click OK
  6. Build the solution.

Thanks Theo Gray! Worked like a charm!

Follow

Get every new post delivered to your Inbox.

Join 68 other followers