Project Description
Strives to improve SharePoint development experience by automating remote WSP, GAC, and file asset deployment operations as well as simplifying cross-domain remote debugging experience.

Building upon the conveniences brought upon by WSPBuilder, this project provides a Visual Studio -integrated client and a service running on a target WSS/MOSS server. The project intends to facilitate the process of local workstation-based SharePoint development paired with simplified build, remote deployment operations for WSP files and remote debugging. While developing from a workstation running only Visual Studio 2008 and a local copy of WSS/MOSS DLLs, a developer has the option to deploy iteratively onto any SharePoint server enabled with the WssDeploy service. The target SharePoint server may be running in the context of a VM guest hosted locally/remotely or on an actual physical server. This bring about the following benefits:
  • Improved developer experience by having a more responsive Visual Studio;
  • Faster SharePoint app pool reset / pregnant load cycles.
  • Simplified multi-project development environment maintenance as only a single Visual Studio setup needs to be configured to push to multiple separate environments;
  • Reduced burden in setting up remote debugging by cutting out a number of manual steps involved in preparing the remote server for a debugging session (starting / stopping the debugger service).
The following actions are supported:
  • Build & Remotely Deploy a WSP;
  • Deploy assembly to a remote GAC;
  • Deploy a file to a remote server;
  • Reset app pools remotely;
  • Remote debugging automation by copying DLLs to a target server; resetting app pools; putting PDB files side-by-side with assemblies (in GAC).

Brief installation instructions
1) Install a client Visual Studio add-in package in 32 or 64 bits depending on your OS.
  • As a part of the installation, the installer will also deploy a console version of the WSPBuilder project with appropriate CabLib DLL for your platform.
2) If remote debugging is required, install appropriate VS 2008 Remote Debugger components for your architecture onto the target server

3) Deploy server package onto the target server
  • Provide service credentials to the installer for an account that will be used to run the WSP Deploy service under.
  • The account has to be in the Local Administrators group on the target server.
  • In single-server developer environments (WSS/MOSS and SQL running on the same box) the service identity can be changed to Network Service in the service manager. The installer does not support this as an option yet, however, the scenario of the service running under Network Service has been verified as working.

Post Installation Configuration
Using the default installation method of the service installer, the service is setup using netTcpBinding and is hosted within a custom Windows OS service. The service is listening by default on port 9000 for command and 9001 for MEX requests. This default installation method is sufficient for most environments wherein client communication with the service is not obstructed by firewalls and also where support for remote debugging is desired. To support more advanced deployment scenarios, rel 1.3 is introducing support for HTTP transport using basicHttpBinding and wsHttpBinding.
Note: Running in this configuration will preclude remote debugging and may introduce a number of security risks should the service functionality be exposed to public segments of the net with weak security.

Last edited Mar 22, 2012 at 1:13 PM by valorekhov, version 16