Supplement to Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
Sayed Ibrahim Hashimi
William Bartholomew
Published by Microsoft Press
I would like to dedicate this book to my parents Sayed A. Hashimi and Sohayla Hashimi. Without them I wouldnt be here to write this book.
S AYED
I dedicate this book to my parents Rosanna OSullivan and Roy Bartholomew for their unending support and to Lauren Taylor and Jillian Bartholomew for the joy they bring each day.
W ILLIAM
Special Upgrade Offer
If you purchased this ebook directly from oreilly.com, you have the following benefits:
DRM-free ebooksuse your ebooks across devices without restrictions or limitations
Multiple formatsuse on your laptop, tablet, or phone
Lifetime access, with free updates
Dropbox syncingyour files, anywhere
If you purchased this ebook from another retailer, you can upgrade your ebook to take advantage of all these benefits for just $4.99. to access your ebook upgrade.
Please note that upgrade offers are not available from sample content.
A Note Regarding Supplemental Files
Supplemental files and examples for this book can be found at http://examples.oreilly.com/9780735678163-files/. Please use a standard desktop web browser to access these files, as they may not be accessible from all ereader devices.
All code files or examples referenced in the book will be available online. For physical books that ship with an accompanying disc, whenever possible, weve posted all CD/DVD content. Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to .
Foreword
Ah, the thankless life of the Build Master. If they do their job well, youll never know they exist! If they dont, well, everyone knows its the Build Masters fault, right?
Ive been a builder in one form or another since my first foray into managing the build. Nearly 15 years ago now, I worked on an extremely large system with a team of hundreds. When it came time to build, we used Freds machine. Yes, I learned that day that we built and shipped large systems on Freds laptop.
This is also how I came to find that learning a new build system is similar to boiling a frog. If you throw a frog into hot water, it jumps out. But if you turn the water up slowly, the frog doesnt realize its getting hot, so it stays in the pot and gets boiled. The team didnt realize how big the system had become and how complex the build was getting.
I realized immediately, somewhat intuitively, that we needed build box. Fast-forward some years, and now every group I work with uses Continuous Integration. Groups I work with have build farms, one with a Siren of Shame, a flashing light to effectively shame the build-breaker. We have build artifacts as complex and elegant as actual preconfigured virtual machines that pop out the end of our build.
All this was made possible by the power of automation and the surprising flexibility of MSBuild. Sayed and William have written what amounts to the missing manual for MSBuild. MSBuild, and its enterprise support counterpart Team Foundation Build, are almost unapologetically powerful. However, they need to be.
Todays software systems are multilayered, multitiered, and iterate at a speed previously unheard of. All our software development practices and team building comes together at one pinch point: the build.
This essential reference to MSBuild gives us the knowledge not only into how to create an adaptable and vigorous build system, but also valuable insights into the why of the product. William is a senior development lead on engineering systems within the Developer division at Microsoft, while Sayed is a program manager overseeing build and pushing for the Microsoft Azure Cloud and Web Tools. I could think of no better people to help me understand a large build system than the folks building large systems themselves.
Sure, weve all started with Build.bat and called it our build system. Perhaps weve put together a little schedule and called it an automated build. But these simple constructs dont scale across a large team or a large product. This book is what the documentation should have beena guide that takes us through the humble beginnings of MSBuild as a supporting and unseen player in the .NET ecosystems to complete and sophisticated team build solutions.
More importantly, Sayed and Bill dig into the corners and edge cases that we all find ourselves bumping up against. They elaborate on the deceptively deep extensibility model that underlies MSBuild and give us the tools to bring both stock and custom components together into a complete team workflow.
MSBuild continues to evolve from version 2, to 3.5, and now to version 4 and beyond. This updated supplemental edition builds (ahem) on the good work of the previous editions and includes new sections on the updates to the MSBuild core, changes in Team Build, and even updates to Web Publishing in Microsoft Visual Studio 2012.
Im glad that this book exists and that people who care about the build like Sayed and William exist to light the way. Now, if I can just find out what I did just now that broke my build...
Scott Hanselman Teacher, coder, blogger, podcaster hanselman.com
Introduction
Build has historically been kind of like a black art, in the sense that there are just a few people who know and understand it and are passionate about it. But in todays evolving environment, that is changing. Now more and more people are becoming interested in build and making it a part of their routine development activities. Todays applications are different from those that we were building 5 to 10 years ago. Along with that, the process that we use to write software is different as well. Nowadays, it is not uncommon for a project to have sophisticated build processes that include such things as code generation, code analysis, unit testing, automated deployment, and so on. To deal with these changes, developers are no longer shielded from the build process. Developers have to understand the build process so that they can employ it to meet their needs.
Back in 2005, Microsoft released MSBuild, which is the build engine used to build most Microsoft Visual Studio projects. That release was MSBuild 2.0. Since that release, Microsoft has released three major versions of MSBuildMSBuild 3.5, MSBuild 4.0, and now MSBuild 4.5. Along with the updates included in MSBuild 4.5, there are many build-related updates in related technologies. For example, with Visual Studio 2012, you now have the ability to share projects with Visual Studio 2010. Another great example is the usage of NuGet. In many ways, NuGet has changed how we develop and build applications. In this book, we will look at the updates included in MSBuild 4.5, as well as other related technologies.
Team Foundation Build (or Team Build as it is more commonly known) is now in its fourth version. Team Build 2005 and Team Build 2008 were entirely based on MSBuild, using it for both build orchestration and the build process itself. Team Build 2010 moved build orchestration to Microsoft Windows Workflow Foundation and continues to use MSBuild for the low-level build processes. Team Build 2012 continues this architecture but now supports building in the cloud using the Team Foundation Service, an updated task-focused user interface, gated check-in improvements to improve throughput, and better support for unattended installation.
When developing automated build processes, the next step in many cases is to automate the publish process. In Visual Studio 2010, the initial support for the Web Deploy tool was added. In Visual Studio 2012, there have been a lot of updates to how web projects are published, including first-class support for publish profiles from the command line, sharing of publish profiles with team members, database publishing, and many more. In this update, we will describe these updates and show you some real-world examples as well. Youll see how the process used in Visual Studio 2012 is much more straightforward than what was provided in Visual Studio 2010.