SharePointers

This is a command that will quickly let you know which w3wp.exe you should be debugging on Server 2008 (IIS7, since the App Pool isn't listed in Visual Studio's 'attach to process' dialog). go to \Windows\System32\inetsrv and run "appcmd list wp" and you'll get a list that associates App Pool and PID

There are several components/processes that are involved in the execution of sandboxed solutions.    For a developer, it's critical to understand how coding/debugging various types of solutions changes based on the type of solution.  Here's how the execution goes in a nutshell: When the sandboxed code is called, the Execution Manager (running in the w3wp.exe) makes a call to an application server running the User Code Service (SPUCHostService.exe).  The User Code Service then tells the Worker Service  (SPUCWorkerProcess.exe) to load the sandbox code.  The code is then verified to ensure only calls to the subset of the API allowed by the Sandbox API are called.  The worker process then executes the code against the Worker Proxy (SPUCWorkerProcessProxy.exe) which has full access to the SharePoint API (but the sandboxed code has already been disallowed from using the non-subset portion of the API by the Worker Service). When debugging sandboxed solution...

SPFile.MoveTo(), at first glance, looks to be a very straightforward method where a file can be moved from one folder to another. Trying to use it and have an alert triggered by your newly copied file? Forget it. MoveTo() copies the binary to the target library as expected, but fails to recreate the item metadata (created, modified, users, dates, etc.) and will not trigger the alerts that your users set up for the target library. To work around this problem, you can create your own method that uses the SPFileCollection.Add(), which allows you to specify metadata, as described here: http://www.u2u.info/Blogs/Patrick/Lists/Posts/Post.aspx?ID=1141

I've been banging my head for a few days trying to debug a feature receiver that I built and deployed using STSDEV. After scouring the web I found lots and lots of questions, and typically the same, incomplete, answer. To get things to work, this is what I had to do: In VS2008, click on Project->Settings->Debug. When you get to the debug settings for your project, you'll notice each of your build targets in a dropdown at the top of the page. Select a target and then scroll and click the 'Advanced' button. By default, STSDEV doesnt generate a PDB for most of its build targets, so you'll want to change the "Debug Info" drop-down selection to "full". Repeat for each build target that you need debug info to be generated for (at least DebugDeploy and DebugRedeploy). Build and deploy your solution using one of the targets you changed above. Map a drive to \\machinename\c$\windows\assembly. This allows you to see the file structure of the G...

If you've gotten sufficiently comfortable generating solutions with STSDEV, you've probably found that debugging doesn't seem to work. The reason is because the DebugBuild configuration is the only configuration that includes Debug code. Here's how to set up your project so that you can debug the other builds: Go to your Project Properties, click the 'Build' tab and turn on 'Define DEBUG Constant' and 'Define TRACE Constant'. Then click on the 'Advanced' button at the bottom of the Build configuration screen and change the 'Debug Output' value to 'full'. This tip came from the STSDEV discussion forum .