The main issue there is that by default libjingle is built using static runtimes, while /clr option for managed C++ requires the DLL runtimes. Thus when you try to link the libjingle’s “.lib” files into the managed app it produces a lot of “symbol already defined” errors. The obvious way to solve is to build the libjingle using the dynamic runtimes. To do so you need to make few changes in “main.scons” file:

win_env.Append(
  COMPONENT_LIBRARY_PUBLISH = True,  # Put dlls in output dir too
  CCFLAGS = [
   # ...skipped...
    '/wd4996',      # ignore POSIX deprecated warnings
    '/wd4275',      # ignore the warning on exporting class that was derived from non-exported (!!!)
   # ...skipped...
  ],

# ...skipped...

win_dbg_env.Prepend(
  CCFLAGS = [
      '/ZI',     # enable debugging
      '/Od',     # disable optimizations
      '/MDd',    # link with MSVCRTD.LIB (multi-threaded, dynamic linked crt) (!!!)
      '/RTC1',   # enable runtime checks
  ],

# ...skipped...

win_opt_env.Prepend(
  CCFLAGS=[
      '/Zi',     # enable debugging
      '/O1',     # optimize for size
      '/MD',     # link with MSVCRT.LIB (multi-threaded, dynamic linked crt) (!!!)
      '/GS',     # enable security checks
  ],

Changing the “/MT” and “/MTd” to “/MD” and “/MDd” is pretty obvious. Suppressing the warning 4275 is required because flag to treat warnings as errors is set and there is at least one file that throws this warning. It is a quick hack and I am going to check if it is possible to fix it with changes in the code when I have more time. Then you can run the build again. The output “.lib” files are ready to use in managed code, however you will also need to add at least the following libraries to dependencies in managed part to get rid of the “unresolved external symbol” errors completely:

• wsock32.lib
• ws2_32.lib
• Advapi32.lib

At first I was really optimistic about writing all the stuff for our build solely on CCNet, but it appeared impossible because of its poor handling of user-defined variables and lack of flexibility for custom operations. That was the point where MSBuild helped a lot (take a look at Simple MSBuild Project tutorial to see what it looks like). I will describe several situations where I had to find own solution below.

One CruiseControl.NET server for multiple projects

I guess it is a common situation when one CCNet server is used to build several different projects (e.g. made by different teams). The projects’ configurations themselves can be rather large and changing one of them in main ccnet.config file might cause problems for others. Also I think that it would be a good practice to have projects’s own configuration being versioned alongside the whole project. There are two means of including parts of configuration into the main config file: via XML’s ENTITY and via CCNet’s preprocessor. I prefer the latter one for two reasons: the code to include external files is much more readable and files included this way are automatically watched for changes (e.g. if you change external part the configuration automatically reloads). So in our case the ccnet.config files looks simply like:

<!DOCTYPE cruisecontrol>
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
  <cb:include href="path_to_project_1\project.config"
    xmlns:cb="urn:ccnet.config.builder" />
  <cb:include href="path_to_project_2\project.config"
    xmlns:cb="urn:ccnet.config.builder" />
</cruisecontrol>

It’s really simple and effective.

Control flow in CruiseControl.NET

The latest stable version of CCNet (the 1.5 at this moment) I had did not have any means to separate control flow depending on dynamic values. It was announced to be the part of v1.6 release, but I did not want to risk with unstable version, so I had to download the CCNet Conditional plugin. The precompiled version did not work for me as far as CCNet did not see the plugin after copying to the rest of the CCNet server files. So I had to download the sources of the plugin and compile it on my work PC. The newly build plugin worked like a charm… until you need to use the logical operators: “or”/”and”. It seems to be a mistake in plugin documentation as far as it stated that the appropriate conditional tasks to be used in config file were called “orConditions”/”andConditions” respectively, but config file validation always failed on this element. After couple of hours spent in vain I’ve made a stupid thing: I removed the plural ending of the keyword, and it worked! So the typical usage of the conditionals in CCNet project would look like:

<conditional>
  <conditions>
    <orCondition>
      <conditions>
        <compareCondition value1="$[Distribution|None]"
          evaluation="equal" value2="CD" />
        <compareCondition value1="$[Distribution|None]"
          evaluation="equal" value2="Both" />
      </conditions>
    </orCondition>
  </conditions>
  <tasks>
    <!-- primary tasks -->
  </tasks>
  <elseTasks>
    <!-- alternative tasks -->
  </elseTasks>
</conditional>

The long path CCNet Build Publisher problem

I guess it is not a common problem, but we had to handle this case, Our InstallAware installer script generated the uncompressed package that contained .NET redistributables and when we tried to copy it to the server it appeared to have really long path names (e.g. they exceeded the limit of 260 characters) that caused build task to fail. We’ve tried several solutions (like using xcopy, or performing the copy operation by MSBuild script) but it looks like most of them have the same issue. So the last way we had to resort to is to use robocopy. It is an official tool that is a part of Windows OS since Vista (i.e. Server 2008 and Win7 already have it) but for Server 2003 we had to install additional Windows Resource Kit package. Therefore there are couple of thing I suggest to pay attention to. First use /NP switch because otherwise your build log will be full of worthless copy progress lines. Second robocopy uses exit codes that are usually treated as errors (like 1, 2 etc), so you should ignore them (bad idea), or read robocopy docs and add exit code exceptions.

MSBuild absolutely necessary plugin

I cannot imagine having my work done without MSBuildTasks project. It has lots of cool stuff that is not really part of MSBuild, but turns it into the really powerful tool. Just download and install it and add following line in your MSBuild *proj file:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />

Altering properties by conditions in MSBuild

One of the things that I needed to do was to generate the DefineConstants property for our project configuration depending on CCNet dynamic values. Moreover I needed to alter them according to user input. E.g. we have A/B switch and flag C. If switch is set to A then PROP_FOO should be set, if switch SWITCH_AB is set to B then PROP_BAR, and if FLAG_C is on, then PROP_BLAHBLAHBLAH should be added. It is done via the PropertyGroup item introduced in MSBuild v3.5:

<PropertyGroup Condition="'$(SWITCH_AB)' == 'A'">
    <DefineConstants>PROP_FOO</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition="'$(SWITCH_AB)' == 'B'">
  <DefineConstants>PROP_BAR</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition="'$(FLAG_C)' == 'yes'">
  <DefineConstants>$(DefineConstants);PROP_BLAHBLAHBLAH</DefineConstants>
</PropertyGroup>

Moreover with PropertyGroup the CreateProperty task is not needed anymore (in my cases at least).

Autogenerating AssemblyInfo.cs with version info passed from CCNet

As easy as pie:

<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name="BeforeBuild">
  <AssemblyInfo
    Condition="'$(CCNetLabel)' != ''" CodeLanguage="CS"
    OutputFile="Properties\AssemblyInfo.cs"
    AssemblyTitle="Software Name"
    AssemblyCompany="My Company"
    AssemblyProduct="Software Title"
    AssemblyDescription="Software Description"
    AssemblyCopyright="Copyright"
    ComVisible="false" Guid="xxxx-whatever"
    AssemblyVersion="$(CCNetLabel)"
    AssemblyFileVersion="$(CCNetLabel)" />
</Target>

Magic!

Passing values to MSBuild task

It appears that only pre-defined CCNet values values (like $CCNetLabel) are passed to MSBuld task automatically. I wonder if there is a best solution, but if I needed to pass dynamic or custom values to MSBuild project, did it like this:

<msbuild>
  <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
  <projectFile>MyReleaseScripts\so_something.proj</projectFile>
  <buildArgs>/noconsolelogger
             /p:Distribution=0 <!-- static value -->
             /p:VersionShort=$(ProjectVersion) <!-- custom value defined with cb:define -->
             /p:BuildKind=$[BuildKind|nightly] <!-- dynamic value -->
             /p:CustomFlag=$[CustomFlag|yes] <!-- dynamic value -->
  </buildArgs>
  <targets>$[Project|None]</targets>
  <timeout>3600</timeout>
  <logger>$(CCNetPath)\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>

There are only two simple steps to implement this approach. First of all you need to modify the data() overload of your QAbstractItemModel derived model class to return the pointer to the internal data on request for Qt::UserRole role.

// ... skipped
else if (role == Qt::UserRole)
{
return QVariant::fromValue(parent(index).internalPointer());
}
// ... skipped

QModelIndexList list = yourModel.match(
    yourModel.index(0,0),    // starting index for traverse
    Qt::UserRole,            // data source for comparison
    QVariant::fromValue((void*) yourInternalDataClass),    // searched value
    1,                       // maximum number of matched items, use -1 to return all
    Qt::MatchFlags(Qt::MatchRecursive)    // match flags
);

Works like a charm…

Following extensions need to be supported by your graphic adapter:

• GL_ARB_depth_texture or OpenGL>=1.4
• GL_ARB_shadow or OpenGL>=1.4
• GL_EXT_shadow_funcs or OpenGL>=1.5
• GL_ARB_vertex_shader or OpenGL>=2.0
• GL_ARB_fragment_shader or OpenGL>=2.0
• GL_ARB_shader_objects or OpenGL>=2.0
• GL_ARB_occlusion_query or OpenGL>=1.5
• GL_ARB_multitexture or OpenGL>=1.3
• GL_ARB_texture_rectangle
• GL_SGIS_texture_edge_clamp or GL_EXT_texture_edge_clamp or OpenGL>=1.2

When using OSG it is not necessary to perform direct OpenGL calls as far as OSG has own wrappers. To check GL extensions you can use the following function:

bool osg::isGLExtensionSupported(contextID, extensionName);

You will probably want to check all those things on application startup or something like that, but using the GL context of your OSG viewer instance. Beware: the context is not valid outside the OSG frame loop. However guys from OSG users mailing list suggest to avoid doing OpenGL calls directly in the frame loop, and instead use a Camera initial/pre/post/final draw callback to do extra OpenGL calls. This approach works for all threading models and viewer configurations. It works indeed, but in my case we need to perform the checks only once on startup, so while this solution is working it has some overhead. I wonder if we will have to create another GL context just to perform this operation without using OSG? Uh, what a bother…