RavenDB transformers will lower-case your IDs

Here’s a nice little gotcha. When RavenDB (v3.0.30155) returns data from the database, it will generally preserve the casing of the IDs (e.g. an ID of MyDocuments/1 will be returned as such), even though RavenDB itself doesn’t care about casing (e.g. if you run Session.Load<MyDocument>("mydocuments/1"), you’ll still get back the right document). However, if you write a transformer like this:

public class MyDocumentTransformer : AbstractTransformerCreationTask<MyDocument>
{
    public MyDocumentTransformer()
    {
        TransformResults = docs => docs.Select(d => new TransformedDocument
        {
            Id = d.Id
        });
    }
}

You’ll notice that when you use this transformer, any returned TransformedDocuments will have lowercase IDs like mydocuments/1. Although RavenDB doesn’t care about this, we had some code further down the line that (unfortunately) did rely on casing, which then started to fail. Fortunately, since transformers are just running C# code on the server, it’s easy to fix with something like this:

public class MyDocumentTransformer : AbstractTransformerCreationTask<MyDocument>
{
    public MyDocumentTransformer()
    {
        TransformResults = docs => docs.Select(d => new TransformedDocument
        {
            Id = d.Id.replace("mydocuments", "MyDocuments")
        });
    }
}

Which will restore your IDs to their proper-cased glory.

TeamCity build fails with “no net in java.library.path”

One of our builds just failed with this fairly cryptic error:

[File content replacer] no net in java.library.path
java.lang.UnsatisfiedLinkError: no net in java.library.path
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.loadLibrary0(Unknown Source)
    at java.lang.System.loadLibrary(Unknown Source)

Turns out we’d manually updated Java on the machine that the build agent was running on. If you do that, you should also restart the build agent service so that it picks up the new version correctly.

How to version DLLs using TeamCity

It’s useful to include a version in DLLs that you deploy, to make it easy to check what code is actually being used where. We build our projects using TeamCity, and it’s possible to write build scripts that grab the version from an environment variable that TeamCity sets in order to insert into your AssemblyInfo.cs files. However, if you have a fairly standard project setup and are using TeamCity, there’s an easier way to do this using the AssemblyInfo Patcher build feature that TeamCity provides. This will run after all files have been checked out, automatically searching for all AssemblyInfo.cs files and replacing relevant versions (e.g. in the [assembly: AssemblyVersion("1.0.0.0")] attribute) with the current build number, before then proceeding as normal with the build, and reverting the changes once the build has finished.

To enable this feature, simply edit the configuration settings for the build you wish to add it to, click “Build Features” in the sidebar on the left, then click the “Add build feature” button and select “AssemblyInfo patcher” from the options. Configuration is fairly minimal but will allow you to customise the format of the version that will be used for various different attributes, if you don’t want to just use the default build version.

TeamCity build features

The AssemblyInfo Patcher is just a pre-configured version of the TeamCity File Content Replacer build feature, which you can use if you have more advanced needs.