Please see the .Net Component Build Process for an explanation of what the new java build process provides beyond the old process.

Overview

The rebuild process is conceived with several things in mind :
- first of all in order to have the possibility to make usage of the Visual Studio IDE facilities when developing the component in a transparent way.
- separate the part of the build files which changes from the one which always stays the same.

TopCoder has chosen to use the a Bamboo continous integration server from Atlassian in order to increase the quality of its component model. One of the main advantages of having an in-house continous integration server is that it takes a lot less to find inconsistencies between a component if its dependencies are changing. When a component svn trunk is updated there are several actions which can be triggered on the continous integration server for it like: compiling, testing, etc. and also if everything is all right the same thing for the component plans which represent child plans of the component (because they depend on it).
Generally speaking there are several steps to integrate a component in Bamboo:

Updating the file structure of the component to match the new build format
Create a test plan for the component in Bamboo.

Updating the file structure of the component to match the new build format

Most of the information on how to do update the file structure of the component in order to have the new build format for it in place is presented in .Net Component Build Process document so please read it by paying attention to all the details presented there.
To make the long story short, you'll need to :
* download and use the master Build files
* update the Build.version and Build.dependencies files to match the dependencies of the component
* remove unnecessary files after you're done with the translation to the new build format (remove default.build and default_dist.build files)
* update the README file from the trunk of the component with instructions for setting up the component for use/testing
* update the AssemblyInfo.cs file if needed by commenting the reference to the keyfile from it, in order to avoid signing issues. What you need to do is something similar to what you see bellow :

AssemblyInfo.cs file sequence

//[assembly: AssemblyKeyFile(@"..\tcs\bin\TopCoder.snk")]

* update file names from the docs/ directory to match what is searched in the fileset from DistDocs target from Distribution.targets file. Particularly you need to be careful here to match the .tcuml file, CD, SD, UC, RS,CS names with what is searched in the fileset.
To help out what I'm trying to say here I will add an image on how the structure for docs/ directory should look like.

You can see in the image above and you should keep in mind that coverage information is not supposed to be in the docs/ directory from the component's SVN trunk. This is a move towards keeping in the component's svn trunk only what is really needed and also to remove auto-generated files, which may get outdated throughout the time. The most common example is that differences can be found between CS.rtf and CS.pdf as there are made changes on the document on the final fixes phase and the developer forgets to regenerate the CS.pdf file.
* commit all the changes to svn

Please note that sometimes you need to add fewer component references in Build.dependencies for the Component Source project file than there were mentioned in the older default.build file. This can be either due to the fact that the component was build reference to more components then there was really needed, either to the fact that those dependencies are used only when running the tests. In case you encounter a problem in the tests (in case you execute them) please notify the project manager through a mail about the problem.

When you'll encounter components compiled or tested in a DIFFERENT way that the standard way (with something else than NUnit) please let the project manager or ivern know about this and put on hold the rebuild task. Please take extra care when checking about these things, because otherwise the build could be broken because of this when the component will be tested.

You can also encounter a component directory in svn which doesn't have the directories (component_name should be replaced with the distribution name for the component):

https://coder.topcoder.com/tcs/catalog/dotnet/component_name directory structure

- branches
- tags
- trunk

In this case you need to create at least the tags/ directory (from Tortoise SVN explorer).
After each rebuild task is done the changes on the component need to be tagged(Branch//Tag from TortoiseSVN menu after you've commited the changes) to the following address: https://coder.topcoder.com/tcs/catalog/dotnet/component_name/tags/version-x.x.x.x where x.x.x.x represent the values for component's major,minor,micro,build values (from build.version file).

Once you have completed that tutorial and when you'll take a component for re-build, at the end of the process, the svn file structure of the component will look like this :

Be sure always to check if the file structure is similar to what can be see in the image presented earlier.
In the case one or more of the conf/, test_files/ directories are empty you can REMOVE them from svn as they are useless in this case for the component.

The good part about translating the build files to the new build format is that there is a special tool conceived in order to leverage much of the manual work of the rebuilders by automation of the process. The sources for this tool can be found in svn repository for Rebuild Helper Tool. What the builders need to do is that they have to download the sources, compile on their machine the application, put the directory location where the executable RebuildHelperTool.exe in the environment PATH variable and then just run it when they check out the trunk of a component to be rebuilt. The tool does most of the stuff needed for translation and in some cases there will be no need for extra work on the build files from the rebuilder. What is requested though is to be careful when examining the following files for accuracy:

Build.version
Build.dependencies

In some of the cases when using this tool you'll notice that the building will not work because the compiler doesn't see some of the assemblies which were found before by NAnt in GAC(Global Assembly Cache) reason why they weren't specified before in the build files and so these missing assemblies (like System.Xml or System.Data or System.Configuration, etc.) need to be added by hand to the Reference part of the Build.dependencies file (either for component sources -which will apply to component tests also - either only for component tests).

Some of the components present in the TopCoder .NET component catalog integrate into the assembly resulted from compiling the sources, resource files. Embedding resource files is pretty straightforward and can be done by specifying the resource files in Build.dependencies file.

- Specifying an .xsd resource file with logical name composed of $(ComponentPackage) and its filename:

- Specifying an .xsd resource file with the same logical name as its filename:

You can also encounter assemblies which need a configuration file for Component Tests assembly. The solution for specifying this configuration file is presented in the image bellow:

If some assemblies need more configuration files copied int the place where the compile output assembly is stored you can use a tweak like the one from ASP.NET Localization component (redefine CopyTestDependencies target in Custom.targets file).

Another thing to take into account is that for some newer components (with target versions like NETFX 3.0 or NETFX 3.5) is that in the Build.dependencies you will have to manually modify the TargetFrameworkVersion property with appropriate values like v3.0 or v3.5

A last note about the changes you can make in Build.dependencies file is about the OutputType library. This property can have one of the following values :

Library (default value)
Exe
WinExe

Normally you are supposed to change this property only if you want a different kind of output from the Build target.

Create a test plan for the component in Bamboo

Once the svn trunk of the component has been updated CORRECTLY it we can proceed to create the test plan for the component.
Currently the Bamboo server instance can be found at this address Bamboo URL and the catalog for the current project is TopCoder .NET Catalog.
The user interface for Bamboo, as well as for all other Atlassian products is very intuitive.
This tutorial is conceived to give you a head start on how to create test plans in Bamboo, so there's no need to get into the details on how to use Bamboo, to avoid duplicating the documentation which can be found at Bamboo Documentation Home.

For creating a Bamboo plan please use the Create plan link which can be found on the TopCoder's Bamboo server home page.
Once you pressed the button for creating the plan you'll need to fill in its details :

What you need to fill in is :
* build plan name
* build plan key
You also need to choose to clone an existing plan (TopCoder NET Catalog - Set is a good plan to choose from the available plans to clone). You an see in the image presented earlier that the Build Plan Name and Build plan key are highlighted. These fields can be retrieved from Topcoder component's catalog page (see highlighted part from the component page URL and component name from the page).

Once you have filled the plan details you can advance to the next step of specifying the component's repository. As you may know TopCoder is using Subversion as standard for repository of the components. In the following image you can see that in this step you only need to fill in the repository URL of the component (normally you should be aware by now on the format of the svn URL for the component from .Net Component Build Process document).

The next step in creating the plan is the Builder Configuration where you only need to specify the Build JDK (if you chosed to clone the TopCoder NET Catalog - Set plan).It is possible that the value of the Target field to be different from what you see in this image, but don't mind that as this may be due to some target name change, or simply a change of what the plans need to do during the builds.

Normally you shouldn't be concerned to modify anything in the next steps so keep hitting next until the process of creating the plan is completed.
Once the plan is created the build sequence which was specified in Builder Configuration step (see Target field value from the image above) will be executed. There's only a slight thing to be specified and the plan configuration is done. Select the plan from the TopCoder NET Catalog Bamboo project and go to its Configuration tab. There you should go in Dependencies sub-tab and add as Parent plans all the TopCoder components which are specified in Build.dependencies file for the component sources.

Mostly what you need to do in Build.dependencies file is that you need to make sure that the References part is well put together. In the image bellow you can see in the upper highlighted part that the _Component Source dependencies are defined, but you can also see on the bottom side of the image that an extra assembly (System.Data) is referenced in order to be used by the project Component Tests.

Another thing to take into account is that for some newer components (with target versions like NETFX 3.0 or NETFX 3.5) is that in the Build.dependencies you will have to manually modify the TargetFrameworkVersion property with appropriate values like v3.0 or v3.5

Once you have completed all these steps you can consider finished the transition of the component to the new build format and its input into the TopCoder's integration server.

When you're positive that the errors you are getting when compiling the sources or the test cases for the component are due to the fact that either there is an incompatibility between the older version of a dependency component and the new version used now for building, or when simply you encounter compile/compile_tests erors due to the fact that svn trunk of the component was incorrectly updated (not likely) please add a comment to the build explaining what happened and a TopCoder employee will take it from there. I will post shortly some examples on how this should be done.

External libraries directory structure.

TopCoder is not allowed to re-distribute the 3rd party libraries on which some of the components are dependent (like junit for example). This is the reason why attached to document you will find here a listing of TopCoder's ${ext_bin} directory. Please structure your ${ext_bin} directory in the same way as TopCoder has structured these libraries to avoid having problems when integrating the component on the Bamboo server.Note that there will be other libraries added, when needed, to the external libraries directory on the Bamboo machine, so please check out from time to time if anything has updated on the 3rd party directory listing.
When you encounter a problem in building a component because of a missing third-party library, please contact the component rebuild project manager and ivern in order to have the problem solved.

Please feel free to comment any of the details presented in this tutorial if you feel that it can be polished to be easier to understand or if there is more information needed.