Catálogo de publicaciones - libros

In this chapter, we talked about the various types of applications and application architectures. It is important for build and deployment engineers to be familiar with what they are going to be building and deploying. This knowledge comes in handy after you do a build or a deployment and have to verify that it was successful.

We also talked about distributing the .NET runtime. In the next chapter, we will start the multichapter coverage of Microsoft’s new build engine (MSBuild).

In this chapter, we discussed what build tools are and why they are now a required component in the software development life cycle. We also introduced Microsoft’s new build tool, MSBuild. We covered all of the key elements that you need to start customizing your builds using MSBuild. For the next few chapters, we will build on this foundation so you can extend your build process to suit your needs. In the next chapter, for example, we will show MSBuild in action. You will see many examples of using MSBuild to help you comprehend some of the difficult-to-understand features and to provide more of a concrete basis on which to further build.

In the previous chapter, we introduced some fundamental concepts of MSBuild and showed some examples of how you can use MSBuild. In this chapter, we expanded on that knowledge extensively by showing a series of examples. The aim of this chapter was to clarify the topics discussed previously and to introduce many new ideas. As is the case with many other technologies, MSBuild is best learned by trying the concepts as you learn them.

In this chapter, we presented the two most extensible aspects of MSBuild: custom loggers and custom tasks. We discussed how you can hook into the MSBuild logging process to create your own logger that meets the specific needs of your application if necessary. We covered how to create custom tasks to perform steps unattainable from existing MSBuild tasks. During this, we also discussed incremental building and how you can create targets and tasks that support it. We showed how to cleanly extend the build and clean process that MSBuild currently has in place. With these tools, you should be able to customize the build to meet the needs of your applications. All of the source code for this chapter is available in the Source Code section of the Apress Web site (http://www.apress.com). For brevity reasons, some details of that code could not be covered; for more information, see the source files.

In this chapter, we introduced many new topics, the most important being Team Build.Team Build is flexible because it is built on top of MSBuild. Also, you can reuse your knowledge of MSBuild to fine-tune your team build process. Covering the new topics that were addressed here in great detail is outside the scope of this chapter, but it certainly has given you a starting point to creating a solid public build on which your team can rely.

If you are working on enterprise applications, then it is essential that scheduled, automated builds are part of your process. By using TFS and Team Build, you are able to do this simply and easily. Not only is it easy to create an automated public build process, but it also integrates with the other components available in Visual Studio. You no longer have to rely on hooking up many different third-party tools to achieve this.

The focus of this chapter was ClickOnce, which is a technology that ships with the .NET Framework 2.0 and is used to autodeploy and update Windows Forms and console applications. ClickOnce supports three sources for where a ClickOnce application can be deployed. They include aWeb server, a file server, and some form of removable media (such as a CD).

ClickOnce is amajor improvement over the previous approaches to deploying rich client applications. ClickOnce has a rich and configurable deploy, update, and security policy. Moreover, you can use the ClickOnce APIs to customize your deployment solutions.

This chapter was a tour of ClickOnce. In the next chapter, we will go into great detail about the concepts discussed here. Furthermore, we’ll identify what ClickOnce can’t do and how to work around that.

In this chapter, we presented the two most extensible aspects of MSBuild: custom loggers and custom tasks. We discussed how you can hook into the MSBuild logging process to create your own logger that meets the specific needs of your application if necessary. We covered how to create custom tasks to perform steps unattainable from existing MSBuild tasks. During this, we also discussed incremental building and how you can create targets and tasks that support it. We showed how to cleanly extend the build and clean process that MSBuild currently has in place. With these tools, you should be able to customize the build to meet the needs of your applications. All of the source code for this chapter is available in the Source Code section of the Apress Web site (http://www.apress.com). For brevity reasons, some details of that code could not be covered; for more information, see the source files.

In this chapter, we introduced many new topics, the most important being Team Build.Team Build is flexible because it is built on top of MSBuild. Also, you can reuse your knowledge of MSBuild to fine-tune your team build process. Covering the new topics that were addressed here in great detail is outside the scope of this chapter, but it certainly has given you a starting point to creating a solid public build on which your team can rely.

If you are working on enterprise applications, then it is essential that scheduled, automated builds are part of your process. By using TFS and Team Build, you are able to do this simply and easily. Not only is it easy to create an automated public build process, but it also integrates with the other components available in Visual Studio. You no longer have to rely on hooking up many different third-party tools to achieve this.

In this chapter, we discussed three important tools related to ClickOnce. We talked about the Bootstrapper Manifest Generator (BMG), the Manifest Generation and Editing (MAGE) tool, and MSBuild. All of the discussions in this chapter related to practical problems. For example, we showed how you can use the BMG tool to quickly create the product and package XML files needed to create custom prerequisites. The discussions about the MAGE tools gave four practical scenarios where the MAGE tool can be useful, and the discussion of MSBuild showed how to automate the generation of a ClickOnce deployment. All of these tools will be useful as you work with ClickOnce. The last portion of this chapter talked about some practical ClickOnce scenarios.