On my current SharePoint/InfoPath project, we’re using NAnt to deploy absolutely everything. NAnt creates SharePoint pages, imports web parts to pages, activates SharePoint features, deploys assemblies, creates SharePoint lists, creates/updates SQL databases (via DBDeploy), packages and deploys InfoPath forms, copies XSLT/XML/ASPX files, and much much more.
I always boast about how when a new developer comes on the project, he/she can have a fully operational SharePoint development environment within minutes. This is an important achievement, as most SharePoint Developers know it can be painful to automate deployments to SharePoint sites.
This works great for a Development environment, but what happens when you need to deploy to Production? Some companies don’t allow NAnt to be executed directly in Production, so you’ll need to setup your NAnt build files to execute on a build server to prepare for a Production deployment.
To achieve this, I went back into my NAnt build file and updated my NAnt targets to allow for the “preparation” of a deployment rather than actually performing the deployment. This provides us the ability to run NAnt on a build server in order to package everything for an easy automated deployment in Production (without NAnt).
I’m leveraging Windows Installer XML (WiX) in order to package the deployment files into MSI packages (In a future post I’ll get into more detail about using WiX MSI’s for SharePoint deployments). For SharePoint feature installation/activations and InfoPath form deployments I’m generating a batch file from NAnt that gets packaged into the MSI and executed when the MSI is installed on the server.
First we prepare the batch files – this will create 3 new empty batch files with a line “ECHO OFF” inside them:
1: <target name="PrepareBatchFiles">
2: <echo file ="${featuresDeployment.cmd}" append="true" message="ECHO OFF" />
3: <echo file ="${formsDeployment.cmd}" append="true" message="ECHO OFF" />
4: <echo file ="${dataConnectionsDeployment.cmd}" append="true" message="ECHO OFF" />
5: </target>
Next, we append STSADM calls to the batch files – anytime we call STSADM from NAnt, we will add a row into the batch file. Here’s an example when we’re calling the “UploadForm” NAnt target:
1: <target name="UploadFormTemplate" description="Uploads an InfoPath Form">
2: <choose>
3: <when test="${prepareDeployment=='true'}">
4: <echo file="${formDeploymentBatchFile}" append="true" message="echo Attempting to upload form template '${formName}.xsn'" />
5: <echo file="${formDeploymentBatchFile}" append="true" message="${stsadm.exe} -o uploadformtemplate -filename "${deploymentFolder}\Forms\${formName}.xsn"" />
6: </when>
7: <otherwise>
8: <exec program="${stsadm.exe}">
9: <arg line="-o uploadformtemplate" />
10: <arg line="-filename "${publishedFormsFolder}${formName}.xsn"" />
11: </exec>
12: </otherwise>
13: </choose>
14: </target>
You can see from the NAnt target above that it checks whether we’re “Preparing” a deployment or if we’re actually deploying. If we’re preparing the deployment, it will generate batch files and copy files to a deployment folder. I’ve added the “choose –> while” condition into each NAnt target so that I can prepare my deployment files for the MSI.
The generated batch file will look something like this:
1: SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.exe
2: ECHO OFF
3: "%STSADM%" -o deactivateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"
4: "%STSADM%" -o removeformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"
5: "%STSADM%" -o execadmsvcjobs
6: ECHO Attempting to upload form template 'MyInfoPathForm.xsn'
7: "%STSADM%" -o uploadformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"
8: "%STSADM%" -o execadmsvcjobs
9: "%STSADM%" -o activateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"
Now when I add a new form to be deployed, it will be automatically added to the batch file for the Production deployment. The end result is that I can run my NAnt scripts on a development environment to actually deploy my SharePoint components, or I can run the same batch scripts on a Production server via an MSI package.