For a while now on a large number of solutions that I enable NCrunch on, when I close visual studio and then open the solution again NCrunch is disabled.
If anyone knows some common reasons that could cause this please let me know, as this is starting to become very annoying.
Remco NCrunch Developer
#6550
19 Oct 2014 23:59 UTC
The flag that controls the enable/disable status of NCrunch when a solution has been opened can be found in the .ncrunchsolution file next to your .sln file:
<SolutionConfiguration>
<FileVersion>1</FileVersion>
<AutoEnableOnStartup>False</AutoEnableOnStartup>
...
</SolutionConfiguration>
When you manually enable NCrunch on a solution, NCrunch will set the AutoEnableOnStartup to 'True' in memory, then write this back to the file.
If you manually disable NCrunch, it will set the value to False and again, will write it back to disk.
Closing VS will create a shut-down sequence in which NCrunch won't adjust this flag. This is to prevent the annoying behaviour that you've described.
My theory is that NCrunch is having trouble writing this value to the file. Is the file read-only perhaps? Or locked somehow? Are you using a source control system that might prevent this from working? If so, it may be down to the simple action of checking the file out of source control, updating it, then committing with the flag set to True.
<SolutionConfiguration>
<FileVersion>1</FileVersion>
<AutoEnableOnStartup>False</AutoEnableOnStartup>
...
</SolutionConfiguration>
When you manually enable NCrunch on a solution, NCrunch will set the AutoEnableOnStartup to 'True' in memory, then write this back to the file.
If you manually disable NCrunch, it will set the value to False and again, will write it back to disk.
Closing VS will create a shut-down sequence in which NCrunch won't adjust this flag. This is to prevent the annoying behaviour that you've described.
My theory is that NCrunch is having trouble writing this value to the file. Is the file read-only perhaps? Or locked somehow? Are you using a source control system that might prevent this from working? If so, it may be down to the simple action of checking the file out of source control, updating it, then committing with the flag set to True.
Yeah on the solutions having the issue the file was readonly. Thank you for pointing me to the file and it being read-only.
I would think this could have been avoided if NCrunch would be simply detect this state and change to to be not a writable like ReSharper does for its settings file. Even visual studio will check out a file and make it writable if its in source control, and if its not and read only it will prompt me to change it to be writable. I am not sure how they became read-only, however I would think VS did something as the files are not even checked in.
I would think the use case here is that a user triggers a change in the NCrunch UI which requires a setting to be written, that the users expectations are that it will be persisted if no error occurs on closing the dialog. That the user would expect NCrunch to either simply make the file writable to make the change, or if its checked in check the file out and make the change. If you are not comfortable with those automatic choices then NCrunch could prompt the user for permission to take one of those actions when they close the dialog.
I would think this could have been avoided if NCrunch would be simply detect this state and change to to be not a writable like ReSharper does for its settings file. Even visual studio will check out a file and make it writable if its in source control, and if its not and read only it will prompt me to change it to be writable. I am not sure how they became read-only, however I would think VS did something as the files are not even checked in.
I would think the use case here is that a user triggers a change in the NCrunch UI which requires a setting to be written, that the users expectations are that it will be persisted if no error occurs on closing the dialog. That the user would expect NCrunch to either simply make the file writable to make the change, or if its checked in check the file out and make the change. If you are not comfortable with those automatic choices then NCrunch could prompt the user for permission to take one of those actions when they close the dialog.
Remco NCrunch Developer
#6741
12 Jan 2015 09:45 UTC
For anyone experiencing the issue above, I just wanted to add that the above information is out of date. The auto-enable setting has been moved to the user-specific configuration file, '.ncrunchsolution.user', which is a binary file. If you ensure that you have this file checked out of your VCS (or in an otherwise writable state) when you close the solution, NCrunch should auto-enable as designed.
Note that .user files shouldn't normally be checked into a VCS as they are considered to be local, user-specific settings. It may be better to remove the file from your VCS entirely.
Note that .user files shouldn't normally be checked into a VCS as they are considered to be local, user-specific settings. It may be better to remove the file from your VCS entirely.
Post a reply
Log in to reply.