Forum member

Remco NCrunch Developer

7586 posts

Posts by Remco

  1. AdditionalFilesToInclude on multiple lines

    Thanks, I can see how this would be irritating. The config system is going to have a major overhaul soon - I'll note this down for review.

  2. NCrunch 2.23 causes InvalidProgramException to be thrown with exception filtering

    Hi, thanks for sharing this issue. This is likely being caused by NCrunch's instrumentation. There must be something in the CLR that doesn't like code within the exception filter from being instrumented. It's interesting that this only happens on Windows 10. I'll need to investigate this more …

  3. NCrunch Licence

    Hi, Thanks for posting. The 12 month period only applies to upgrades to new versions of the product. This means that after the 12 months are over, you can continue to use an older version of the product for as long as you like.

  4. Quick second build losing code coverage?

    [quote=robmen;8810]Just to close this thread. With v2.23.2 this issue seems to be resolved for me. Thanks for working on the fix.[/quote] Thanks for confirming!

  5. IDLE Grid Nodes at the end of the tests run

    [quote=avishnyakov;8807] Surely, at the end we really wanna get these test spread across nodes, not stuck on one node with several spare nodes. [/quote] Agreed. Normally the engine should be doing this for you. It's possible there is a good reason why it isn't happening that way.

  6. IDLE Grid Nodes at the end of the tests run

    [quote=avishnyakov;8805] Also, if this is happening for the first run ever, or over the "re-synch/re-run" all the test, how NCrunch would handle that?[/quote] Not very intelligently :( When NCrunch doesn't have any data on normal test execution times, it simply assumes that each test takes on…

  7. IDLE Grid Nodes at the end of the tests run

    [quote=avishnyakov;8803]No, fixtures are different. There is no setup or anything else, only tests.[/quote] Ok - If you were to run a test several times, would it report a consistent execution time for each run? Something else to check: Open the processing queue and look up one of the tasks w…

  8. IDLE Grid Nodes at the end of the tests run

    Are the tests placed within fixtures that have a long running setup time? The batching does take into consideration fixture set up times to avoid repeating a long fixture setup where possible.

  9. IDLE Grid Nodes at the end of the tests run

    Is it possible you have a setup where the first test run within a batch takes a very long time to execute, then every test after it is much faster? (i.e. a load-on-demand situation where significant time is spent at the start of the test run). If so, this might explain the grouping behaviour. NC…

  10. Filter tests with build configuration

    Hi, Thanks for posting! There isn't anything in NCrunch at the moment that tracks the build configuration selected in VS. NCrunch doesn't make use of this value itself - it instead relies on the default values specified in your project files or the 'Use build configuration' project-level NCru…

  11. Temporary "user" files being created

    [quote=MatthewSteeples;8794] There's something wrong with that logic then, because these files are being created _every_ few seconds, with different Guida each time. The screenshots I sent you were seconds apart and I was doing nothing in VS. This behaviour actually carried on after I closed VS for…

  12. NCrunch dots not showing correctly for VSTO project

    Yes, it looks like this is a 'lost reference': 'nCrunch.TestHost45.x86.exe' (CLR v4.0.30319: nCrunch.TestRunner.AppDomain_ca9ef31b355b4da581c044df1545bca2): Loaded 'C:\Users\aungu\AppData\Local\NCrunch\14580\2\_ncrunchreferences\Gsync.dll'. Symbols loaded. My assumption is that the Gsync assem…

  13. Temporary "user" files being created

    Hi, thanks for posting. This is by design. For NCrunch to be able to query information from MSBuild, it needs to create a temporary file adjacent to each of your project files that can then be passed through MSBuild to obtain detailed information about the project. The limitation here is that…

  14. Code coverage missing when using plain reference to project DLL

    [quote=ArneG;8787] It seems that the coverage dots in P code in this case still stay black in this scenario; am I correct? [/quote] Yes, you are correct. For this setting to behave the way you need it to, the assembly name must match the project name.

  15. Code coverage missing when using plain reference to project DLL

    Hi, thanks for posting. The 'Implicit project dependencies' setting exists for a different purpose. This setting is intended to help you find the location of assemblies in the NCrunch workspace using your own code at runtime - it won't change NCrunch's assembly resolution logic. The setting y…

  16. NCrunch dots not showing correctly for VSTO project

    Hi, thanks for sharing this issue. I have no personal experience with VSTO projects, but it appears to me that this project type involves the execution of a build step that requires referenced assemblies to exist in the same directory as the assembly being built. Although undesirable, this isn't…

  17. NUnit duplicate name warning without duplicate names

    [quote=ssg;8780] That removes the need to override ToString() in the actual code. I still wonder though, how NUnit could not have come up with a "sequence" based identification for data-driven tests? That would be more than enough between builds and debug attempts. We don't need a universally uniqu…

  18. NUnit duplicate name warning without duplicate names

    Hi, Please see here for more details about this problem - [url=http://forum.ncrunch.net/yaf_postst1799_Doesn-t-recognize-multiple-tests-with-same-name-using--ValueSource---NUnit.aspx]http://forum.ncrunch.net/yaf_postst1799_Doesn-t-recognize-multiple-tests-with-same-name-using--ValueSource---NUnit…

  19. Incorrect Coverage Metrics for single-line if-statements

    Hi Richard, I'm sorry, but there has been no change in the way this is handled by NCrunch. If I can find a feasible way to implement more detailed resolution of coverage in the tool in future, it will be implemented.

  20. IDLE Grid Nodes at the end of the tests run

    When you see this happen, is there any pattern as to how the 50-60 tests are split between different tasks in the processing queue? Are the tests all being grouped together? What is the normal run time of a single one of these tests?