I am a developer at Microsoft and work in the .NET Common Language Runtime (CLR) team. For the last 4 years I have been working on virtual machine technologies on a variety of form factors including desktops (Windows, Linux), tablets (Win8), gaming-consoles (Xbox 360), mobile devices (Windows Phone 7, Windows CE, Symbian).I have worked on various core pieces of the runtime including Garbage Collector, memory manager, platform abstraction layer, runtime-performance, etc.Before working on .NET I worked on Visual Studio Team Foundation Server, Visual Studio Team System, Adobe Framemaker, Adobe Acrobat, Texas Instrument's Code Composer Studio.
For people new to Team Build do read Overview of Team Build
Though most people using Team Build easily finds out how to create a build type and fire a Team Build, they find it difficult to figure out how to edit a Build Type. So one of the common use scenario is to re-create the Build Type again with the changes required. Though this is perfectly fine and talks a great deal about the ease of using the Wizard to create a new build type, but results in Build Types hanging around.
Editing build type is easy once you know what is a Build Type and where they go once created.
Right click on the Team Build node on the Team Explorer and choose "New Team Build Type" from the context menu. This launches the Wizard to create the Build Type (refer Using the New Build Type Wizard for more info)
Once a Build Type is created a set of three files are created and checked in to source control at the following server location $/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}
In Beta2 the server location used to be $/{TeamProjectName}/TeamBuildConfigurations/{BuildTypeName}. So replace all references to TeamBuildTypes with TeamBuildConfigurations if you are working with VS2005 Beta2
Team Build operates and works on some thing called Build Types. Build Type is essentially a set of 3 files that reside on the Source Control as follows
Interestingly the Build Type name is not stored in any of the files. The name is same as the name of the folder in TeamBuildTypes that contain these files
Viewing the build type files is same as viewing any file in the Source Control. You need to create a Workspace that maps the Build Type files to some local folder, sync the file and open them in any text editor. This can be done in a number of ways and one of them is clearly mentioned as comment on top of the generated TeamBuild.proj file. So if you right click on any of the Build Types under the Team Build node in the Team Explorer and choose "View Team Build Type" then the file is downloaded from the server to the local machine and opened in VS. One thing to keep in mind is that the file opened is a local copy and changes made to it will NOT be reflected in the actual TeamBuild.proj on the server.
Double click on the version control node in the Team Explorer to bring up the Source Control Explorer. If in the Folder list the TeamBuildTypes and its children are grayed out then that means that the folders are not mapped in the current workspace. In the tool window on the top of the Source Control Explorer select Workspaces... in the Workspace drop down. Select your current workspace and click on edit. In the Edit workspace dialog add mapping for the TeamBuildTypes folder. See image.
Once the mapping has been added right click on the TeamBuildTypes node in the folder and get the latest version. After that right click on the TeamBuild.proj and check out for edit. Double click on the file to open it in VS for edit.
TeamBuild.proj file is an xml file and heavily commented so that it is easy to edit. Just look for <Description> and add some description to the Build Type, search for <DropLocation> and change the location where the build bits will be dropped. Keep reading the comments and that will guide you in your changes to this file. At the end save the file and go back to the Source Control Explorer, right click on the checked out TeamBuild.proj and check in the file and you are done
You can verify that your changes have gone through by right clicking on the Build Type you changed in the Team Explorer and choose "View Team Build Type". The opened Build Type should have your changes in it.
How do you communicate to users which fields on a UI is required and which is optional? This was the questions I was trying to answer while implmenting the Team Build Type creation wizard. Though there exists some common conventions in Web forms like marking the fields with asterix and putting something like "Fields marked with an asterix * are required" somewhere on top, there seems to exist no convention to do this on Windows user interfaces.
In team system the work item tracking UI does this by making the background color of the required fields with the same color as tooltip (yellow) and then as soon as the user types in some thing in them the color changes back to window backgorund color (white). So the user can quckly review the form and can locate fields that are left to be filled as they are marked with a different color (yellow).
I liked this idea a lot and wanted to do the same thing with our wizard and Start build forms. But could'nt get that approved by the User Experience team becuase they think that on wizards the visual cue should come from the enabling of the Next button. The idea is that once the user has filled in all the required fields in the page Next should get enabled so that he can move to the next page. I think this works well only when the number of controls on the Wizard page is less, other wise the user will keep trying to guess why the next button in not getting enabled. Since wizard guideline clearly calls out against crowding too many things in one page, I guess this is fine but still think we should move towards a common guideline on marking required fields and I think the background color change is a fine way of doing just that.