MSDN Magazine - March 2008 - (Page 38)

Figure 7 DebugBuild Build Target XML formatted in a structure similar to that shown in Figure 6. As you can see, MSBuild requires a top-level Project element. Within the Project element there are child elements such as PropertyGroup and Target. Note that the PropertyGroup section at the top of Microsoft.SharePoint.targets is used to track metadata and values like the path and name of files that are needed within individual target commands. You can see that Microsoft.SharePoint.target tracks the file name of the output solution package as well as the fully qualified file path to utilities such as MAKECAB and STSADM. These is also a property that tracks the local file path to STSDEV itself so that command targets are able to call into the STSDEV utility and execute the RefreshDeploymentFiles command. Now let’s look at a few of the build targets. I will start by examining the commands defined inside the build target named DebugBuild, shown in Figure 7. As you can see, the first command inside the DebugBuild target is the one that calls into STSDEV and passes the /refresh parameter to run the RefreshDeploymentFiles command. This causes the STSDEV utility to regenerate manifest.xml and SoutionPackage.ddf as the first part of the solution package build process. Af- ter that, there is an MSBuild command executed to delete any existing .wsp file and to rebuild the solution package using the MAKECAB.EXE utility. You should also note the use of Message commands, which are used to display informational messages to the developer inside of the Visual Studio output window while the commands are running. The DebugInstall command has been written to use the addsolution operation supplied by STSADM to install the newly generated solution package .wsp file into the solution package store of the local farm. Also note the use of the DependsOnTargets attribute, which will first run the DebugBuild target commands anytime the DebugInstall target is executed: Many of the operations exposed by the STSADM utility are run asynchronously using timer jobs. Therefore, there is another call to STSADM to run the execadmsvcjobs operation. This operation causes the command to pause and wait until the local SharePoint Web server has been able to run all pending timer jobs to completion. The execadmsvcjobs operation is also called in the DebugDeploy target directly after calling the deploysolution operation: Figure 8 Executing an STSDEV-Generated Build Target Now that you have seen the different custom build targets that exist within the Microsoft.SharePoint.targets file generated by the STSDEV utility, you need to know how to execute them from within the Visual Studio environment. It’s very simple. You simply select the Visual Studio configuration associated with the desired build target and run the standard Visual Studio build command, as shown in Figure 8. The MSBuild technique that is being used to wire up these custom build targets requires adding a Target element into the Visual Studio project file (for example, HelloWorld.csproj). This is something that STSDEV does automatically anytime you create a new solution. If you open up one of the .csproj files and look at the bottom, you will see a Target section that looks like Figure 9. You should notice that the Target section has a name of AfterBuild. This is a well-known target name that Visual Studio automatically runs at the completion of every build. This makes it easy for you to add one CallTarget command per build target with a condition to execute the appropriate custom build target depending on the configuration that has been selected. 38 msdnmagazine Office Space

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.