I Got the Ncrunch 3.3
I Got Resharper 2016.3.2 running on Visual Studio 2017.
When I "refactor" Change the signature of one function who is with an interface and a other implementation, Ncrunch looks not able to see changes and rebuild correctly.
I choose the option when à Refactor to mannualy correct all instance of change.
And after VS build works, Resharper build works but my DLL still not building with Ncrunch. I have to restart it.
Can you confirm that this happens each and every time you choose this particular refactoring? Is there a pattern around how these dependencies work across assemblies? NCrunch has a history of desync problems when certain refactoring changes are made (such as rename of deeply referenced types), though this has never been consistent enough to actually track down why it goes wrong. Usually right clicking on the failed project in the Tests Window and choosing to reload it is enough - you shouldn't normally need to reset the whole engine.
I'm not sure exactly for the exact pattern but I can begin with that.
-> Have a class with an interface and one implementation of that.
-> User resharper «change signature» feature to add parameter to a function.
-> Correct the TODO parameters they come up to the use of that function
-> Here the bug, the ncrunch build stop working after. All build now but not with ncrunch.
I'm not sure exactly for the exact pattern but I can begin with that.
-> Have a class with an interface and one implementation of that.
-> User resharper «change signature» feature to add parameter to a function.
-> Correct the TODO parameters they come up to the use of that function
-> Here the bug, the ncrunch build stop working after. All build now but not with ncrunch.
Thanks! I'll take a look and will see if I can get this to happen.
I've had a bit of a spin on this, but can't seem to make it happen in the way that you've described.
There's something here that seems a bit strange for me and I'm wondering if you can share some more information about the pattern you've found.
Basically, there are broadly two different types of changes that can occur that NCrunch responds to:
1. Project file XML changes
2. Source file text changes
Project file changes are very significant for NCrunch because when these happen, the engine needs to reload the project involved to retrieve updated dependency data from MSBuild. This action is complex enough that I wouldn't be surprised if a desync was possible somewhere in its handling.
Source file text changes are very simple - they are a one-way event that essentially just throws new source content at the engine which then rebuilds the project.
The refactoring action you've described should only perform source file text changes. Assuming NCrunch managed to desync with the source code referencing the changed signature, you would still need to go back and change this code to fix up the 'TODO' entries. When you do this, in theory the text change updates should resync the engine and all should be well.
So I guess what I'm saying here is that there is something happening in your environment that I don't understand.
After you've performed this refactoring, then fixed up the TODOs, can you describe in detail the state of the engine and how it is desynchronised? Something you can do is to look at the generated source files in the NCrunch workspace and compare these with your foreground source files, then see what's different. You can access the source files in the NCrunch workspace by right clicking on a project in the Tests Window and choosing Advanced->Browse to workspace.
EDIT: I also just wanted to add that of particular relevance is whether the source files changed by the refactoring are open in the IDE. This is quite important because otherwise they are treated as a file system change by NCrunch, which has different handling.
This is what I did to reproduce this problem:
1. Changed a signature (with R#) of an interface method to have an additional int parameter, and told R# to place "TODO"s in the existing calls. There are 6 implementations of that interface and one call of that method (so 6+1 files R# needs to update automatically due to the signature change).
2. There was only one call/TODO to fix, which I did.
3. The code now compiles, but NCrunch reports a build failure for that project, with errors like:
XXX.cs (9, 18): 'XXX' does not implement interface member 'YYY'
... where YYY is the interface method I changed signature of and XXX are the 6 implementation classes of that interface.
Remco wrote:
After you've performed this refactoring, then fixed up the TODOs, can you describe in detail the state of the engine and how it is desynchronised? Something you can do is to look at the generated source files in the NCrunch workspace and compare these with your foreground source files, then see what's different. You can access the source files in the NCrunch workspace by right clicking on a project in the Tests Window and choosing Advanced->Browse to workspace.
EDIT: I also just wanted to add that of particular relevance is whether the source files changed by the refactoring are open in the IDE. This is quite important because otherwise they are treated as a file system change by NCrunch, which has different handling.
I checked the source code in the NCrunch workspace, as you suggested. The interface YYY file was updated (with the new
int parameter), but the 6 implementation (XXX) classes was not. It's also clearly visible that the Date modified time of interface file YYY was 6 minutes after that of 6 XXX files, so I guess NCrunch somehow did not pick up the changes in the XXX.
When I do a reload of the failing project in NCrunch Tests windows, everything is fine.
When I repeated this same procedure a couple of times on the same code, NCrunch worked (detected all changes) without problems. So it's an intermittent thing.
Thanks! We're getting closer here. A couple more questions:
- At the time the refactoring was done, were any of the XXX source files open in Visual Studio?
- Are the XXX source files and the YYY interface file sitting inside the same project?
(C#)
For me I have many project in the same solution.
All is edit in Visual studio
I have the Project for all my interface.
And project for implementation.
When I begin the refactoring with de Change signature function all my files is close, and after they will be open if I Check « To enable Undo, open all files with changes for editing» (That checkbox is check for me)
The 'Unable undo' checkbox is critical in producing this problem.
When ReSharper changes the source files, it does so at the same time as opening them. This by-passes NCrunch's change handler, so the in-memory change goes undetected.
A fix will be in the next build.
This problem has been floating around for years, and until now, I've never been able to nail it down.
Remco wrote:Thanks! We're getting closer here. A couple more questions:
- At the time the refactoring was done, were any of the XXX source files open in Visual Studio?
- Are the XXX source files and the YYY interface file sitting inside the same project?
In my case all of the files were in the same project. I'm 100% sure not all of the XXX source files were open in VS, and 90% none of them were :)
The 'Unable undo' checkbox is critical in producing this problem.
When ReSharper changes the source files, it does so at the same time as opening them. This by-passes NCrunch's change handler, so the in-memory change goes undetected.
A fix will be in the next build.
This problem has been floating around for years, and until now, I've never been able to nail it down.
The 'Unable undo' checkbox is critical in producing this problem.
When ReSharper changes the source files, it does so at the same time as opening them. This by-passes NCrunch's change handler, so the in-memory change goes undetected.
A fix will be in the next build.
This problem has been floating around for years, and until now, I've never been able to nail it down.
A very similar behavior (not necessarily caused by R# refactoring) is still occurring. I have a bunch of tests that seem to be running on an older version of the SUT and they report failing errors even though the code is OK. If I run the same test with R#, they are passing.
Reloading the test project does not help. One thing that helps is running these tests explicitly, it then detects that SUT has changed and the tests pass. Another is making a substantive change in the SUT code (just adding whitespace does not help, but adding dummy code like "int a = 0; a++;" forces NCrunch to recompile SUT and then tests pass).
offset123 wrote:
A very similar behavior (not necessarily caused by R# refactoring) is still occurring. I have a bunch of tests that seem to be running on an older version of the SUT and they report failing errors even though the code is OK. If I run the same test with R#, they are passing.
Reloading the test project does not help. One thing that helps is running these tests explicitly, it then detects that SUT has changed and the tests pass. Another is making a substantive change in the SUT code (just adding whitespace does not help, but adding dummy code like "int a = 0; a++;" forces NCrunch to recompile SUT and then tests pass).
This doesn't sound like a synchronisation issue. Are you using the 'Run impacted tests automatically, others manually' engine mode?
Ok, this is a limitation of the impact detection then.
When you use this engine mode, NCrunch will only queue tests for execution when the impact detection flags them as being impacted by a change. Because the impact detection is not 100%, there are known situations where changes to code will not trigger the tests as impacted. The 'Run impacted tests automatically, other manually' mode also has a setting enabled that will only mark tests with the ? when they have been impacted, which can make it hard to identify tests that have been missed by the change detection.
If you need 100% accuracy here, you may be better off using the 'Run all tests automatically, others manually'.
Unfortunately even using the pinned tests mode doesn't seem to work correctly. I switched to running pinned tests automatically and have two pinned tests, but coverage bubbles are white for one.
offset123 wrote:Unfortunately even using the pinned tests mode doesn't seem to work correctly. I switched to running pinned tests automatically and have two pinned tests, but coverage bubbles are white for one.
Remco wrote:
The pinned tests mode has a different configuration option that will only show the coverage markers for tests that are pinned.
My point was that both of these tests are _already_ pinned and the coverage should be updated automatically for both of them. Subsequently, when I changed the code, both were run and coverage was updated. So there seems to be some kind of malfunction (this wasn't happening in v3.3 and before).
