Using the TFS Build Process to Deploy Sharepoint Custom Applications, Page 2
Because this is not an article just about the merits of TFS, I won't go into every advantage listed. I will concentrate on the ease of setting up your builds, and extending those builds by using MSBuild coupled with the TFS build engine. Keep in mind that this article is based on using Visual Studio Team System as the IDE in conjunction with TFS. You can use other IDEs with TFS, but that is an entirely different article! This article sticks with the VSTS/TFS development combination.
The Application to Deploy
Sharepoint custom application deployment is not as straightforward as deploying an ASP.NET application. Sharepoint custom web parts get their configuration keys from the web.config in the Sharepoint web root. This makes automated deployment a little clunky when sharing that web.config with other custom web parts/applications.
You are going to concentrate on creating a build for a custom web part. Other areas that are tricky include deploying Sharepoint features. I may tackle that issue in another article.
The sample source code includes a Visual Studio solution with the custom object model project, a Data Access Layer (DAL) project, and the Web Parts project that utilizes those. Also, the solution includes a Unit Testing project.
The Sharepoint server you will deploy your custom application to utilizes Jan Tielens' smartpart. The Smartpart allows developers to develop standard ASP.NET user controls, and place them as web parts in your Sharepoint sites. User Controls allow you to design your interface more easily when programming. You can use ASP.NET web parts projects to create web parts, but I have found the Smartpart control easier to develop applications with.
When you deploy a Smartpart application, you will need to at least deploy your ASCX files to a User Controls directory and your DLL to the bin directory in Sharepoint. You may find a need to deploy your DLL to the GAC as well. Assume that your Sharepoint site, http://localhost: 36917, is the Sharepoint site you want to deploy your web part to. The actual directory to deploy to would look something like this: "C:\Inetpub\wwwroot\wss\VirtualDirectories\36917". See Figure 2 for a better look.
Figure 2: Sample of how your Sharepoint directory might look like if it is on the C drive.
Your application is called AWWebParts. This application utilizes the AdventureWorks database that is available with SQL Server 2005. Therefore, the AW is part of most of these assembly names! The full assembly name is Eric.Landes.Sharepoint2007.AdventureWorksSample.AWWebParts.dll. You will need to deploy that assembly and the AWObjects and AW_DAL assemblies to the bin directory under the Virtual directory for Sharepoint.
That's the application you are deploying. I also went over how you would manually deploy the different parts of the application after compilation. But, doing this manually does not give you a consistent, repeatable deployment that current software engineering disciplines demand.
Creating the Automated Build
Remember, you have a Visual Studio solution that includes four different projects. You want to deploy the DLLs from three of the projects. Because you have created some unit tests testing your business objects against mock objects, you want to run those tests. This article assumes that your builds want to run your mock objects tests, and verify they still pass, before you deploy your application.
I mentioned earlier that the Daily build can include longer running tests. I haven't included longer running tests in your Unit Tests for this sample; you only run mock object tests. In VSTS, you created a test list called Mock Objects. Oddly enough, the Mock Objects test list only includes tests that run against mock objects! You do not include tests that would run against a real database. For the mock object testing, you are using the open source mock framework moq.
Now, step through creating the build first by utilizing a wizard. You open the build wizard, by going to team explorer, and in the workspace for this project, right-click on builds and select "New Build Definition." This brings up a screen similar to Figure 3.
Figure 3: What the New Build Definition looks like.