Would like to request an option to treat project references as binary references if they are no part of the current solution or if they have the 'Ignore this project completely' option enabled.

The reason for this is I work on a large codebase (thousands of projects and deep dependency tree) and our build environment requires that we use ProjectReference for our references (with some projects having dozens of references).

We do have a custom tool that copies the project's dependencies (the corresponding binaries for all the project references) from our build shares. We then pass the "/p:BuildProjectReferences=false" option to msbuild so it does not actually build all those project references.

However when I try to use NCrunch on such a project I get a "Missing or ignored project reference" warning. The build then fails because the code from that project reference is missing, i.e. I get an error like this:

The type or namespace name 'MissingType' could not be found (are you missing a using directive or an assembly reference?)

Here's a new idea: I'd like to be able to set a "failure baseline" in a project with a lot of failing tests.

Granted, such a project shouldn't exist in the first place! But I'm sure many of us have had the experience of getting to a new workplace where nobody's run the unit tests for a while, and suddenly the new guy runs them and there are hundreds failing.

Of course, the ideal thing would be to stop everything and fix them all. But try explaining to management why we can't fix bugs or write new features for a few weeks.

Thus, my proposal:

I fire up NCrunch, do a complete test run, and find out that 637 tests are failing. Now I can tell NCrunch to save that as a baseline. NCrunch will store the details on each of those 637 failing tests. Then when I modify code, and NCrunch reruns tests, it'll give me baseline-compared results (perhaps in a new window, separate from the normal test result window) telling me about (1) any new failing tests, and (2) any failing tests in that baseline that now pass.

Currently, if I write code that makes a failing test to pass but also makes a formerly passing test fail, I'll just see the same number, 637. With this new feature, I'd see a clear indicator that compared to the baseline, I have 1 more failing test and 1 more passing test, and I can see exactly what those tests are.

One question is how this would work with branches. I assume NCrunch isn't really branch-aware, but simply focuses on the current state of the code. The baseline should probably be a file saved in the project, such as an XML or JSON file. Then on a different branch I can keep the same file or overwrite it with a different baseline file if I so choose.

Background:
I got a solution with 117 projects. Oftentimes, I will sketch the implementation of a new subsystem and only partially test-cover it while doing the sketch. Once I'm satisfied with the shape and usage, I switch over to completely test-covering it. When doing this, it's helpful to look at the metrics view NCrunch provides.

However, because of the number of projects, it's a bit tedious to navigate to the right project, open the right namespace etc.

If there was a textbox on top which would represent a filter on project-names and namespaces that would automatically filter the list on keypress (simple matching: if a project-name or namespace contains the text, display it), that would make such flows faster.

When I am inside the source code of a Test, I'd like to have a button in the NCrunch test window that automatically focuses, inside the NCrunch test window itself, the entry corresponding to the test I am editing.

I already can do a similar thing with Visual Studio's Solution Explorer: if I am editing a source code file, I can press the "sync with active document" button in the toolbar of the solution explorer and get the source code I am editing highlighted in the solution explorer treeview, without having to browse the whole tree by myself.

I would expect NCrunch to have this identical feature.

The behaviour I am suggesting is the same of the native show "symbol references" visual studio popup window. (I am referring to that popup that opens when you click on the "<n> references" tag visual studio shows on top of method and properties declarations)

it is a pop up, but in its top-right corner there is a icon that, when clicked, turns it in a docked tab in the editor that does not go away.

the current approach (a simple popup window that goes away as soon as you start interacting with the editor) makes this list of very little use: if you want to check the source code of all the tests covering such line, you have every time to go back to such line (if you remember where it was), reopen the popup and remember which was in the list the last test you checked.

Please add an option to allow sorting by natural code order in the test window. So the tests appear in the same order in the test window as they do in the source code file.

Tests are typically written in roughly increasing order of complexity and dependency - in general, I would almost always want to fix a test that appears first in a source file before those that appear after it.

Tests are also often (very) loosely grouped together by position in the file - related tests will be next to each other, and it would be helpful to reflect that in the list of tests.

More details: https://forum.ncrunch.net/yaf_postst3041_Is-it-possible-to-list-tests-in-code-order--in-the-test-window.aspx