12.20.2007
Introducing SPDeploy 

image_thumb SPDeploy is a tool that allows developers to create SharePoint customizations inside Visual Studio, then package and deploy those changes to a remote SharePoint server. With SPDeploy you can create a project that contains SharePoint customizations and deploy those customizations to a remote SharePoint server in 10 minutes or less. SPDeploy consists of an MSBuild extension and a Visual Studio Project template.


Download SPDeploy Now

Features
  • SharePoint Solution Package (WSP) Compilation
    SPDeploy examines your project files and creates a SharePoint Solution Package (WSP). The manifest.xml is dynamically created based on the files that exist in the project. If you add a file, that file is automatically added to the WSP and deployed to SharePoint.
    Benefits:
    1. Provides single distribution file that can be deployed via standard SharePoint tools (stsadm). This makes deploying to QA, Staging and Production trivial. Third party executed deployments are also made very simple.
    2. Since the WSP file is excercised during development, you can be assured that deploy is not an issue when deploying to other environments.
  • Remote Deployment & Developer Isolated Environments
    SPDeploy is able to remotely deploy the compiled WSP file to a SharePoint server. This is important for several reasons:
    1. All source code is housed and maintained via source control. All customization must be contained within the WSP file which means they are a part of your project which in turn can be committed to source control. This alleviates the need to migrate a SharePoint content database from development to QA to Production.
    2. Allows multiple developers to work on a single project and deploy to a separate and distinct environment avoiding clashes and breaking changes that typically occur when developers attempt to deploy customizations to a single SharePoint development environment.
    3. Deployment takes place from inside Visual Studio. SPDeploy allows you to push you WSP through the entire WSP lifecycle (Add, Deploy, Upgrade, Retract, Delete). This allows you to focus on writing code instead of the minutia of deploying your WSP.
    4. Most importantly SPDeploy puts you, the developer, in complete control of your customization and how they are deployed.

      image_thumb_3

    Information direct from the readme.txt:

    Overview
    ========

    SPDeploy extends MSBuild to include targets that allow you to create a SharePoint solution file (.wsp) from a standard C# class library project inside Visual Studio 2005. In addition, SPDeploy allows you to deploy your newly compiled wsp file to a remote SharePoint server. This allows you to develop locally and deploy to SharePoint remotely.

    Benefits of wsp compilation and remote deployment:

    1. All source code is housed and maintained via source control. All customization must be contained within the wsp file which means they are a part of your C# project which in turn can be committed to source control. This alleviates the need to migrate a SharePoint content database from dev to QA to Production.

    2. Provides single distibution file that can be deployed via standard SharePoint tools (stsadm). This makes deploying to QA, Staging and Production trivial. Third party executed deployments are also made very simple.

    3. Allows multiple developers to work on a single project and deploy to a separate and distinct environment avoiding clashes and breaking changes that typically occur when developers attempt to deploy changes to a single SharePoint development environment.

    For more information on SharePoint Solution files see http://msdn2.microsoft.com/en-us/library/aa543214.aspx

    Installation
    ============

    1. Install the msbuild extension. Copy the SPDeploy folder located in this zip file to your MSBuild extensions directory. For a standard installation this directory is located at c:\program files\msbuild.  The MSBuild extension directory is located at <program files>\msbuild where <program files> is your default program files directory on your system drive. The final path to the SPDeploy targets file should be <program files>\msbuild\spdepoy\v1\spdeploy.targets

    2. Install the Visual Studio Project Template. Copy the SPDeploy_Template.zip file to your Visual Studio project template directory located at <My Documents>\Visual Studio 2005\Templates\ProjectTemplates

    Creating a Project
    ===========================

    1. Inside Visual Studio, click file -> new -> project -> visual c# -> SPDeploy.

    2. Add user specific settings to SPDeploy.user. Open SPDeploy.user under the properties directory. Setup the WspServerName, WebApplicationUrl and WebApplicationOwnerEmail property values. These properties should contain the server name where the wsp is to be deployed and the url of your deployment web application.

    3. Setup manifest.xml GUID. Open the manifest.xml in the root directory of the project, and add a GUID to the SolutionId attribute. To create a guid go to tools -> create guid -> copy, then paste into the SolutionId attribute.

    4. Setup manifest.xml assembly. Inside the manifest.xml uncomment the assemblies element and add the name of your assembly to the Location attribute of the Assembly node. This will ensure your assembly is deployed to the GAC as a part of the wsp deployment.

    5. Strongly name your assembly. Right click on the project -> properties -> signing. Click "sign the assembly". Select a new key and give it a name.

    6. Build the project.

    7. Execute the CreateWebApplication target. See Executing SPDeploy below for more details.

    8. Execute the AddWsp target to add the wsp to your server.

    9. Execute the DeployWsp target. Your wsp file will now be deployed to the farm and all customization are available.

    10. Execute the CreateSite target. This will create a top-level site inside your web application.

    About SPDeploy.user
    ===================

    The SPDeploy.user file defines properties that are specific to your project and to the developers working on your project. These properties are consumed by the SPDeploy msbuild extension. At minimum you must override the WspServerName and WebApplicationUrl properties but you can override any property you like.

    You can also specify properties conditionally based on the executor's username. This allows for isolated and independant environments per developer.
    For example:

        <PropertyGroup Condition="$(USERNAME) == 'clints'">
            <WspServerName>dev-clints-wss</WspServerName>

            <WebApplicationUrl>http://$(WspServerName):88</WebApplicationUrl>
            <WebApplicationOwnerEmail>clints@ascentium.com</WebApplicationOwnerEmail>
        </PropertyGroup>

        <PropertyGroup Condition="$(USERNAME) == 'johnl'">
            <WspServerName>dev-johnl-wss</WspServerName>

            <WebApplicationUrl>http://$(WspServerName):81</WebApplicationUrl>
            <WebApplicationOwnerEmail>johnl@ascentium.com</WebApplicationOwnerEmail>
        </PropertyGroup>

    Executing SPDeploy
    ==================

    Supported Targets: ComileWsp, AddWsp, DeployWsp, UpgradeWsp, RetractWsp, DeleteWsp, UpgradeIncremental, UpgradeIncrementalFiles, UpgradeIncrementalAssembly, CreateSite, DeleteSite, CreateWebApplication, DeleteWebApplication

    You can execute these targets via the command prompt from the project directory like so:
    msbuild /target:<target name> <project name>.csproj

    Where <target name> is the msbuild target such as AddWsp or DeployWsp and <project name> is your project's name.

    To add visual studio support for launching these targets import the included SPDeploy.vssettings file into visual studio by going to tools -> import/export settings. This will add external tools items that are located under the tools menu in visual studio. You can also customize this further by creating a toolbar or menubar for these tool items.

    WARNING: Importing these settings with override all external tools settings inside visual studio.

    Remote Debugging
    =================
    Remote debugging can be problematic and somewhat tricky as most people have found. Here is the technique that works for me.

    1. Attach to the remote process. From your dev local machine inside Visual Studio go to Debug -> Attach to process. Change the qualifier field to your remote server name, pick ALL the w3wp.exe processes and click attach. At this point you may run into issues around firewalls, dcom, etc. See http://support.microsoft.com/kb/910448

    2. Ensure that your pdb symbols file has been loaded.

    Open the modules window while in debug mode to ensure that the symbols for your assembly are loaded. This window is notoriously hard to find, here's how I do it: Right click on a toolbar and go to customize. In the left pane choose debug, then drag the modules icon from the right pane onto a toolbar. Close the customize dialog and click on the module icon. You will now have the modules window open and you can scroll to find your assembly.

    If your assembly's symbols are not loaded, right click on the modules window and choose symbols settings. Now make sure that the spdeploy temporary folder is in the list, the spdeploy temporary folder is where spdeploy copies assemblies, PDBs and WSPs when deploying to your remote server. The temporary directory is located at \\<remote server name>\c$\_spdeploy\<project name>. Make sure this path is visible in the symbols setting dialog and that the checkbox next to it is checked. Now close the symbol settings dialog.

    In the modules window you should now see that the symbols for your assembly are loaded and your breakpoints are working.

    Team Build
    ==========

    Team Build is supported and wsp compilation works as normal. You will need to install the SPDeploy extensions on the Team Build server as descibed in this document. After a team build is executed, you should see the compiled wsp inside the output folder along with the assembly.

    NOTES
    =====

    - References to your project are compiled into WSP when the "Copy Local" attribute is turned on for the reference. To change this attribute, right click on your reference in visual studio and select properties. Then change the value of the "Copy Local" attribute.

    - Your development machine must be on the same domain as your SharePoint server.

    - makecab.exe must be in your DOS path for the wsp compilation to work. To make sure that makecab is in your path, open a command prompt and type makecab.exe

    - When loading an SPDeploy extended project you may receive a security warning stating that the project file has been customized. Choose "Load Project Normally". This is an issue that I am actively trying to resolve.

    - The SPDeploy project template is based on the ASP.net web application project type. You will need to have Visual Studio 2005 SP1 install so that this project type is available.

    Feedback
    ========

    If you have comments, suggestions or requests please email me at clints@ascentium.com

    posted at: 3:35 PM by Clint Simon
    Comments
    Saturday 12/22/2007 12:31 PM by anonymous
    This is brilliant stuff! I've got a feature working which has a custom aspx page (PageTemplate.aspx) which has a different "name" (whatever.aspx). However, if I try to add *another* aspx page, I get a "Webpage cannot be found" error when trying to access it. I've added the extra File element to the Module element in the elements.xml for the feature too. Do you know why this might be? Thanks!!!
    Saturday 12/22/2007 12:33 PM by george bonney
    Hi, great tool. I had a quick look and couldn't see how I might integrate a number of other projects into the output ... is this something that is possible, e.g. other assemblies?

    thanks.
    Saturday 12/22/2007 12:33 PM by Clint Simon
    If you add references to you project, the referenced assembly will automaticaly be added to the WSP file if the "Copy Local" attribute is set to true on the reference. "Copy Local" is set to true by default.

    If you'd like to deploy the referenced assembly as a part of the wsp you'll need to add an assembly node to the manifest.xml in the project that refers to the referenced assembly.

    Hope that helps! Let me know if you have any other questions.
    Tuesday 1/22/2008 4:10 AM by carlos
    Will you publish the source code? Example at codeplex.com

    It would be very valuable for the MOSS community

    Best Regards
    Friday 1/25/2008 12:36 PM by wali
    Great utlity! This is exactly I was looking for. One question:


    What permission is required to deploy .wsp package on remote server? Does user need to be remote server Admin or Farm Admin?
    Monday 1/28/2008 3:34 PM by Clint Simon
    You need to be a local administrator on your remote sharepoint server and you will need to be a farm admin if you want to run "create webapplication" or anything else that requires farm admin priveleges.
    Monday 2/4/2008 6:50 AM by Robert
    Thank you for that tool! It saves me heaps of work!
    However, since I added my Project to SVN I can't compile the wsp anymore, because it tries to link all the .svn-Files to the project. Is there any way to exclude certain files and folders?

    Cheers,
    Robert
    Monday 2/4/2008 1:37 PM by Clint Simon
    I am not that familiar with subversion but I am sure that there must be a way to exclude local file from source control. Maybe these links would help?

    http://svn.haxx.se/users/archive-2005-09/0354.shtml
    http://sdesmedt.wordpress.com/2006/12/10/how-to-make-subversion-ignore-files-and-folders
    Tuesday 2/5/2008 12:36 AM by Robert
    SVN creates files and folders (_svn, .svn, entries...) inside the project directory. All these files are automatically being included in the *.ddf and later in the solution file by SPDeploy.
    Since there are many duplicate files in the *.ddf afterwards, I am unable to create the wsp-file.
    Now I would like to exclude certain files and folders from the deployment mechanism.
    Tuesday 2/5/2008 9:46 AM by Clint Simon
    Hi Robert, I think I understand your problem now :)

    I am not sure of your familiarity with msbuild but here is a workaround:

    1. Open the SPDeploy msbuild extension file at c:\program files\msbuild\spdeploy\v1\spdeploy.targets.

    2. Find the WspSourceRootFiles item group, for the exclude attribute you will need to add a wildcard such that all the svn files/directories are excluded, it should look something like this:

    Exclude="$(BaseRootFilesDir)\**\*.cs;$(BaseRootFilesDir)\**\*svn*\*.*"

    I am not sure if this expression will work so you will probably need to experiment a bit.

    3. Repeat step 2 for the WspSourcetemplateFiles item group.

    When you get this working can send me your SPDeploy.targets file? It would great if I could incorporate this back into the SPDeploy release. Thanks!
    Tuesday 3/4/2008 5:46 AM by Edward Wilde
    Is there any intention to share the source of this project on CodePlex or equivalent ?
    Wednesday 4/16/2008 2:58 AM by Hung Mai
    Hi Clint,

    I found alot of interesting when using SPDeploy. And I took an example on create a web part using SPDeploy template. I followed your instructions but I got some problem.

    I do not run CreatWebApplication target, but I run sucessfully both AddWsp and DeployWsp target.

    And I could not see my webpart in the webpart gallery.

    Do you have any idea on that?

    Thanks alot,

    Cheers
    Hung
    Add a New Comment
    Name

    Email Address
    Url

    Comment
    Blog Search
    Keywords:
    Author:
    Posted Between ...
    and ...
    Archive by Month
    Archive by Author
    © 2009 Ascentium Corporation. All rights reserved.