The build definition dialog is now a window! Why is that so exciting? Well, let me tell you…
- Now you open two definitions side by side and copy information from one to the other!
- If you forget some bit of information, like where your solution file is, you don’t have to close the dialog to go to Source Control Explorer. You can open both at the same time.
- And lastly, like all other Visual Studio documents in 2010 you can dock it, tear it off, see when it’s dirty, save it with Ctrl+S, etc, etc, etc!
But what else is new in 2010? Let’s take a look at it Page by Page:
This page is basically the same as in Visual Studio 2008. No changes here.
There’s a new trigger type here called Gated Check-in. This is like the inverse of CI. Before the check-in is allowed through the build must succeed. So, instead of the check-in causing the build, the build is forced to happen first and then the check-in can finish. Read more about Gated Check-In here and here.
Not much new here, except a new button to “Reset to Default Workspace”. Of course, what you see here is the default workspace. But the button was added as part of one of my favorite new features. When you create a new build definition and you have a solution open (that’s mapped to source control), we assume you want to build the solution you have open and default the name, workspace, solution to build, and tests to run. So this button was added just in case our assumption was wrong and you wanted to get back the default workspace.
Again, not much is new here except that ability to not use a drop location. That’s right! We know that some builds don’t produce drops. Most notably Lab Management builds do not need drop locations. Now, just to be clear, if you use the default template or upgrade template, you MUST supply a drop location either here or when the build is queued. Otherwise the build will fail. This check box, just allows you to leave the field blank on this page and still be able to save the definition. If the checkbox is checked, the drop location field is required as it was in Visual Studio 2008.
Process – NEW!
This page is all new and replaces the Project File page from Visual Studio 2008 (Note that if you connect to a 2008 server, you will still see a Project File page here instead). This page contains information on exactly how and what the build will do.
The build process template box shows you which template will be used for the builds. This defines the logical flow of the build process. You can think of the template as a replacement for the Microsoft.TeamFoundation.Build.targets file from 2008. The template defines when and where everything is done. It also defines what order things will happen in. If you really want to control what the build does, you have to dig into the template and figure it out. But, that’s another post for another time. Use the Show details button to expand the area and change the template. We ship with two build templates – Upgrade and Default. But you can add your own templates as well, just click on the new button after you expand the section.
The only other thing on the tab is the Process Parameters property grid. This is a standard WinForms property grid and should behave just like other property grids in Visual Studio. The properties listed here are what we call Process Parameters. They are the values that you can pass into the process template when the build executes. These parameters can change the way the build executes or simply tell it what to build. Notice the items in the list: Items to Build, Automated Tests, Build Number Format, etc. The default template defines the parameters it requires in the Required category. The other parameters either have default values or are simply optional. Notice that a yellow triangle shows up next to properties that need to be changed. You may also want to note that the Advanced category is collapsed (not empty). It contains many more properties that you should only change if you are sure you understand what they do. Every template can define its own set of parameters. Try changing from the default template to the Upgrade template. You will notice almost all the parameters are changed.
Some parameters have custom dialogs that you can use to set the value of the parameter. Just look for the … button on the right side of the value column of the property grid. Some parameters are also expandable so that you see the details of the parameter without opening the custom editor.
This page did change quite a bit. We added the ability to specify separate retention policies for Private builds (private builds are “buddy builds” of a shelveset that do not produce drops normally). We also added the ability to specify exactly what to delete (or what to keep). See my Delete Options post for more information on the options here. The retention policy column is the same as it was in 2008.
So that’s the new Definition Editor. I hope you find it as easy to use as the 2008 dialog 🙂