Jaa

TFS 2010 – The New Build Definition Window

  • Artikkeli

The build definition dialog is now a window! Why is that so exciting? Well, let me tell you…

  1. Now you open two definitions side by side and copy information from one to the other!
  2. 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.
  3. 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:

General

image

This page is basically the same as in Visual Studio 2008. No changes here.

Trigger

image

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.

Workspace

image

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.

Build Defaults

image

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!

image

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.

Retention Policy

image

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 :)

Comments

  • Anonymous
    June 17, 2010
    Hi Jason, You have said "Some parameters are also expandable so that you see the details of the parameter without opening the custom editor". Any idea on how to get this to work for custom types? I have a custom list type with a type converter and type descriptor (modelled from TestSpecList), but I don't get any expanded property for it. Cheers, Rory

  • Anonymous
    September 08, 2010
    I have migrated visual studio and TFS from 2008 to 2010. All the code is working perfectly. The only problem I am facing is related to build. To be precise for 'Build Defaults' property of builds. Along with migration we have also migrated server. In build definition its showing old Build controller and I am not able to change it. In dropdown too I am getting only that old one. So can you please help me on how to change the build definition to use new controller & build agents.

  • Anonymous
    January 10, 2011
    Why do build definitions have no backing file stored in source control? What if I'm working for a large corporation and have 200+ solutions to compile?  if the list of 200 is accidentally messed up or out of order there is no change history. What if the build is more complex than Hello World and multiple custom parameters are added. When one of those is broken there is no history of the changes made to the build definition.

  • Anonymous
    May 20, 2013
    Hi Everyone, Right now we have one Check in build definition, now we want to create another build definition with same build activities but it is for VS2012. Is everything same or do i need to set any more settings.?

  • Anonymous
    July 17, 2013
    Everything should be basically the same. I can't be sure without knowing exactly what you are doing. Thanks, Jason

  • Anonymous
    August 31, 2014
    Hi Jason, Is there an answer to @Rory_Primrose question? You have said "Some parameters are also expandable so that you see the details of the parameter without opening the custom editor". Any idea on how to get this to work for custom types? I have a custom list type with a type converter and type descriptor (modelled from TestSpecList), but I don't get any expanded property for it.

  • Anonymous
    September 01, 2014
    To have your properties be expandable in the WinForms property grid, you have to put the ExpandableObjectConverter on them as a typeconverter. Look for examples of this converter and you should find plenty of examples. Thanks, Jason