Just ran into an interesting unconventional occasion for the current client I'm consulting with. For some company network policy reason, we are not allowed to do any development on the staging environment, not to mention, they don't even have a in-house development environment for us to deploy the WSP package to it directly by Visual Studio 2010.
It's not a huge deal of it, but the time-consuming bit is that we couldn't leverage the VS2010 integration development benefit to deploy the WSP or any feature to SharePoint 2010 farm/web/site/website through the integration environment. Instead, we have to go back to MOSS2007 old way to remote debug the development module from the local to the server.
Well, the following steps and hoops listed below is the approach I set up in order to get my environment ready to roll: (P.S. my local development environment is 32bit Windows XP operation System)
- Build a SharePoint2010 environment virtual machine (you know the drill otherwise you won't be here in the first place).
- Install VS2010 on the local machine (32bit), ideally, get the SharePoint 2010 SDK installed as well, which benefits you later on for sure.
- Export the hive [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0] from the virtual machine and install on the local machine.
- Copy all the files under (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\UserCode) from SharePoint 2010 to Visual Studio 2010
- Create an empty SharePoint 2010 project and reference 2 dlls back into the SharePoint solution file (Microsoft.SharePoint, Microsoft.SharePoint.Security) if this Visual Studio 2010 machine doesn't have SharePoint environment setup.
- Modify the project property (Build tab -> Platform target: x64), then fully ignore the build warnings (something like, it has switched to the different platform) It only displays this error if the local Visual Studio 2010 machine doesn't have 64bit enviornment, which is exactly what's happening on my-end.
- Run the command:
add-spsolution -LiteralPath "c:\solution\PackageFileName.wsp" add-spsolution -LiteralPath "c:\solution\ListPortalUsers.wsp"
install -spsolution -Identity "PackageFileName.wsp" -GACDeployment -WebApplication "http://RemoteSPInstallName"
To deactivate a Feature, run the following Windows PowerShell command using SharePoint Management Shell: a. retract solution
Uninstall-SPSolution -Identity -WebApplication
b. remove solution from farm
- Turn on the development dashboard to display the debugging traces. Using stsadm, you can run the following command to configure the Developer Dashboard:
STSADM –o setproperty –pn developer-dashboard –pv OnDemand
- SPMonitoredScope doesn't seem working on the remote Visual Studio stations (bomber!), but the rest seems all being up-running as intended.
As mentioned earlier, it's not the ideal development environment for SharePoint 2010 custom build, by which inevitably you lose a lot of built-in functionality you could simply pull off from VS2010 SharePoint project, not to mention, that time-consuming. However, if that's the client's corporate policy, I guess, that's the best solution I could come up with so far.