I recently switched from Visual Studio 2013 to 2015 and currently I am evaluating the latest version of NCrunch.
I am using the visual studio git provider and NCrunch informed me about performance issues because of the Microsoft Git Provider scanning the files inside _NCrunch_SolutionName folder.
The solution is to redefine NCrunch Cache Storage Path to point somewhere else, which I did. However I am not happy with this for a couple of reasons.
1. I have to do this for every solution, and since I already have multiple topic branches per project in git this will require me to set the value many many times. A global setting would be much better.
2. To maintain backward compability a global variable "NCrunch Cache Storage Root" could be introduced which defaults to SolutionDir.
3. Already asked here: http://forum.ncrunch.net/yaf_postst1703_Possible-performance-issue-for-Git-repositories.aspx Being able to use environment variables would be helpful. I already configured my virus scanner to exclude %localappdata%\NCrunch so I would place the cache dir inside.
Daily Usage Issues
Improve NCrunch Cache Storage Path management
Started by SchlaWiener on 6,521 views
Remco NCrunch Developer
#8261
21 Jan 2016 12:02 UTC
Hi, thanks for sharing your feedback on this.
I've already been looking at adding support for environment variables in this setting.
There is also a long term plan to implement a more sophisticated configuration system that would allow many of the configuration options to be specified at different levels, with more granular options to override them in specific cases. This is being done in recognition of the fact that many people have far more specialised needs for the current set of config options than the existing config system can conveniently handle. Such a system would, in theory, allow you to set this value globally.
I've already been looking at adding support for environment variables in this setting.
There is also a long term plan to implement a more sophisticated configuration system that would allow many of the configuration options to be specified at different levels, with more granular options to override them in specific cases. This is being done in recognition of the fact that many people have far more specialised needs for the current set of config options than the existing config system can conveniently handle. Such a system would, in theory, allow you to set this value globally.
Post a reply
Log in to reply.