Configuring SharePoint for Debugging was quite the adventure, particularly since you have to sift through tons of information on the topic... I have two different ways that do work (both relatively easy); I'll provide the details below.
The following screen is what started the adventure:
From Visual Studio 2008 I clicked on Debug, Attach to Process and sorted by process - I found I had two w3wp.exe processes; I need to attach to one of them. I should note that my Google research resulted in varying ideas on the topic, one site I read noted that if you select more than one process *only the first will run*; if the first isn't yours then it won't work, most sites will have you locate the applicable ID using IISApp.vbs, which was not to be found on my system - I later learned it is an IIS 6 file (more on this below). The SharePoint Training Management Application Documentation notes that you should select them all - indicating that they will all be debugged (which makes sense). But just in case.... below is the steps to run your specific process.
I clicked on Start and typed in CMD
From the command prompt I did the following:
cd \Windows\System32\Inetsrv
appcmd list wps
I found that I needed to attach to w3wp.exe with ID 3856. Note AppCmd.exe is used with IIS 7.0, I understand that with IIS 6.0 you'll have to use the following:
cscript c:\windows\system32\iisapp.vbs /a "SharePointDefaultAppPool" /r
I deleted the Training*.* files from C:\Windows\Assembly (GAC), attached to process 3856 and ran the site to see what would blow up - I got the following error:
I used this opportunity to find where the Bin folder was by getting a reference to the context (see image below on line 38)
Note above that I got past the error - it was because I added the following statement to all of the projects that need to be in the GAC - after a successful build the DLL files would be copied to the Bin folder for the site:
However, I was being stopped by a different Error:
At first I thought I'd take the easy route, all the research on CASPOL (much of which hasn't worked for me in the past) wasn't a path I have the time to take and I was the only developer placing code on my server (I'm rationalizing because I know this isn't the right way). I changed the Web.Config to use "Full Trust" as shown below so I wouldn't have to deal with Partial Trust:
As well as it was working (breakpoints being hit) I was not happy with the Full Trust and Bin folder solution. I deleted the files from the Bin folder, set trust back to WSS_Minimal and updated my Post-Build events as follows - Note: the colon on the first column of the second line is a REMARK statement (line is ignored); the first line installs my DLL into the GAC. I did this for each Project that needed to be in the GAC
I then complied with the following steps:
1. Compiled all of the projects (post-build updated GAC)
2. Deployed the applicable sites
3. Clicked Start | Command => IISRESET / RESTART
4. Attached to the W3wp.exe process
5. Loaded the site and all of my breakpoints were hit - everytime I accessed the page
Debugging worked as well with the files in the GAC and partial trust as they did with the files in the Bin folder w/Full trust.
Note: I didn't have to put my .PDB files in the GAC (many sites suggest this)
Something worth noting is that during my Google Adventure to Debug SharePoint I ran into something that said if you went to Tools | Options and unchecked "Enable Just My Code (Managed only)" that this was all that was required. At the time I tried this it worked but as you see below it is currently checked and it is still working. Just in case it could make a difference I'll note it here.
Disclaimer: I develop on Windows Server 2008, .NET 3.5 SP1, Visual Studio 2008 - don't know how well these tips will work in other environments.
Tags:
debugging,
sharepoint
Categories: