Every time I open my solution NCrunch shows the First-run wizard

This is perhaps similar to this post, but the <AutoEnableOnStartup> element doesn't even exist in my .ncrunchsolution, nor is the file read-only.

If I manually add the element to the .ncrunchsolution file, then start VS again, it will happily overwrite the settings file again without that line, leaving me with the same behaviour again.

Hi, thanks for sharing this issue.

Looking at the way the auto-enable system is designed, it looks as though the information in the referenced forum post is out of date. The AutoEnable setting has been moved into the .ncrunchsolution.user file, which is a binary file. Is it safe to assume that you have this file locked/read-only and NCrunch is therefore unable to update it? If you check out the file before you close the solution or shut down VS, NCrunch will save the setting and should auto-enable as designed.

I'm also posting something in the other thread to avoid misleading other people. Sorry about this.

The file is not locked or read-only, nor is it checked into source control. If I move the file away and let NCrunch re-create it on VS shutdown (with NCrunch being enabled upon shutdown), I get a binary-identical .user file and the same behaviour when I start VS again.

Can you confirm which version of NCrunch you are running?

Sorry, I just re-read your post and realised that I've managed to get my wires crossed - the issue you're experiencing is not that NCrunch isn't auto-enabling, it's that you always get the wizard ...

The wizard has nothing to do with the auto-enable feature. It's controlled very differently.

There are two mechanisms underlying this feature, storing state in two different places. One is inside the .ncrunchsolution file, in the form of the 'FileVersion' property. Where the FileVersion does not match a value of '1', NCrunch will run the wizard with questions specific to the solution itself.

The second mechanism is in your global configuration file, under your user profile.. i.e.: C:\Users\Remco\AppData\Roaming\NCrunch\globalconfig.crunch.xml .. This also contains a FileVersion, which on the latest version of NCrunch will need to have a value of '2'. If this isn't the case, the wizard will be run with questions specific to your global configuration (i.e. CPU config etc).

Note that after NCrunch has saved configuration to both of the above two files, it will update the FileVersion properties accordingly and you shouldn't see the wizard again.

Considering that you've already checked over the .ncrunchsolution file thoroughly, I wonder if it's the global config file giving you trouble. If NCrunch isn't able to write to this file, you'll probably see this issue. You may also see this issue if you're running two very different versions of NCrunch in different versions of Visual Studio. For example, if you are running NCrunch v1.48 on VS2010 and NCrunch v2.11 on VS2013. The config file is shared between versions of NCrunch in a way that would probably cause these two versions to fight over the FileVersion property.

.ncrunchsolution has FileVersion=1, globalconfig.crunch.xml has FileVersion=2.

I seem to get a shorter wizard that just covers how many cores I want to use, which might be just the solution configuration wizard. When explicitly selecting NCrunch > Run Configuration Wizard I get a longer one that asks me a lot of other things as well (e.g. whether to run tests in parallel, etc.).

The global config is also not read-only. The only thing I managed to see right now is that you write integers with the user's current locale, which in my case (for i18n bug testing) uses a proper Unicode minus sign instead of the ASCII hyphen-minus. Reverting that to hyphen-minus and letting NCrunch write a new global config apparently fixes the issue. If I were to guess you write the values with the current culture, but try to read them using the invariant culture, which raises and exception, which is swallowed and interpreted as »config not present«.

Confusingly, a few settings are retained as they should be. If what I wrote above is indeed the reason, then some settings are read from the config, perhaps up to the first setting that won't parse correctly.

yworksjr wrote:.ncrunchsolution has FileVersion=1, globalconfig.crunch.xml has FileVersion=2.

The global config is also not read-only. The only thing I managed to see right now is that you write integers with the user's current locale, which in my case (for i18n bug testing) uses a proper Unicode minus sign instead of the ASCII hyphen-minus. Reverting that to hyphen-minus and letting NCrunch write a new global config apparently fixes the issue. If I were to guess you write the values with the current culture, but try to read them using the invariant culture, which raises and exception, which is swallowed and interpreted as »config not present«.

Great catch. This could well be what is causing the problem. Would you be able to try submitting a bug report after NCrunch has failed to read your configuration? The report may contain error information I can use to zero in on the problem. Also - can you confirm the language code of your current culture? I may be able to use this to reproduce+fix.


Thanks!

Remco

I've sent a bug report (with a working locale and properly-read config, though). The relevant change seemed to be that I had U+2212 as my minus sign. The base culture should probably not matter in this case, but was de-DE.