Build assemblies not optimiezed

Hi!

When I debug a test it seems that the assembly is build with optimization turned on so that some of the symbols aren't available (inspection not available).
When I debug with resharper I can inspect all the symbols no problem.

Is there a flag where I can tell ncrunch to include/exclude optimization or debug with optimization turned off?

Thanks

Hi, thanks for posting!

NCrunch deliberately turns optimisations off when it builds your project, as the optimisations prevent it from accurately instrumenting the output assembly.

It's possible there may be another reason why your debug evaluations are not working.

Are you seeing code coverage data for this project? Does this affect just one solution, or all of them?

I do see code coverage without any problems.
I had/have the this particular problem with multiple project setups over the last couple of years and today I decided to ask you if there is a way to fix it :)
The problem affects bigger solutions with multiple projects. Maybe thats the problem that the dependencies build with optimizing on?

Oh and another short question: my ram-disk (4 gb) with the ncrunch temp files is constantly running full and I have to reset ncrunch 4-5 times a day to clean it up. Is there a way to tell ncrunch to cleanup old artifacts from time to time?

If the code coverage is working correctly, then this is probably related to the debugger (or PDB data) rather than optimisations. Is there a pattern around which values can be evaluated when you are in a debug session? Does the debug session correctly stop at breakpoints?

Regarding the RAM disk, the best advise I can give here is to increase the size of your RAM disk. Workspace consumption works similar to memory consumption in an application; it is possible (with serious effort) to limit it, but there will be a serious performance cost attached to this. NCrunch will already clean up workspaces religiously, so there shouldn't be a need to do this manually. Reducing the 'Max number of processing threads' will mean you won't get so many workspaces, but this will then make NCrunch run slower. When the goal of using a RAM disk is to improve performance, this would seem slightly self-defeating :)

I didn't found a pattern yet, but I will pay attention to that from now on.
Will report back once I've found it.

@ramdisk: it's already 4 gb, that should be enough for 4 running threads, right?

SeriousM wrote:
@ramdisk: it's already 4 gb, that should be enough for 4 running threads, right?

It really depends upon the solution.

NCrunch can make several workspaces for each project in your solution, depending on your change patterns and the number of workspaces needed in parallel.

Because the workspaces are direct copies of the source of each project, large projects can consume quite a bit of space. If you're running out of space on the disk regularly, 4GB isn't enough for this solution.

Remco wrote:

SeriousM wrote:
@ramdisk: it's already 4 gb, that should be enough for 4 running threads, right?

It really depends upon the solution.

NCrunch can make several workspaces for each project in your solution, depending on your change patterns and the number of workspaces needed in parallel.

Because the workspaces are direct copies of the source of each project, large projects can consume quite a bit of space. If you're running out of space on the disk regularly, 4GB isn't enough for this solution.

I guess I found the problem: Once I hack on a non buildable solution state (incomplete statement somewhere) the RamDisk is running out of space if I just continue generating non buildable attempts.

SeriousM wrote:
I guess I found the problem: Once I hack on a non buildable solution state (incomplete statement somewhere) the RamDisk is running out of space if I just continue generating non buildable attempts.

Workspaces are always created to service build tasks. For this reason, it is unlikely for additional workspace space to be consumed at any time outside of NCrunch starting up builds (expect for tests that generate data on disk, but this is quite rare).

There really isn't anything that NCrunch can feasibly do here to limit its disk consumption. You either need to reduce the amount of concurrency through your settings, or you need to reduce the size of your projects on disk.