Using the TFS Build Process to Deploy Sharepoint Custom Applications, Page 3
Walk through the build definition. The sample build definition is called Daily Build. A nice feature is the Retention policy that automatically allows you to set how long to keep your different states of builds. For instance, for failed builds, you can keep all of them, or the last two. The same goes for Successful builds, and partially completed builds. In the Trigger tab, make sure to fill out how often you want this build to run. Because it's a daily build, I would select Monday–Friday at a later time, say 3:00 AM, or another time when most developers won't be working on the source. After filling the wizard out, you click OK, and an XML build file is created for you.
In the case of your sample application, the build file called TFSBuild.proj is located in the subdirectory that holds the Build Definitions. To deploy the right files to the correct directories on the Sharepoint server, you need to add some XML tags to the build project file, TFSBuild.proj. To do this, open your source control explorer. Navigate to the Team Build Types node of your workspace, and find the "Daily Build" folder. In this folder is the TFSBuild.proj file. I edit this file by doing a get latest, and then check out and double-click on the file in Source Control explorer.
When that file is open, you want to add some tasks to run after TFS completes its build activities, but before the agent exits. To do this, you will use the "AfterEndToEndIteration" target name in the .proj file. This is an event that the TFS build process looks for and that can be overwritten. See Listing 1 for an idea of what this might look like.
<Target Name="AfterEndToEndIteration"> <Copy SourceFiles="$(BuildDirectory)\Binaries\Debug\ Eric.Landes.Sharepoint2007.AdventureWorksSample. AWWebParts.dll" DestinationFolder="C:\Inetpub\wwwroot\wss\ VirtualDirectories\36917\bin"> </Copy> <Copy SourceFiles="$(BuildDirectory)\Binaries\Debug\ Eric.Landes.Sharepoint2007.AdventureWorksSample.AW_Dal.dll" DestinationFolder=" C:\Inetpub\wwwroot\wss\ VirtualDirectories\36917\bin"> </Copy> <Copy SourceFiles="$(BuildDirectory)\Binaries\Debug\ Eric.Landes.Sharepoint2007.AdventureWorksSample. AWObjects.dll " DestinationFolder=" C:\Inetpub\wwwroot\wss\ VirtualDirectories\36917\bin "> </Copy> <Copy SourceFiles="$(BuildDirectory)\Binaries\Debug\ _PublishedWebSites\AWWebParts.ascx " DestinationFolder="C:\Inetpub\wwwroot\wss\ VirtualDirectories\36917\usercontrols "> </Copy> </Target>
For this example, you have copied the correct DLLs from the build directory (that's a built-in variable) to the destination directory. For clarity, this sample XML shows the directory you copy the files to. Use best practices in real life by utilizing variable names for the from and to directory names to keep your script flexible.
Now, you can run the build file. To test the build, in Team Explorer, find the Daily Build build definition, by expanding your workspace. You can start a build by right-clicking on that build node and selecting "Queue New Build." Once the build successfully completes, you should see the Eric.Landes.Sharepoint2007.AdventureWorksSample.AWObjects.dll in the directory \Inetpub\wwwroot\wss\VirtualDirectories\36917\bin. And then, you can see the User Control AWWebParts.ascx in the directory C:\Inetpub\wwwroot\wss\VirtualDirectories\36917\usercontrols.
Now, to view the web part, add the Smart Control web part to a web page in your Sharepoint site. Configure Smartpart to display the AWWebparts User control. Violà, your web part is now displaying in Sharepoint. Now make some changes to the web part, rerun your daily build, and validate that your changes have been deployed to the page you just made.
Download the Code
Click here for the source code to this article. This is a large (1 Mb) file.
You have just automatically deployed your Sharepoint application using TFS as your build tool. Sharepoint can have some tricky differences in deployments (location of files, for instance) from a standard ASP.NET web application deployment. Despite those differences, you can automate your Sharepoint applications, just like your ASP.NET applications, and use these standard software engineering practices on your Sharepoint applications.
I went over a few of the advantages TFS gives you in deployment, the ease of setting up scheduled deployments, and the tight integration with VSTS.
About the Author
Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in developing custom Sharepoint applications. He has two years experience using Agile techniques in developing Sharepoint applications. See his linked in profile for more information.
Page 3 of 3