This project is read-only.


CCI Code

How Do I Run the Standard Test Suite
How Do I Access the Continuous Integration Server?
How Do I Automatically Upload a New Release
I want to attach annotations to nodes, why can't every node implement IUserData?
What is the relationship between Phoenix and CCI?

How Do I Run the Standard Test Suite

The CCI Code source tree includes a set of test projects, which are all under the Tests folder. Just go and run them! Each test project is a command-line application that executes its test and tracks the test’s progress in the command window. If there are no errors, the command window closes automatically when the test completes. Otherwise, the window stays open so you can inspect the output. Typical test output looks like: console runner (xunit.dll version
Test assembly: C:\codeplex\ccimetadata\Tests\RoundtripTests\bin\Debug\RoundtripTests.exe
Total tests: 10, Failures: 0, Skipped: 0, Time: 39.181 seconds

To debug a test application, either step into the application or set a breakpoint and run the application from Visual Studio.

CCI Code runs the set of tests as a suite by using the test framework. If you have only Visual Studio installed, the test suite uses the basic runner. However, you can install alternative runners that have smoother Visual Studio integration, including:
  • Gallio (open source)
  • TestDriven .NET. To enable this tool for xunit, run the xunit.installer project in the metadata source tree’s External\Xunit folder.
  • Resharper

How Do I Access the Continuous Integration Server?

The Research in Software Engineering Group (RiSE) group at Microsoft Research maintains a continuous integration server that uses CruiseControl.NET to monitor the CCI source trees and trigger a build on every checkin. The CruiseControl.NET server displays the results on its Web interface.

You can also track build results in real time by using the CCTray application.

How Do I Automatically Upload a New Release

If you have sufficient rights, you can automatically push a new release to the CCI Code project’s CodePlex Web site, as follows:
  1. Perform a clean checkout of the source files that will be used to create the .zip files for the release. The script will take care of updating it.
  2. Open a Visual Studio command window.
  3. In the command window, navigate to the source tree’s Build folder and run the createrelease command, as follows:
createrelease <clean sources path> <release version> <username> <password>

createrelease has four arguments:
  • <clean sources path>: The clean source tree’s root folder.
  • <release version>: A .NET compatible version number to be used as the release name (e.g.,
  • <username>, <password>: Your CodePlex user name and password.

I want to attach annotations to nodes, why can't every node implement IUserData?

This idea was extensively discussed during the CCI design process and it has a lot of proponents. However, it also has some very serious drawbacks:
  • It attaches mutable data to an immutable object model.
  • It introduces the possibility of name clashes and race conditions.
  • Many roots can keep the objects alive, so you must walk the object model to delete user data.
  • Every node in the object model now has to pay a tax.
An alternative approach is a separate hash table that maps CCI nodes to user data. Some people don’t like this solution, because you have to pass the hash table (or an object containing multiple tables) everywhere you pass the object model. However, in Herman Venter's opinion, it actually works out very well in practice; you just have to get over the gag effect. ;-)

Another approach is to make the hash table an instance field of a visitor object. Usually, the object model is traversed by a visitor, so this is also quite convenient. When composing visitors, some or all of the hash tables must be transferred from one visitor to the next, or shared between them if they are all active at the same time.

What is the relationship between Phoenix and CCI?

Herman Venter writes:

“I think of CCI and Phoenix as being complementary because CCI is primarily about turning source text into IL and Phoenix is primarily about turning IL into machine code.

If I were to remove the ability of CCI to read method bodies from compiled assemblies, CCI would not be able to do anything Phoenix can do. One could conceivably use Phoenix as a metadata reader for a source to IL compiler, and as a metadata plus IL emitter for the same, but if you were to do so, you’d be in for a very big disappointment.

So, at one level, things are crystal clear: you use CCI when you want to produce IL and you use Phoenix when you want to produce machine code.

However, somewhat to my surprise, the ability of CCI to also construct an object model for method bodies of compiled assemblies has been a big hit. So much so, that most people think exclusively of CCI as a metadata plus IL reader.

OK, so when should you use Phoenix? Do so if you are willing and able to master a very complex API and when performance/memory footprint is not a big concern for you. Do so if you need to perform basically the same analysis over managed and unmanaged code. Do so if you need to and can leverage all of the information Phoenix computes in order to optimize IL into good machine code.”

Last edited Jul 10, 2010 at 12:53 AM by mikebarnett, version 2


No comments yet.