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

Notification

Icon
Error
3 Pages123>
NCrunch 1.33b occasionally fails to build an assembly, but provides no error information
Options
Previous Topic Next Topic
jeremygray
#1 Posted : Tuesday, September 6, 2011 5:50:39 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Since upgrading from 1.32b to 1.33b this morning I have seen it momentarily fail to build an assembly on two occasions (a different assembly each time.) When this happens, the NCrunch Tests window shows the assembly with a red X. Clicking on that entry does not show any related text in the lower pane as it does when there is, for example, a syntax error in one of the source files. Disabling and re-enabling NCrunch resolves the issue until it next pops up.

My morning has been pretty light in terms of working in the IDE. My afternoon will be more code heavy, though, so I'll keep an eye on things to see if I can spot any patterns. With that in mind:

What actions can I take and/or information can I collect that would help diagnose this issue further?
Back to top
Remco
#2 Posted : Tuesday, September 6, 2011 6:56:47 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
The best thing you can do is use the 'Submit Bug Report' option in the NCrunch menu as soon as you see this issue occur.

The bug report contains a detailed log file containing the workings of the engine up until the point where you submit it, so it's the single best weapon I have for reproducing and correcting the issue.

Out of interest, does right clicking the project and choosing 'Rebuild' help at all?
Back to top
jeremygray
#3 Posted : Wednesday, September 7, 2011 3:43:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
I just ran into this issue again while adding signatures to a number of tests, then interfaces, then implementations. While in the midst of this NCrunch was rightly showing a Build error in one or more projects. Upon completing the last update (after which the IDE was happy to build the solution) NCrunch was left out of sync and showing (in the bottom pane of the NCrunch Tests window after selecting the project that failed to build) the last compilation errors in the last project to be updated during the flurry of changes. Using the context menu for that NCrunch Tests project entry to try a Rebuild has no effect. Disabling and enabling NCrunch via its main menu entry worked, however.

PS - I tried to submit a bug report when I spotted the issue but I received some kind of connection error. I'll give it another try when next I bump into the issue.
Back to top
Remco
#4 Posted : Wednesday, September 7, 2011 7:01:11 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Interesting .. Were you doing any kind of bulk operations at the time that it failed? For example - a rename or refactoring of some kind?
Back to top
jeremygray
#5 Posted : Wednesday, September 7, 2011 10:05:44 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Some copy/paste/edit from existing members and plenty of Alt-Enter in R# to, for example, update a class' implementation of an interface to account for new signatures on the interface.
Back to top
1 user thanked jeremygray for this useful post.
Remco on 9/8/2011(UTC)
jeremygray
#6 Posted : Thursday, September 8, 2011 5:58:23 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
I just had the issue crop up again this morning, but this time around it was simple typing of a new statement into an existing source file that NCrunch had just happily built. Clicking on the relevant project in the NCrunch Tests window shows nothing in the lower pane.

On a somewhat related note, I am still receiving an error when trying to submit a bug report. To save me from having to break away from my work to figure this out: could you let me know what the bug report tool is trying to connect to, and how? I'd like to submit reports but it looks like I might need to get the sysadmins here to (re-)open things up.
Back to top
Remco
#7 Posted : Thursday, September 8, 2011 8:06:01 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
It sounds to me like some of the change messages are being skipped somehow. If you have it happen to you, changing the file affected should cause it to resync and carry on. I'll see what I can do about trapping the issue and figuring out what's going on.

The bug reporter connects via http to app.ncrunch.net:80 and bugs.ncrunch.net:80, I hope this helps with any firewall configuration.
Back to top
jeremygray
#8 Posted : Tuesday, September 13, 2011 8:39:37 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Here's today's example (which I also saw yesterday but hadn't had a chance to mention until now): NCrunch just went from green into red with a Build error (that includes no details in the lower pane of the NCrunch Tests window) after I edited a text file that just happens to be in the project for convenience of use but which is set to Build Action - "None", Copy to Output Directory - "Do not copy". This is a file that NCrunch shouldn't even care about but editing it caused NCrunch to stop building properly until I told it to resync via the button in the NCrunch Tests window.
Back to top
Remco
#9 Posted : Tuesday, September 13, 2011 9:01:16 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
That's definitely not right. Have you had any luck in opening up your firewall for the bug reporter? If you manage to capture something like that with the reporter, the log file will be really useful.
Back to top
jeremygray
#10 Posted : Tuesday, September 13, 2011 9:51:36 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Sorry, not yet as I've been tied up with other things. Once things settle down I'll see what I can do about that.
Back to top
1 user thanked jeremygray for this useful post.
Remco on 9/14/2011(UTC)
jeremygray
#11 Posted : Thursday, September 15, 2011 4:46:54 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Today's variation :) - editing a form in a designer.

As an additional note, in all of the cases I have described so far, "changing the file affected should cause it to resync and carry on" has never worked for me. I have always had to tell NCrunch to resync.
Back to top
Remco
#12 Posted : Thursday, September 15, 2011 4:55:37 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I wonder if there are some characteristics to your solution that make this issue hit you particularly hard :)

Is it a large solution? What is the rough specification of the system you're using? High-spec or slow-spec CPU?
Back to top
jeremygray
#13 Posted : Tuesday, September 20, 2011 8:07:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
41 projects. Approx 120k lines (as measured by VS 2010 code metrics), 68k of which are spread almost evenly across two of the 41 projects. The rest of the projects range between a few hundred lines and a few thousand lines. Only around 2200 of the total lines are in tests, spread across a couple of the 41 projects.

The system is a Core i5 750 2.67GHz with 4GB of system memory. Win 7 x64. Fairly standard 320GB SATA drive, nothing fancy and definitely the lowest-scoring item on the experience index at 5.9. NVIDIA Quadro FX 580 graphics running the latest drivers as of early August. Work runs McAfee, as much as that saddens me, and while I cannot disable it I have been able to configure it to exclude my dev folders and the ram drive that I set up for NCrunch.

1.32b was fine with this solution, except for having to disable instrumentation in all but the test projects. Perhaps I'll put the instrumentation settings back (or closer to) the way they were then just to see if it makes a difference. All said, however, I would much rather have 1.33b and have to resync NCrunch occasionally than run 1.32b without instrumentation. 1.33b is almost entirely awesome. :)
Back to top
Remco
#14 Posted : Wednesday, September 21, 2011 11:48:24 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
1.33b introduced quite a critical change in the way that assembly references are resolved - Over the last week, I've noticed a number of problems in here myself... they are admittedly particularly frustrating, though so far I've only seen them when CopyReferencedAssembliesToWorkspace is used. Do you have this switched on for any of your projects?
Back to top
jeremygray
#15 Posted : Wednesday, September 21, 2011 6:37:30 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
CopyReferencedAssembliesToWorkspace is false for all projects in the solution. (For all projects the default test timeout of 60000 is assigned, instrumenting of the assembly is enabled, and pre/post build event running is disabled.)
Back to top
Remco
#16 Posted : Thursday, September 22, 2011 8:15:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Gotcha. I have some ideas on how I can fix this now .. I think I know what's going on. Fix will be in 1.34b.
Back to top
jeremygray
#17 Posted : Thursday, September 22, 2011 11:54:12 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Excellent! Out of curiosity, can you provide any insight into what you think is going wrong?
Back to top
Remco
#18 Posted : Friday, September 23, 2011 8:50:29 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
When NCrunch creates an application domain for running tests, it wires together assemblies from different workspaces (and different file paths) in much the same way as other test runners do when they have shadow copy enabled. 1.33b relaxed some of the rules around how these assemblies were resolved. As a result, it seems that in some circumstances the test domain is being wired up with incorrect assemblies (i.e. ones from old workspaces). This can cause some really strange behaviour in the test domain, in addition to file locking problems during builds etc. I observed it happening a few times locally when using the CopyReferencedAssembliesToWorkspace option, and it really drove me crazy. I suspect there are other conditions that can cause this to happen, so the change I'm introducing in 1.34b is to tighten back up the resolution logic.

The CLR can be a bit of a pain when it comes to assembly reference resolution at runtime. It has an extensive set of rules that determine which assemblies will be resolved when they are required. Naturally these rules behave different in other environments and solutions, and not all of them can be overridden - so it has often been a source of problems over the last few months.
Back to top
1 user thanked Remco for this useful post.
jeremygray on 9/23/2011(UTC)
Remco
#19 Posted : Saturday, September 24, 2011 7:51:12 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Ok - the fix for this is out in 1.34b, released today :)
Back to top
jeremygray
#20 Posted : Monday, September 26, 2011 4:35:42 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/20/2011(UTC)
Posts: 32
Location: Vancouver, BC, Canada

Thanks: 1 times
Was thanked: 3 time(s) in 3 post(s)
Cool. I'm off today but will be sure to check it out first thing tomorrow.
Back to top
Users browsing this topic
Guest
3 Pages123>
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.090 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download