Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Unnecessary .ncrunchproject files
Options
Previous Topic Next Topic
jnm236
#1 Posted : Monday, February 6, 2017 4:00:14 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
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?
Back to top
 |  Edit by user
Remco
#2 Posted : Monday, February 6, 2017 10:07:38 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
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 you're concerned about the config files polluting your VCS, you might want to look into this setting - http://www.ncrunch.net/documentation/reference_solution-configuration_project-config-file-storage-path.
Back to top
jnm236
#3 Posted : Tuesday, February 7, 2017 4:38:11 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
> 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!
Back to top
1 user thanked jnm236 for this useful post.
Remco on 2/7/2017(UTC)
sjkirk
#4 Posted : Tuesday, February 28, 2017 11:24:15 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/23/2015(UTC)
Posts: 9
Location: United Kingdom

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
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.
Back to top
Remco
#5 Posted : Tuesday, February 28, 2017 11:29:32 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
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.
Back to top
sjkirk
#6 Posted : Tuesday, February 28, 2017 11:37:27 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/23/2015(UTC)
Posts: 9
Location: United Kingdom

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
Actually, having actually tried that setting, it seems to work perfectly! Thanks Remco!
Back to top
1 user thanked sjkirk for this useful post.
Remco on 2/28/2017(UTC)
jnm236
#7 Posted : Tuesday, March 21, 2017 7:51:49 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2015(UTC)
Posts: 57
Location: United States of America

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
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.
Back to top
Remco
#8 Posted : Tuesday, March 21, 2017 11:12:35 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
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.

Sorry but I will not be changing this.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.054 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download