Getting around “This breakpoint will not currently be hit”.

Posted on 1/3/2009 @ 2:20 PM in #SharePoint by | Feedback | 5141 views

Okay so, I bet you’ve seen this before. In the real world, I would be willing to assert that 90-99% of the code written for SharePoint 2007 goes in the GAC. Oh sure it’s full trust, but it beats the alternative. Writing CAS is just so unwieldy and difficult, not to mention, there are many scenarios that absolutely require GAC. As lamented by Dan Larson in his blogpost here, .. quoted ..

But alas, there are a few reasons to GAC. For one, you need to GAC your feature receivers... so we've always had some code in the GAC. But to work with Web Parts programmatically (adding them to the page, manipulating them) the executing code needs access to the Web Part assembly. So for receivers to work with Web Parts, the Web Parts need to be GAC'd. Otherwise, you might need to set up a Web Service that your receiver can call that can then work with the Web Parts-- we did this in the last release, and it wasn't an approach that was bulletproof across all of our customer installations. This approach would be fine for internal development where you control the environment and can test against it, but as an ISV there are too many unknown factors (including authentication) that are involved. So we GAC'd the Web Parts, which does make me feel a bit dirty, but our code is more reliable than an alternate approach, and because of that our business stakeholders and customers are appreciative. Did I bypass CAS altogether though? Not entirely-- a customer COULD choose to run in a pure bin-deployed scenario, although they wouldn't get all of the functionality.

In fairness, you should read his full blogpost, because he still says CAS is better .. well yeah, but it’s just so damn broken and hard (Okay I’m not as smart as you .. Mr. Dissenter). CAS is better, sure .. it’s better, like pizza in Italy is better. I know Pizza in Italy is better, but the practical me still goes to Pizza hut because it’s cheaper, easier, quicker, and y’know .. for my needs it tastes ok enough. Dominoes on the other hand is true value for money. Once you’re done eating the pizza, you can eat the box .. they both basically taste the same. LOL.

Anyway, so in typical SharePoint development, what do we do? We throw our DLL in the GAC, then we attach the W3Wp.exe .. hopefully the right one .. I always look at the userid running the specific instance of W3Wp.exe. And then I come by to happily debug my code to be happily greeted by this -----

Oh well, “This breakpoint will not currently be hit. No symbols have been loaded for this document.” C’mon .. I know you’ve seen that message before.

So how do we get around this message?

EASY!

  1. Open command prompt, and go to “cd \windows\Assembly”.
  2. In there, execute this command “dir HelloWorld.dll /s” .. this will tell you where exactly on the file system is your HelloWorld.dll (the dll you are deploying to the GAC), is ending up. In my case, the path was - C:\Windows\assembly\GAC_MSIL\HelloWorld\1.0.0.0__bc828473b22d1b35.
  3. Great, now back in your dll, do right click –> project settings, under Build, Output Path, and add the following %Windir%\assembly\GAC_MSIL\HelloWorld\1.0.0.0__bc828473b22d1b35\
  4. Yeah that’s it. Now, attach to W3wp.exe, and your breakpoint should get hit reliably, everytime.

Do note that IIS will still cache the GAC DLL, so you still need IISReset, or recycle app pool using (Win2k8 only) - appcmd.exe recycle apppool "apppoolname" (there is an equivalent script for Win2k3 also, but c’mon get on with the times already. Win2k3 .. is so .. 2003).

Have fun!

Sound off but keep it civil:

Older comments..


On 1/3/2009 2:53:47 PM Bjørn Furuknap said ..
Honestly, I've never seen that message, not unless I do something wrong in the deployment. Are you sure you're attaching to the right w3wp process? I do get that message if I forget to IISReset or modify the source after I deploy, but not otherwise. Then again, I am using WSPBuilder most of the time and rarely have more than one app pool running.

Perhaps it is a W2K8 issue. I hear that it isn't as well tested as W2K3. :-)


On 1/3/2009 3:39:50 PM Sahil Malik said ..
Hmm .. I've seen it plenty on W2k3. But I didn't use WSPBuilder extensions.


On 1/12/2009 2:43:38 PM Doug Ware said ..
Hi Sahil,


An easier alternative is to just uncheck the Enable Just My Code (Managed only) option in the Visual Studio debug settings. See my post here: http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=23.


On 1/12/2009 3:18:21 PM Sahil Malik said ..
Doug - that is awesome!


On 6/16/2010 2:25:05 PM Nitin said ..
Thanks a lot. Your solution have helped me overcome lot of frustration with Debug Settings


On 11/30/2010 10:50:46 AM Maria Smart said ..
What if the dll was not found in the GAC?


On 9/22/2011 2:55:47 AM Faseela said ..
Activatefeature solved my problem.stsadm -o activatefeature -name EventReciever_Feature1 -url http://site/subsite.The Feature is present in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES


On 1/23/2012 3:27:56 AM OferC said ..
So easy!! Thanks!!!