I know the answer (it's 42)

A blog on coding, .NET, .NET Compact Framework and life in general....

June, 2005

  • I know the answer (it's 42)

    TechEd Hyderabad starts tomorrow

    TechEd is starting tomorrow in Hyderabad (home to the MS India development centre). Most of the devs in our team will not be able to attend tomorrow and we will join the show from Tuesday. VSTS is getting a lot of attention this year and we heard great stories from the people who attended TechED in Bangalore and Chennai. The India Team System team working on Team Build and the converters will all be there in our Black T-shirts with Team System written in front. So if any one of you have any questions or need any insider info ;) catch us.
  • I know the answer (it's 42)

    marking required fields on forms/UI


    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.

  • I know the answer (it's 42)

    What are the Build Types, how do I edit them


    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.

    How do you create a Build type

    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)

    Where did the Build Type go?

    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

    • $/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}/TeamBuild.proj
      The main BuildType file that we would be interesting is editing.
    • $/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}/VCOverrides.vsprops
      Used for building VC++ projects to override some build properties like the OutputDirectory
    • $/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}/WorkspaceMapping.xml
      This is used to recreate the users Workspace on the Build Machine to sync sources prior to build.

    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

    Build Types in Source Control 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.

    Editing the file

    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.

    Edit workspace dialog

    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.






Page 1 of 1 (3 items)