Colin Phillips (Alumni)
Under normal circumstances, when you’re debugging a custom SharePoint solution, the process is easy and simple. However, it’s not always as easy as that.
The definition of normal is of course subjective, but typically (and as defined here) it would be a single server environment in which Visual Studio (2010) would be installed on the same server as the SharePoint server. In this situation, in order to debug a custom solution, you would simply setup your custom solution to be distributed against the proper web application in the server (assuming it’s a sandboxed solution) or setup properly against the farm, code your solution, and then build you solution. Once you’ve got a working solution (it compiles without errors as Debug – make sure it’s not Release for these purposes) and it is ready to be tested, you would simply press F5 to install the solution into your local copy of SharePoint (this will start the process of deploying and running the solution in one easy step), setup any breakpoints, and voila, debug away!
However, if you’re in a multi-server environment, things are never as simple as that. In this scenario, you will have to do the same steps to get your solution setup and built, but instead of simply pressing F5 and having your solution deployed for you into the server for testing, you will have to instead package the solution up and manually run steps (in PowerShell) to install the WSP file (see here for reference http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/36f95fa1-457e-4b52-8b59-baf6ab387c93/). Follow the instructions here to install a WSP file via PowerShell http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2009/12/02/adding-and-deploying-solutions-with-powershell-in-sharepoint-2010.aspx. Once you’ve got your solution installed, you then need to find the executable that runs that solution, and set your Visual Studio to debug that application (see here for reference http://int.social.technet.microsoft.com/Forums/en/sharepoint2010programming/thread/0cb3da87-1169-4737-8bcf-82b80702934b). In other words, you have to run your application so the executable loads, then attach to that process, and then set your breakpoints and run it a second time (unless you’re lucky and some other process has already started your executable for you – such as the timer service). Be sure that if you’re doing this, that the copy of the executable that’s running includes your code, so if your code goes into the timer service, you will need to restart that service every time you make a code change.
If you simply try to do the F5 debugging trick in a multi-server environment, you’ll most likely run into the error below, as documented in this article http://int.social.technet.microsoft.com/Forums/en/sharepoint2010programming/thread/0cb3da87-1169-4737-8bcf-82b80702934b.
Error occurred in deployment step ‘Activate Features’: Feature with Id [feature ID here] is not installed in this farm, and cannot be added to this scope.