Just spent an unreasonable amount of time getting remote debugging
working with Sharepoint 2010 Sandbox *AND* Full-Trust solutions. It took
quite a bit of work for me to understand and troubleshoot, so thought I
would write it down:
a. for my own future reference
b. so others don’t have to go through the same heartache
The general approach for sandbox and full trust solutions is the same, but they do differ in a few details.
A post by tlhost on the Microsoft Forums titled A SharePoint server is not installed on this computer got me 90% of the way there, this is just filling in the gaps that tripped me up.
And a BIG THANK YOU to Pav – he helped a ton
On your development machine, run regedit and import the nodes.
Create a project. To test, I simply created a Blank Sharepoint Project (first one was sandboxed, second one was full trust), and added a webpart with a label displayed.
Build the solution (so that you generate .pdb files) and then right
click on the project in the Solution Explorer and choose “Package”. This
will generate a .wsp file, which is actually a cab file (try changing
the extension and opening in winzip or similar). If you extract it,
you’ll see that in the .wsp is the webpart and the metadata files (xml).
Go to Site Actions>Site Settings and click on “Solutions” under “Galleries”
Click “upload Solution”, navigate to your .wsp, upload it, and activate it.
You should now be able to add your webpart to a page
Fire up Powershell_ise (an install of Powershell that Sharepoint installs and which includes a bunch of Sharepoint-specific cmdlets)
Run the command:
and then:
But of course replace with the name of your .wsp and the web application that you want to install to (try running “get-spsite | get-spweb”, if you need to see the sites installed locally)
Your solution should now be installed into Sharepoint, you may have to use the UI and go to Site Actions>Site Settings>Site Collection Administration>Site Collection Features and activate your feature from the list before associated webparts become available.
Add your webpart to a page.
Make sure that the account that you use on your local machine also exists on the remote machine. They do not need to be in the same domain, but they must have the same name. Add the account to the appropriate group on the remote machine (administrators?).
Start the remote debugger “service” by double clicking on msvsmon.
Back on your local machine in VS2010, go to debug>attach to process and enter the domain, account and server that you are connecting to. NOTE that the account name is not necessarily your user account (ie the account you ensured exists on the remote machine above). It must be the account the THE REMOTE DEBUGGER IS RUNNING UNDER.
That is, if your account on your local machine is DOMAIN\jsmith, you have to make sure that a jsmith account exists on the remote machine as well, and that it has permissions to debug. But you might be logging on to the server (let’s call it “SHAREPOINTSERVER1″) with some service account like sharepointadmin_service and running the remote debugger bits as that account. In this case you would attach to the remote process with the “qualifier” of:
DOMAIN\sharepointadmin_service@SHAREPOINTSERVER1
On the remote machine, your debugger should show you as connected:
And in VS2010, you should now see the processes running on the remote server. Make sure you select to “Show processes from all users”.
Find and attach to the SPUCWorkerProcess.
Type CTRL+ALT+U in VS2010 to open the Modules panel
Look through the modules, and you should find your Sharepoint solution and see that VS cannot open its PDB (and breakpoints will not be hit)
Make a note of the path, in this case:
C:\ProgramData\Microsoft\SharePoint\UCCache\8CDA3229CD9F12A\1CAC709F235C40DF8E36CCE5B798E115%2DjtwtnquBLn%2B%2547Udab9QIvqZg0JeyEczf%2547ky%2BIAVMPDzs%3D-13\SharePointProject2.dll
By default, Sharepoint will store the deployed .dll in the c:\ProgramData\Microsoft\SharePoint\UCCache folder on the server. Note that “ProgramData” is a hidden folder, so you’ll have to enable viewing hidden folders and files.
I don’t quite understand the logic (ie when precisely it’s triggered), but the folder will change during the lifecycle of the solution. I believe that when the SPUCWorkerProcess gets recycled, Sharepoint will create a new subfolder, but I’m not sure under what circumstances this occurs. Point being, the “active” .dll is in this folder now, but next time you try to debug, it might be in a different one.
Copy your .pdb file to the specified directory on the remote server
Now you should be able to right-click on the Module in the Modules Pane and select Load Symbols From>Symbol Path
Once you’ve done this, your breakpoint should become “hittable” and the symbols shown as “Loaded”
Reload the web page, and boo-yah, you’re debugging remotely!
(so I guess that means it’s about the same?) Full trust solutions run
in the main Sharepoint W3WP process; however, Sharepoint spins up
multiple W3 worker processes, so you have to connect to the proper one.
On the remote server, back in Powershell_ise execute:
c:\Windows\System32\inetsrv\appcmd list wp
This will return a list of all W3 worker processes, with a bit of descriptive info and process id. You want to make a note of the process ID of the “main” Sharepoint process (generally running on port 80)
Back in Visual Studio, debug>attach to process and find and attach to the W3WP Process on the remote server that matches the process identified above.
Open the modules pane by typing CTRL+ALT+U
Look through the modules, and you should find your Sharepoint solution and see that VS cannot open its PDB (and breakpoints will not be hit)
Make a note of the path, in this case:
C:\Windows\assembly\GAC_MSIL\SharePointProject4\1.0.0.0__bf506a3a24d83b2c\SharePointProject4.dll
Sharepoint stores deployed Full Trust .dlls in the GAC.
A little trick here: in order to navigate the GAC as a normal folder structure, MAP A NETWORK DRIVE on your development system to \\SERVER\C$\Windows\assembly. Go through the mapped drive, and find the install location mentioned above (eg “GAC_MSIL\SharePointProject4\1.0.0.0__bf506a3a24d83b2c\SharePointProject4.dll”). Copy your .pdb file here
Now right click on the module in the module pane and select Load Symbols From>Symbol Path
Once you’ve done this, your breakpoint should become “hittable” and the symbols shown as “Loaded”
Reload the web page, and boo-yah X 2, you’re debugging remotely!
in powershell_ise
For Sandbox Solutions, I go through the UI and remove and add through the Solution Gallery
cheers
a. for my own future reference
b. so others don’t have to go through the same heartache
The general approach for sandbox and full trust solutions is the same, but they do differ in a few details.
A post by tlhost on the Microsoft Forums titled A SharePoint server is not installed on this computer got me 90% of the way there, this is just filling in the gaps that tripped me up.
And a BIG THANK YOU to Pav – he helped a ton
Export Nodes from Sharepoint Machine Registry
Remote to the Sharepoint machine, run regedit and export [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0]On your development machine, run regedit and import the nodes.
Create Sharepoint project
You will now be able to create a Sharepoint Project in Visual Studio 2010. When asked where the Sharepoint server is, tell Visual Studio it’s on your local machine. You will not be able to deploy locally (unless you actually *do* have Sharepoint installed), but you will now be able to create Sharepoint projects, and will be able to package them.Create a project. To test, I simply created a Blank Sharepoint Project (first one was sandboxed, second one was full trust), and added a webpart with a label displayed.
1 | protected override void CreateChildControls() |
2 | { |
3 | base.CreateChildControls(); |
4 | Label l = new Label() { Text = "BLAH!" }; |
5 | this.Controls.Add(l); |
6 | } |
Install .wsp to Sharepoint
This approach may differ between sandboxed and full trust:Sandboxed
Fire up your web browser and navigate to the Sharepoint UI.Go to Site Actions>Site Settings and click on “Solutions” under “Galleries”
Click “upload Solution”, navigate to your .wsp, upload it, and activate it.
You should now be able to add your webpart to a page
Full Trust
Copy your .wsp to the remote machine (anywhere, really)Fire up Powershell_ise (an install of Powershell that Sharepoint installs and which includes a bunch of Sharepoint-specific cmdlets)
Run the command:
add-spsolution -LiteralPath "c:\SharePointProject4.wsp"and then:
install-spsolution -Identity "SharePointProject4.wsp" -GACDeployment -WebApplication "http://RemoteSPInstallName"But of course replace with the name of your .wsp and the web application that you want to install to (try running “get-spsite | get-spweb”, if you need to see the sites installed locally)
Your solution should now be installed into Sharepoint, you may have to use the UI and go to Site Actions>Site Settings>Site Collection Administration>Site Collection Features and activate your feature from the list before associated webparts become available.
Add your webpart to a page.
Get Remote Debugging Bits Set up
Pull the remote debugger folder from your VS2010 install at: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger over to the remote server. Note there is a 64 bit and a 32 bit version. Choose the correct one.Make sure that the account that you use on your local machine also exists on the remote machine. They do not need to be in the same domain, but they must have the same name. Add the account to the appropriate group on the remote machine (administrators?).
Start the remote debugger “service” by double clicking on msvsmon.
Back on your local machine in VS2010, go to debug>attach to process and enter the domain, account and server that you are connecting to. NOTE that the account name is not necessarily your user account (ie the account you ensured exists on the remote machine above). It must be the account the THE REMOTE DEBUGGER IS RUNNING UNDER.
That is, if your account on your local machine is DOMAIN\jsmith, you have to make sure that a jsmith account exists on the remote machine as well, and that it has permissions to debug. But you might be logging on to the server (let’s call it “SHAREPOINTSERVER1″) with some service account like sharepointadmin_service and running the remote debugger bits as that account. In this case you would attach to the remote process with the “qualifier” of:
DOMAIN\sharepointadmin_service@SHAREPOINTSERVER1
On the remote machine, your debugger should show you as connected:
And in VS2010, you should now see the processes running on the remote server. Make sure you select to “Show processes from all users”.
Attach to Process and Deploy .pdbs
Before our breakpoints can be hit, we have to make sure that the .pdbs are accessibleSandboxed
Sandbox solutions run in a different application pool than the rest of sharepoint (hence the “sandboxed” part; your webpart could go nuts and it won’t take down Sharepoint proper). Sharepoint will run in a W3WP process, but the sandboxed solutions will run in a process called the SPUCWorkerProcess.
Find and attach to the SPUCWorkerProcess.
Type CTRL+ALT+U in VS2010 to open the Modules panel
Look through the modules, and you should find your Sharepoint solution and see that VS cannot open its PDB (and breakpoints will not be hit)
Make a note of the path, in this case:
C:\ProgramData\Microsoft\SharePoint\UCCache\8CDA3229CD9F12A\1CAC709F235C40DF8E36CCE5B798E115%2DjtwtnquBLn%2B%2547Udab9QIvqZg0JeyEczf%2547ky%2BIAVMPDzs%3D-13\SharePointProject2.dll
By default, Sharepoint will store the deployed .dll in the c:\ProgramData\Microsoft\SharePoint\UCCache folder on the server. Note that “ProgramData” is a hidden folder, so you’ll have to enable viewing hidden folders and files.
I don’t quite understand the logic (ie when precisely it’s triggered), but the folder will change during the lifecycle of the solution. I believe that when the SPUCWorkerProcess gets recycled, Sharepoint will create a new subfolder, but I’m not sure under what circumstances this occurs. Point being, the “active” .dll is in this folder now, but next time you try to debug, it might be in a different one.
Copy your .pdb file to the specified directory on the remote server
Now you should be able to right-click on the Module in the Modules Pane and select Load Symbols From>Symbol Path
Once you’ve done this, your breakpoint should become “hittable” and the symbols shown as “Loaded”
Reload the web page, and boo-yah, you’re debugging remotely!
Full Trust
In some ways, debugging full trust is a little easier, and in some ways a bit harder
(so I guess that means it’s about the same?) Full trust solutions run
in the main Sharepoint W3WP process; however, Sharepoint spins up
multiple W3 worker processes, so you have to connect to the proper one.On the remote server, back in Powershell_ise execute:
c:\Windows\System32\inetsrv\appcmd list wp
This will return a list of all W3 worker processes, with a bit of descriptive info and process id. You want to make a note of the process ID of the “main” Sharepoint process (generally running on port 80)
Back in Visual Studio, debug>attach to process and find and attach to the W3WP Process on the remote server that matches the process identified above.
Open the modules pane by typing CTRL+ALT+U
Look through the modules, and you should find your Sharepoint solution and see that VS cannot open its PDB (and breakpoints will not be hit)
Make a note of the path, in this case:
C:\Windows\assembly\GAC_MSIL\SharePointProject4\1.0.0.0__bf506a3a24d83b2c\SharePointProject4.dll
Sharepoint stores deployed Full Trust .dlls in the GAC.
A little trick here: in order to navigate the GAC as a normal folder structure, MAP A NETWORK DRIVE on your development system to \\SERVER\C$\Windows\assembly. Go through the mapped drive, and find the install location mentioned above (eg “GAC_MSIL\SharePointProject4\1.0.0.0__bf506a3a24d83b2c\SharePointProject4.dll”). Copy your .pdb file here
Now right click on the module in the module pane and select Load Symbols From>Symbol Path
Once you’ve done this, your breakpoint should become “hittable” and the symbols shown as “Loaded”
Reload the web page, and boo-yah X 2, you’re debugging remotely!
A few lingering issues
Does the .pdb *REALLY* have to go in the GAC?
I’ve read elsewhere (eg: here) that you don’t have to put the .pdb in the GAC. I haven’t been able to get it to work, however. If anyone has more info on this, I’m all ears.How about updates to my solutions?
For Full Trust solutions, I believe that simply replacing the .dll and .pdb in the GAC will get you there… Haven’t done enough yet to know otherwise. You could be more thorough and:Uninstall-SPSolution -Identity "SharePointProject4.wsp" -WebApplication "http://RemoteSPInstallName/"
Remove-SPSolution -Identity "SharePointProject4.wsp"in powershell_ise
For Sandbox Solutions, I go through the UI and remove and add through the Solution Gallery
Tell me more
If you have any question, corrections, or comments, be sure to post them belowcheers