What culture does TeamCity run builds in (and how to change it)?

I am running some unit tests using a MSBuild runner within a configuration. Some of the tests are failing because they are expecting a US/UK culture, but are using a different one. As an example:

Expected: "1.50"
But was:  "1,50"

It looks like the build is being run using a culture which uses a comma as its decimal separator. Is this so, and can it be changed?

The build agent is a UK install of Windows 7. If I use the built-in NUnit runner on thei agent, the tests are fine. They only fail when using the NUnitTeamCity task from within a MSBuild script to run the tests.

6 comments
Comment actions Permalink

Please check the locale settings for build agent windows service running user account. You may change the account to another in order to fix the issue. You will need to restart machine to ensure changes in locate were applied to the build agent.

0
Comment actions Permalink

The locale settings for the user running the build agent's Windows service are all set to UK/US.

To verify this, I've just added a failing unit test to the build that outputs the current culture and ui culture:

Culture: English (United Kingdom) (en-GB)
UICulture: English (United States) (en-US)


Immediately following this (in the same test fixture), there are tests that fail because they are in the wrong culture.

0
Comment actions Permalink

Do you have tests that may change the locale? Do you use NUnit-specific attributes for this?

Please try running tests with  NUnit-Console.exe test runner to check weather it depends on TeamCity NUnit tests launcher.

0
Comment actions Permalink

> Do you have tests that may change the locale?

Yes. I'll comment those ones out and see if it makies a difference.

> Do you use NUnit-specific attributes for this?

No, we explicitly set the culture in the SetUp and set it back in the TearDown.

> Please try running tests with  NUnit-Console.exe test runner to check weather it depends on TeamCity NUnit tests launcher.



I was running the tests by selecting the NUnit runner in the build step and specifying the assemblies in the configuration. Following an answer on this post, I am now using a MSBuild runner to run a custom script that runs NUnit on a list of assemblies (the same set as with the NUnit runner) loaded from a text file:

 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <TestList Include="tested-assemblies.txt"/>
    </ItemGroup>

    <Target Name="NUnit">
        <ReadLinesFromFile File="@(TestList)">
            <Output TaskParameter="Lines" ItemName="TestAssembly"/>
        </ReadLinesFromFile>

        <Message Text="Assemblies loaded from tested-assemblies.txt: @(TestAssembly)" />

        <NUnitTeamCity Assemblies="@(TestAssembly)" 
                        ExcludeCategory="IgnoreInAutobuild,UI"
                        RunProcessPerAssembly="True" />
    </Target>
</Project>


Since switching to this approach, some tests have started failing with what looks like a locale/culture related issue.
0
Comment actions Permalink

I think the way I am running these tests is what the issue is. We have some tests that were setting either the current thread's culture or principal, but were not setting them back in the tear down. Running these tests using the TeamCity test runner or in NUnit directly didn't have a problem, but using the script I have posted in this thread does. It seems that using the NUnitTeamCity runner from a script file doesn't run the tests in a manner where they don't interfere with each other.

I have fixed the tests to make sure they tear down what they set up and the problem has gone away. I'm still puzzled as to why the runners behave differently though.

0
Comment actions Permalink

Within MSBuild runner NUnit uses assembly order specified in your external file.

0

Please sign in to leave a comment.