I'm creating an IE extension in C# using visual studio 2010. How do I go about debugging the extension whilst running it in Internet Explorer?
A few things are very striking:
This question is being asked a lot
Most answers, if not all, are incomplete or incorrect
So here it goes: In VS2010. perform the following:
Create your BHO project, a good starting point is: Demo IE Toolbar/BHO
Create a similar solution/project, Go to "Solution Explorer", Right Click your project or use Alt+Enter and go to "Properties":
Be sure the debug profile is selected:
We will need some post build events to register our assembly:
These are the different commands:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u "$(TargetName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /f /i "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /unregister /codebase "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /codebase "$(TargetPath)"
The order is important. First the assembly gets unregistered, then registered. The first time you run this, build will fail since these post-build events will fail. This is normal, the first time you build, there was no assembly registered and as such there is nothing to unregister. The second time you build, everything will work just fine. At this stage, after a successful, error-free build, manually starting IE should result in your BHO being visible:
Now we would also like to be able to just go and press F5, have the whole thing build, open IE and attach the debugger. Contrary to popular belief however, the VS 2010 debugger will not attach on its own, not even when defining "Start external program" in "Debug" (which in fact, is still necessary):
Doing so will start IE, your BHO should also run but breakpoints will not be hit.
To solve this we will use:
public virtual void SetSite(Object pUnkSite)
{
#if DEBUG
Debugger.Launch();
#endif
... Other code ...
}
This ensures that the debugger gets attached early on in the BHO lifecycle. Read about the nitty gritty details here.
Pressing F5 now will result in a few dialogs asking you which debugger to attach:
From thereon out it' s happy debugging:
I hope this helps!
EDIT
I recently was asked to bring some updates to a rather ancient BHO I wrote. Revisiting my own tutorial, I noticed some issues might come up when following it:
1) After quickly deploying a W7 machine with VS2010 (as released) I got a funky error when an attempt was made to attach the debugger:
I could resolve the issue by also installing VS2010 SP1 (as I used it originally) although I have no clue why this was happening.
2) Right now, when an attempt is made to attach the debugger, the instance of VS2010 holding my project is not in the list of available debuggers.
However, when I just cancel all dialogs and restart IE, the running instance is magically there and I can hit my breakpoints once again. The issue seems related to questions by others.
EDIT 2
The 2nd issue was solved after a full reboot, just as in the linked question.
Project + Properties, Debug tab. Select "Start external program", set it to c:\program files\internet explorer\iexplore.exe. You probably want to set the "Command line arguments" to the path of an HTML file that exercises your BHO.
Set a breakpoint on the code you want to debug. Internet Explorer will start running when you press F5. You'll see the breakpoint turning hollow, indicating that the breakpoint is not armed. As soon as IE loads your DLL, visible in the Output window, it will turn into a solid red. And the debugger automatically breaks when IE calls your code.
There is a registration step. Do always avoid using gacutil.exe, it does nothing but pollute the GAC on your machine. Always favor the "Register for COM interop" option in the IDE, the equivalent of running Regasm.exe with the /codebase option. No need for the GAC that way. Either way, VS must be running elevated to make these machine config changes, start it by right-clicking the shortcut and selecting "Run as Administrator".
Related
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
I am using Visual Studio 2013. I use a single start up project. There are more than 8 projects in the solution. Here is what I used to do when I was on Visual Studio 2010;
I would Build the solution. Then run it from its .exe file in /bin/Debug, then on Visual Studio, I would Attach to Process and it would start debugging and it would always hit the breakpoints as long as the source code and the .exe are not different.
This is the same thing that I do on Visual Studio 2013. I put the breakpoints in a file in my startup project. I build the solution (it says it successfully builded on the output window), or I Start Without Debugging, then attach to process, it says "The breakpoint will not currently be hit. The source code is different from the original version" Then I stop debugging, and without building again, I run the .exe again, attach it, then the breakpoints start hitting. Why do I have to close my .exe and then start it again? I use attach to process a lot and this 'must do twice to hit' is really annoying. I haven't change any configuration or anything. What am I doing wrong? I swear I don't change the source code. Not even a single space. It says "Build succeeded" when I attach it.
I have a similar issue. (on a webproject)
my temp solution:
right click the web project
Select Property Pages
Under Build --> Change the Target Framework to something else than the one selected (Apply the new framework)
Then Change back to your desired framework and Debug
I have an issue with Visual Studio 2010 and an ASP.NET 2.0 project.
I have searched StackOverflow for a possible solution to my problem, but even though there are alot of articles related to the Visual Studio debugger, none specifically solve my issue.
Every time I start debugging, Visual Studio tells me that "The breakpoint will currently not be hit. The source code is different from the original version.". In the past when I got this problem, I could solve it by doing a Clean Solution. Or if that didn't work, I could always restart Visual Studio or my machine and the problem would be gone. This, however, doesn't work anymore. The solution cleans and I can rebuild, but the debugger still complains about the source.
I found that if I delete the folder "root" in "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files", the problem is temporarily gone but only the next time I start the debugger, and only for the breakpoints that are currently set in the project. All breakpoints I add when the debugger is running are also not being hit due to the source/original difference.
I don't know how to solve this issue permanently because I don't want to delete that folder every time I have to start a debug session.
I also have a few ASP.NET 4.0 projects that debug just fine.
I use Windows 7 Enterprise (x64).
If someone has a suggestion I would very much appreciate it :)
Try this
Right click solution.
Click "Property"
Go to: "Common Properties" -> "Project Dependency"
Select your "project" from drop down list
Check every item in list of "Depends on"
Click "OK"
Now Open "Task Manager"
And kill all worker process i.e. "w3wp" in case of iis7
Or Kill all "WebDev.WebServer40.exe" process
Now run your application.
Has anyone gotten a debugger attached to mshta.exe after installing IE9? (64bit or WOW64)
If you have Visual Studio, go to Tools -> Attach to Process and attach to the MSHTA.EXE process. Then pick Script as the target to debug.
I'm on a Vista x64, so I have to contend with the 32bit/64bit barrier.
HTA
c:\windows\system32\mshta.exe
(mshta32)
c:\windows\syswow64\mshta.exe
(mshta64)
Launching
"mshta32 foo.hta" may use mshta32 or mshta64 depending on what is associated with HTA
the same goes if "mshta64 foo.hta" is used
"cmd /C start foo.hta" would have the same affect.
Debugger
MS Script Editor (from Office XP/2003) for JS debugging in IE/HTA
Normally I would use the debugger keyword to initiate the launching of the debugger, however with IE9, it doesn't seem to do that anymore. I must launch the debugger first, attach to the mshta.exe process manually (only supports 32bit). Then everything appears to work fine!
EDIT:
With coworkers, different machine have exhibited different behaviors:
debugger keyword works fine
Connecting to MSHTA.EXE from the debugger doesn't work
I haven't yet found a silver bullet.
Try using 'Stop' statement. This should raise the debugger dialog
I had the same problem. Finally pieced together how to debug using Visual Studio from two sources
Turn on script debugging through Internet Explorer, as described here and here
Start up Visual Studio. Click on Debug -> Attach to Process
Run the .hta file and select the running process from the Attach to Process dialog
(I just posted this in the NUnit discussion group on groups.google.com)
Under VS 2008, I would run my tests under NUnit, and, if I needed to
debug, I would attach the VS2008 debugger to the running Nunit process
(Debug -> Attach to Process), and set any breakpoints on code I wanted
to examine. When I hit the Run buttion in NUnit, it would hit the
breakpoint. (BTW, if it matters, this was running NUnit 2.5.2).
I just upgraded to NUnit 2.5.4 and VS 2010. When I set a breakpoint,
then attach to NUnit, I get a little warning symbol on the breakpoint
dot, and hovering over it gives the tooltip "Breakpoint will not be
hit. No symbols are currently loaded". Going to the Debug -> Windows -> Modules window shows a whole bunch of Windows and NUnit modules
loaded, with the Symbol Status of "Skipped loading symbols", and then
1 module with a funny name that changes each time (r1euhmh5 right
now), and Symbol Status of "No symbols loaded". (There is no trace of a module with a name remotely like my DLL under test).
Right clicking the funny filename (assuming that to be some mapping from my
DLL under test), and clicking Load Symbols From -> Symbol Path, and
navigating to the bin\debug folder, then clicking the pdb file of my
DLL under test, I get the message "A matching symbol was not found in
this folder". (The top of the Open dialog box has a line that says
"Original location: r1euhmh5.pdb")
So what's changed? And how do I go about debugging/breakpointing
under VS 2010/NUnit 2.5.4 (Or is it possible I screwed something up
when I decided to go through my VS2010 options and set some of them to
more advanced levels than I knew what I was doing?)
I appreciate any help.
I'm not sure I understand exactly why, but the answer is to attach the debugger to nunit-agent.exe instead of nunit.exe. See Charlie Poole's response here
There's information on this blog post about how to tell NUnit to use the correct .Net framework in the nunit.exe configuration file.
The benefit to fixing this in the configuration file is that it allows you to set up your unit test project so that you can launch NUnit as an external command when you select Debug -> Start New Instance.