Hi, thanks for posting! It's great to hear that you've been making good use of NCrunch and that you've found such value in the build optimisation features. I'll try to address your problems one at a time.

1: The NCrunch build itself is executed with the sole intention of building artifacts to be used in a testing environment. As such, DLLs and EXEs that are output from an NCrunch build will normally be manipulated at IL level (with instrumentation) and aren't really designed to be run independently from NCrunch. Most likely the reason for your EXE crashing is that its DLL dependencies aren't existing in the same directory (and therefore can't be resolved without help from NCrunch) - or it could be a side-effect of the instrumentation. You may be able to prove or disprove either of these theories by changing the 'Instrument output assembly' and 'Copy referenced assemblies to workspace' settings to see if this makes any difference.

2: Build processes will generally have a higher priority than test tasks in NCrunch's processing queue, although this may not be the case if test tasks are queued manually or if they represent impacted tests. If the execution of tests isn't particularly important to you, turning off instrumentation (using the 'Instrument output assembly' setting) will prevent the impact detection from working and should cause build tasks to generally sit higher in the queue .. although this may have some undesirable side-effects.

3: NCrunch does have some known issues around resolving some types in the debugging environment. These issues include lack of recognition of compiler-generated methods containing the 'yield' statement, and lack of namespace resolution for types and extension methods in a global space. I have an item on the backlog to address these issues, though due to their complexity it may take some time to resolve them. In most situations you can work around the issue by specifying a full namespace when referencing any type with the debugger.

4: This is a really, really interesting idea. Because of the need to obtain metrics and other information from the code being tested, it would be necessary for NCrunch to have control over the testing environment (so nightly builds on a TFS server probably wouldn't work for this). I do, however, have some long terms plans that may eventually make this sort of thing possible. Watch this space :)


Cheers,

Remco

NCrunch will always use the build configuration that's specified in your .proj file (it doesn't consider the build configuration selected in VS), so most likely you have the x64 configuration set as the default in the .proj file for this EXE. This should be a very simple fix - just adjust the lines of code that are something similar to:

<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x64</Platform>

I've been looking at caching mechanisms to improve the initialisation time. Rest assured that I also start VS approx 20-30 times per day while working on NCrunch, so a slow startup does drive me crazy! It will happen soon :)


Thanks!

Remco

Hi,

The creation of these folders is handled by MSBuild. Most likely the reason you're seeing strange behaviour is because NCrunch doesn't override the $(Configuration) and $(Platform) build properties - it will instead use the defaults as provided in the .proj file.

The best way to get an understanding of how this works is to try building your project with msbuild.exe using the command line. You'll notice that the files are deposited in the same manner as NCrunch (as it works in the same way).

The only way to fix this is to modify your .proj files to ensure that the default $(Configuration) and $(Platform) properties are set to what you would normally expect for your test environment. NCrunch relies on these values where VS will typically just inject them, so adjusting them should solve issues such as this.

Cheers,

Remco

This looks like a localisation issue while parsing the exception being thrown. There's a fix available for this in a development build of 1.40b if you'd like to give it a try. Download links are available on this thread: http://forum.ncrunch.net...ding-test-execution.aspx

Good to hear! I didn't know about the Russian display issue. Is there any chance you can show me a screenshot of this? I'd really like to have it sorted before the 1.40b release goes out the door properly :)

Thanks - I'll PM you an email address you send can it through to.


Cheers,

Remco

NCrunch will usually disable itself if you run the configuration wizard, as many of the settings controlled by the wizard can only be changed while the engine is stopped. You should be able to re-enable NCrunch via the normal menu at the top.

Anyway feel free to send through any details if you manage to recreate the issue again.


Thanks!

Remco