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

Notification

Icon
Error
2 Pages12>
build failed on Resharper Change Signature function
Options
Previous Topic Next Topic
alberd_m
#1 Posted : Thursday, March 9, 2017 9:47:25 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2017(UTC)
Posts: 4
Location: Canada

Thanks: 1 times
Hi,

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.

It's Make Ncrunch less usefull for refactoring !
Back to top
 |  Edit by user
Remco
#2 Posted : Friday, March 10, 2017 3:34:43 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this problem.

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.
Back to top
alberd_m
#3 Posted : Friday, March 10, 2017 3:52:10 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2017(UTC)
Posts: 4
Location: Canada

Thanks: 1 times
Hi,

Thanks for answer.

Yes I think it's happens every time.

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.
Back to top
Remco
#4 Posted : Friday, March 10, 2017 6:21:19 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
alberd_m;9924 wrote:
Hi,

Thanks for answer.

Yes I think it's happens every time.

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.
Back to top
Remco
#5 Posted : Sunday, March 12, 2017 10:21:19 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
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.
Back to top
 |  Edit by user
offset123
#6 Posted : Monday, March 13, 2017 7:06:00 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
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:

Code:

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;9950 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.
Back to top
 |  Edit by user
1 user thanked offset123 for this useful post.
alberd_m on 3/13/2017(UTC)
Remco
#7 Posted : Monday, March 13, 2017 9:19:06 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
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?
Back to top
alberd_m
#9 Posted : Monday, March 13, 2017 2:56:30 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2017(UTC)
Posts: 4
Location: Canada

Thanks: 1 times
(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)

JPB
Back to top
 |  Edit by user
Remco
#10 Posted : Monday, March 13, 2017 10:54:26 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
GOT IT!

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.

Thanks for all of your help.
Back to top
offset123
#8 Posted : Tuesday, March 14, 2017 6:54:09 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
Remco;9956 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 :)
Back to top
offset123
#12 Posted : Tuesday, March 14, 2017 6:55:18 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
Remco;9958 wrote:
GOT IT!

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.

Thanks for all of your help.


Cool! :-)
Back to top
alberd_m
#11 Posted : Tuesday, March 14, 2017 12:57:56 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/9/2017(UTC)
Posts: 4
Location: Canada

Thanks: 1 times
Remco;9958 wrote:
GOT IT!

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.

Thanks for all of your help.


Nice ! Happy to help you ;)
Back to top
Remco
#13 Posted : Wednesday, March 15, 2017 4:36:04 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
A fix for this is now out with v3.6.
Back to top
offset123
#14 Posted : Sunday, March 19, 2017 11:08:00 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
Remco;9965 wrote:
A fix for this is now out with v3.6.


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).
Back to top
Remco
#15 Posted : Sunday, March 19, 2017 12:04:04 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
offset123;10022 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?
Back to top
offset123
#16 Posted : Sunday, March 19, 2017 2:30:34 PM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
Remco;10023 wrote:

This doesn't sound like a synchronisation issue. Are you using the 'Run impacted tests automatically, others manually' engine mode?


Yes
Back to top
Remco
#17 Posted : Sunday, March 19, 2017 10:53:41 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
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'.
Back to top
offset123
#18 Posted : Tuesday, March 21, 2017 10:12:55 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
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.
Back to top
Remco
#19 Posted : Tuesday, March 21, 2017 10:17:56 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
offset123;10060 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.



The pinned tests mode has a different configuration option that will only show the coverage markers for tests that are pinned.

You can change all of these if you like. There is an option to customise the engine modes in the NCrunch menu and you can change them entirely.
Back to top
offset123
#20 Posted : Tuesday, March 21, 2017 10:22:11 AM(UTC)
Rank: Member

Groups: Registered
Joined: 8/24/2015(UTC)
Posts: 16
Location: Slovenia

Was thanked: 2 time(s) in 2 post(s)
Remco;10061 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).
Back to top
Users browsing this topic
Guest
2 Pages12>
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.177 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download