I have 21 .ncrunchprojects getting created containing nothing but `<PreviouslyBuiltSuccessfully>True</PreviouslyBuiltSuccessfully>`.
I don't mind it in an .ncrunchproject.user or ideally some cache location not mixed with settings because it's not really a setting, but I believe .ncrunchproject gets checked into source control by design so that project-level settings can be shared. I don't want the thrash of PreviouslyBuiltSuccessfully causing changes to source control. Can it be moved?
This setting may seem small and annoying, but for new users, it's a big deal.
The setting controls the presence of a hyperlink to the documentation allowing people to troubleshoot problems with projects that NCrunch has never been able to build before. If this is moved into the .user file, people will get notified of this for projects that are already configured by other team mates and have been built by NCrunch correctly.
How is the flag causing problems for you? Does it trigger your VCS to think the file has changed, when it actually hasn't?
> If this is moved into the .user file, people will get notified of this for projects that are already configured by other team mates and have been built by NCrunch correctly.
This would be preferable to me. Anyway, things change. I wouldn't want this info checked into source control because it's not uncommon to do things like switch a .csproj from packages.config to project.json or soon the new CPS csproj. Or work with msbuild.
> How is the flag causing problems for you? Does it trigger your VCS to think the file has changed, when it actually hasn't?
Besides irritating a perfectionist haha, just noise. I don't want to check in NCrunch files in non-test projects especially.
I like tools to have a minimal footprint, if any, on source control.
> If you're concerned about the config files polluting your VCS, you might want to look into this setting -
There is one .ncrunchproject which I do want checked in exactly where it is. It contains ConsiderInconclusiveTestsAsPassing and IgnoredTests settings.
A solution-level switch to keep this PreviouslyBuiltSuccessfully unshared would be awesome!
This has been bothering me too recently: if one uses git submodules, then ncrunch will write project files to these submodules, causing git to complain that the submodule has been modified. Most of the time, the only thing in this project file is the <PreviouslyBuiltSuccessfully> element, as the submodules don't usually contain tests that are built from the main project.
This is a bigger problem for projects in submodules than for those in a regular repository, because often you're not *able* to commit changes to the submodule without forking, which is a rather drastic measure just to work around NCrunch's behavior.
I wasn't previously aware of the "Project Config File Storage Path" though; this would indeed help solve the problem, but as jmn236 said it appears to be an "all or nothing" approach.
The "Project Config File Storage Path" setting was actually designed specifically to address the problem with NCrunch config files messing with git submodules. Are you experiencing any problems with this setting?
Removing the 'PreviouslyBuiltSuccessfully' value from the configuration files would unfortunately create more problems than it would solve. This value does serve an important purpose for NCrunch, and it does need to be stored somewhere.
So here's the thing. Now we've moved to the new csproj. Having *.v3.ncrunchproject show up in Solution Explorer under every project, especially non-test projects, is irritating.
It's one thing to see an .ncrunchproject once in a while and know that it contains crucial settings which must be source-controlled.
It's another to deal with boilerplate we'd rather not see.
Hiding them from Solution Explorer by adding exclusions in every csproj for NCrunch is onerous. NCrunch is a testing tool and shouldn't make us dirty everything else.
Moving the .ncrunchprojects to a non-source-controlled location as you have suggested is a no-go, because one or two projects have crucial settings that need to be source-controlled in the .ncrunchproject.
The ideal scenario I could ask for is for <PreviouslyBuiltSuccessfully> elements to no longer be created, and for the UI to deal with the reality that PreviouslyBuiltSuccessfully is no indication into whether it will build again in the future or whether you'll need help with that.
The second-best scenario would be if I could set something in the .ncrunchsolution which would stop generating PreviouslyBuiltSuccessfully elements.
Sorry, there really isn't anything more I can do about this in NCrunch. It is normal practice for tools to place files adjacent to project files.
The PreviouslyBuiltSuccessfully flag is an important value that needs to be stored per project. Removing this value would create problems far in excess of annoying config file that can be moved using a solution-level setting anyway.