Hi Chris,

Thanks for sharing this issue.

I received some inconsistent results from the code you supplied. I narrowed it down the following:

dim result = String.Format(CultureInfo.GetCultureInfo("de-CH"), "{0:0.###}", 18.45)
Console.WriteLine(result)

The above code returns a different result on some systems. On my own development machine, this returned '18.45', where on another system, it returned '18,45'.

I believe this may have something to do with the cultures that are installed on the machine being used.

Interestingly, in neither case was my result the same as yours. On my development machine, all the tests passed fine under NCrunch. On the other machine, it failed in a completely different place to where you reached the error.

The code did not compile for me under .NET 3.5.

I've inspected the parameters around the NCrunch test environment and confirmed that they are all behaving as expected. I believe this to be pass/fail behaviour dependent upon the state of the .NET framework and the environment in which the tests are being executed.

Sorry, there may not be much more I can do to help you with this problem.

Interesting. It's quite common to see situations in a company where the IT department isn't consulted before major decisions are made. It's rather frightful to see this happening on a country-wide level, though far from unusual I guess.



Thanks, this got the code compiling .. I'm not sure why I didn't think of that at the time.

On my development machine, the test passes normally while under .NET 3.5. This is a slightly different setup to yours (VS 2015 Enterprise w/ Update 2 Windows 8.1). Though I still can't reproduce the problem, given your comment about the culture being changed in an update, I might hazard a guess as to why the behaviour here isn't consistent.

If MS reverted the ',' back to '.' in an update, then I could see this causing all kinds of chaos between different environments. When NCrunch runs tests under .NET 3.5, it will do so using a task runner .exe built to target .NET 3.5. The same pattern applies for other versions of the framework. The task runner .exe itself is essentially little more than a windows application (originally a console app actually) that accepts some data from the NCrunch engine over IPC, then proceeds to call into your test code via your chosen framework. This means that in theory, you should be able to replicate the behaviour of the NCrunch task runner by creating your own console application using the same version of the .NET framework, then calling into your test code directly.

I've observed that under my current setup VSTest is calling into the test using the same version of the core .NET assemblies as is used by the NCrunch task runner. This isn't a surprise, because the test passes in my environment. I'd be interested to know whether something in your environment (perhaps VS community?) is using a different version of the framework when calling into your code via VSTest. My theory is that the exact revision of the framework being referenced in your VSTest is somehow different to the one being used by a standard .NET 3.5 application. At the moment I'm having a hard time understanding how else such a difference in behaviour could exist unless there were bugs in the framework itself. You may wish to try checking this by starting up a couple of debug sessions (NCrunch vs VSTest), then comparing the list of loaded modules inside each of the test processes.

Regardless of whether this is a framework versioning issue or an environment related bug of some kind, I don't think there will be any functional change that can be made to NCrunch that will solve this problem. For compatibility reasons, NCrunch needs to run test code using the same version of the .NET framework that would be used for a standard .NET application. NCrunch isn't able to safely override the behaviour of low level logic within the framework itself. It may well be that the functioning of this test code will always be inconsistent depending upon the environment it's being run in. Given that the de-CH culture can behave differently on different machines, I would perhaps suggest using a different culture for your testing purposes (assuming you are interested in testing the code itself and not the environment it's being executed in).