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

Notification

Icon
Error
Easier "Ignore Completely"
Options
Previous Topic Next Topic
willdean
#1 Posted : Wednesday, February 4, 2026 4:08:03 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 35
Location: England

Thanks: 8 times
Was thanked: 4 time(s) in 4 post(s)

Pure feature request, love the product, etc...

Far and away the most common "configuration" action I perform in NCrunch is to ignore projects. This is because our solutions always seem to be acreting little utilities, etc, which we don't want NCrunch to spend a single cycle or a single byte on supporting.

But it's something of a faff to disable projects:

* Go to "Configuration" (somewhere in the middle of a long menu)
* Decide if you need to be looking at "My Settings" or "Shared Settings" - and accomodate the vague feeling that whichever one you picked might have been the wrong one.
* Find the project (they're grey-on-blue or light-grey-on-blue)
* Find the "Ignore this component completely" option - it's the 4th one down in the 2nd sub-category
* Use a combo box to make a true/false selection (believe me, I sympathise with the motivations for this on the programmer's side, but it's horrible UX...)
[ Chosing to ignore a project now causes NCrunch to restart completely and reload all the other projects.]
* Wait for this restart to settle down and then repeat for the next project you want to ignore

I don't feel I'm special-pleading for my own favourite option here: "ignore completely" is fundamentally different to all the other options (because it supercedes everything else), and I think it should have special treatment, not be buried in among everything else.

So:
* Please could we have something like a checkbox or a right-click option on each project to allow us to ignore it, perhaps even in the "main" NCrunch window (ctrl-shift-m)
* Please could NCrunch not restart when a project is ignored. Just ignore it from that moment on.

Thanks!
Back to top
Remco
#2 Posted : Wednesday, February 4, 2026 10:58:17 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,474

Thanks: 1014 times
Was thanked: 1361 time(s) in 1264 post(s)
Hi, thanks for sharing this.

Not promising anything right now, but I'm hoping I could ask a few things to get a better understanding of your situation.

How many solutions do you use NCrunch on? Are you hopping between many projects very often?

Do you often need to ignore and then unignore specific projects as part of your workflow?

Are the projects you're ignoring unable to build using NCrunch? Or are you doing this for optimisation?

Can you confirm which colour scheme you're using? (grey-on-blue or light-grey-on-blue doesn't sound normal)

Ignoring a project is a serious change under NCrunch. The intention behind this setting is that you'll likely use it when you introduce NCrunch to a solution and then probably never again. An important reason for why it's buried in the configuration is that it's a serious setting that can permanently break the solution if the user doesn't know what they're doing, as ignoring a project will cause any other project depending on it to fail.

My fear is that if it's made more accessible, new users will treat it like the ignored tests feature, then become confused when everything stops working. Normally you shouldn't need to ignore a project unless for some reason NCrunch can't build it. I'm wondering if we're instead looking at a performance issue rather than a UX one?

I'll also add that it should be possible to select multiple projects in the UI and change the setting for all of them at once. This will prevent needing to wait for the engine to restart after each individual change. You can also turn off the engine before changing the settings to prevent it needing to restart while making adjustments.
Back to top
 |  Edit by user
willdean
#3 Posted : Friday, February 6, 2026 11:40:56 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 1/31/2012(UTC)
Posts: 35
Location: England

Thanks: 8 times
Was thanked: 4 time(s) in 4 post(s)
Remco;18600 wrote:
How many solutions do you use NCrunch on? Are you hopping between many projects very often?


Lots, over time - 20, perhaps?
I probably work on 6-8 regularly.
I have three open in different instances of VS at the moment, 5 would probably be the most.

Remco;18600 wrote:
Do you often need to ignore and then unignore specific projects as part of your workflow?


No, it's mostly about ignoring projects which are never going to be relevant - usually utilities which depend on all the libraries in the solution but which are not themselves unit-tested.

Remco;18600 wrote:
Are the projects you're ignoring unable to build using NCrunch? Or are you doing this for optimisation?


It's optimisation - I don't want to see stuff being buit/copied unnecessairly, and NCrunch seems to unroll dependences somehow, so one can see a lot of copies of the same libraries in the working space - presumably because they're depended on by lots of different components? I'm not complaining about that, but I don't want any of it to happen on behalf of a utility I never wanted NC to bother itself with.

Remco;18600 wrote:
Can you confirm which colour scheme you're using? (grey-on-blue or light-grey-on-blue doesn't sound normal)


I'm not using any colour scheme that I'm aware of. It's possible that it's only the disabled projects that are really grey - maybe the non disabled ones are actually black. The "blue" is a sort of light steel blue - I can't paste an image in here.

Remco;18600 wrote:

Ignoring a project is a serious change under NCrunch. The intention behind this setting is that you'll likely use it when you introduce NCrunch to a solution and then probably never again. An important reason for why it's buried in the configuration is that it's a serious setting that can permanently break the solution if the user doesn't know what they're doing, as ignoring a project will cause any other project depending on it to fail.


That sounds like the effect I want. But the particular solution I'm looking at right now had NCrunch "introduced to it" when you started the company and has been joined at the hip ever since. Since then many, many projects have come and gone (or at least, been unloaded) - many/most of them want to be NCrunched, quite a few don't. There are currently 23 projects in the solution and 7 of them are ignored.

Remco;18600 wrote:

My fear is that if it's made more accessible, new users will treat it like the ignored tests feature, then become confused when everything stops working. Normally you shouldn't need to ignore a project unless for some reason NCrunch can't build it. I'm wondering if we're instead looking at a performance issue rather than a UX one?

I'll also add that it should be possible to select multiple projects in the UI and change the setting for all of them at once. This will prevent needing to wait for the engine to restart after each individual change. You can also turn off the engine before changing the settings to prevent it needing to restart while making adjustments.



The multiple project thing is helpful and I didn't know that, thanks.

But as for if this is a performance problem: I absolutely 100% consider that copying a project and building it when I didn't want it copied or built is a performance disaster. Every single cycle of CPU, byte of cache-washing and sector of disk used in such an activity is 100% wasted, and if my crappy little utility is dependent on an great big tree of libraries it's going to happen over and over and over again as I work on those libraries. If I'm waiting while NC says "build in progress" and I go and look at the activity queue and see a bunch of projects that are irrelevant in there then I want to stop them being built.

But anyway, it's not a big deal, and I have spent more time writing these two posts than I shall ever spend disabling projects, so I cannot advance a very honest argument about wasted time...

Thanks!
Back to top
Remco
#4 Posted : Saturday, February 7, 2026 12:52:09 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,474

Thanks: 1014 times
Was thanked: 1361 time(s) in 1264 post(s)
willdean;18611 wrote:

Lots, over time - 20, perhaps?
I probably work on 6-8 regularly.
I have three open in different instances of VS at the moment, 5 would probably be the most.


That's some impressive multi-tasking.

willdean;18611 wrote:

That sounds like the effect I want. But the particular solution I'm looking at right now had NCrunch "introduced to it" when you started the company and has been joined at the hip ever since. Since then many, many projects have come and gone (or at least, been unloaded) - many/most of them want to be NCrunched, quite a few don't. There are currently 23 projects in the solution and 7 of them are ignored.


That's old. It's also a reminder to me about the important of continuing to support older platforms. Do you mind me asking which version of VS you are running?

willdean;18611 wrote:

But as for if this is a performance problem: I absolutely 100% consider that copying a project and building it when I didn't want it copied or built is a performance disaster. Every single cycle of CPU, byte of cache-washing and sector of disk used in such an activity is 100% wasted, and if my crappy little utility is dependent on an great big tree of libraries it's going to happen over and over and over again as I work on those libraries. If I'm waiting while NC says "build in progress" and I go and look at the activity queue and see a bunch of projects that are irrelevant in there then I want to stop them being built.


That's a fair assessment. It's a bit unfortunate that needing to support platform abstractions means NCrunch has to 'churn' up quite a bit of waste, with a lot of files copied. Ideally, the sandbox would be lighter weight, but there's no practical way to implement that without breaking a lot of stuff for everyone.

A few things you might be interested in knowing:
- A project that is never changed will only have one workspace created by NCrunch, so it's only ever copied once. It will also only be built once, unless the 'Copy referenced assemblies to workspace' setting is being used
- Modern SSDs are very fast. Copying files and building workspaces is generally not a serious performance consideration unless they have massive resource files or an absolute ton of code
- However, actually BUILDING such projects can be a massive drain on resources, especially as MS's compiler optimisation goals have moved more towards lots of parallel threads rather than one insanely optimised one
- After the first build run/initialisation, everything always works faster

willdean;18611 wrote:

But anyway, it's not a big deal, and I have spent more time writing these two posts than I shall ever spend disabling projects, so I cannot advance a very honest argument about wasted time...


You didn't directly suggest this, but I don't want you to feel that raising something like this is a waste of time. Unless people open discussions about issues like this, I can remain blind to them. I can't promise the specific change you're after, but you've given me reason to think about your experience here, and I'm grateful for that.

A question that I do have: Is the performance issue bothering you more specific to the initial engine startup? Or to the time the engine takes to report results?
Back to top
Users browsing this topic
Guest (2)
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.053 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download