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?
- Open command prompt, and go to “cd \windows\Assembly”.
- 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\220.127.116.11__bc828473b22d1b35.
- Great, now back in your dll, do right click –> project settings, under Build, Output Path, and add the following %Windir%\assembly\GAC_MSIL\HelloWorld\18.104.22.168__bc828473b22d1b35\
- 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).