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

Notification

Icon
Error
3 Pages<123>
Projects won't build
Options
Previous Topic Next Topic
Remco
#21 Posted : Monday, November 19, 2012 7:53:26 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi Dan,

Sorry, I missed your earlier post. I hope you don't mind me asking a few more questions to help narrow this down further.

- What is your current setting for the 'Include Static References In Workspace' setting? Do any of your projects have this disabled?
- How frequently does this occur? (say, in terms of # of times per hours of use)
- Is it always xunit.dll? Or does it happen for other assemblies too?
- Is this happening for the same solution as the synchronisation issue you reported earlier?
- Do you have any source code available for this solution?


Thanks!

Remco
Back to top
DanHil
#22 Posted : Tuesday, November 20, 2012 9:57:53 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
Remco;3202 wrote:

- What is your current setting for the 'Include Static References In Workspace' setting? Do any of your projects have this disabled?

No. It is enabled for all projects.
Remco;3202 wrote:

- How frequently does this occur? (say, in terms of # of times per hours of use)

I think one to three times a day.
Remco;3202 wrote:

- Is it always xunit.dll? Or does it happen for other assemblies too?

As far as I am aware, it always is xunit.dll
Remco;3202 wrote:

- Is this happening for the same solution as the synchronisation issue you reported earlier?

It's a different project.
Remco;3202 wrote:

- Do you have any source code available for this solution?

You mean, source I can share? Unfortunately not.
Back to top
DanHil
#23 Posted : Tuesday, November 20, 2012 3:52:23 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
It looks like it happens only after I did a "Rebuild All". It doesn't happen always after a "Rebuild All", but I didn't observe it when *no* "Rebuild All" has been performed.
Back to top
Remco
#24 Posted : Tuesday, November 20, 2012 8:39:31 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
There are two things that jump into my mind when thinking about this problem:

1. Your build is (temporarily?) changing the state of your solution in a way that confuses NCrunch
2. You have a workspace isolation problem

After NCrunch has completed an entire cycle (and is sitting idle), what happens if you perform a 'Rebuild All' in Visual Studio? Does NCrunch crank back into life and try to start building again? If so, this means that there are files derived from your build process that are included in the NCrunch workspace - which is generally something you want to avoid and in rare situations may cause behaviour like what you're experiencing. You might be able to track down these issues by building projects one at a time, to see which ones are triggering NCrunch.

As I'm sure you'll have checked for absolute file path references, I think that a workspace isolation problem is less likely than the above issue - but do make sure you don't have any state that might be shared in any way between the code in the NCrunch workspace and your original solution. There are tricks to finding absolute file path references, such as moving your solution to a different location to see if anything breaks.
Back to top
DanHil
#25 Posted : Tuesday, November 20, 2012 8:51:16 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
I can't think of anything that changes the solution. Would it help, if I would send you the .sln and .csproj files?

Workspace isolation shouldn't be a problem. It builds fine on the build server and on the machines of other developers. Additionally, I searched for absolute references in all project files - there were none.
Back to top
Remco
#26 Posted : Tuesday, November 20, 2012 9:07:15 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
The .sln and .csproj files would certainly help. There may not be anything specific in the solution that changes itself - this can also be caused by the files NCrunch is referencing within the solution and whether these files are derived or not. For example, if the xunit.dll file is being referenced from the output directory of another project that may be updated as part of the build, this can trigger NCrunch to start working when it should be idle. How does NCrunch behave if you trigger a rebuild all?
Back to top
DanHil
#27 Posted : Wednesday, November 21, 2012 11:57:16 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
I sent you the project files. The project that has these symptoms is GA.Exports.UnitTests.

NCrunch is idle most of the time but at the end, right before the Rebuild All finished, it starts building.
Back to top
 |  Edit by user
DanHil
#28 Posted : Wednesday, November 21, 2012 12:09:56 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
BTW: I found some references that indeed were referencing DLLs in the debug folder. At least that's what VS showed me. In the project file, these DLLs didn't have any hint path.
I changed that, and it fixed the problem! Rebuilding the solution now doesn't trigger a build by NCrunch!

It have been the following references in the failing project:

LCL.Common
LCL.Translation
Microsoft.Practices.Prism
Microsoft.Practices.Unity

However, I still think that this area could use some improvements - the fact that the project references assemblies without hint path leads to a failed build in NCrunch because it can't find a totally unrelated DLL.
Back to top
 |  Edit by user
Remco
#29 Posted : Wednesday, November 21, 2012 6:57:48 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Great to hear! Yes, I agree that this should be made MUCH more obvious. Normally this kind of behaviour doesn't create obscure problems like you've described above, but I think it would be better to warn people when this happens. NCrunch already tracks direct DLL references to outputs from project files ("lost" references), although it doesn't warn about direct DLL references to non-project outputs. I'll see what I can do in this area. Glad you managed to solve it.
Back to top
1 user thanked Remco for this useful post.
DanHil on 11/21/2012(UTC)
DanHil
#30 Posted : Wednesday, November 21, 2012 9:22:53 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
Thanks for all your help so far! :-)
Back to top
Remco
#31 Posted : Wednesday, November 21, 2012 10:06:08 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Welcome! Thanks for your patience in sticking through this. It seems to me that you have some very complex environments (at least from an NCrunch perspective), which do tend to make an NCrunch implementation challenging .. but it is also very rewarding. You are helping to make NCrunch a better and more reliable tool.


Cheers,

Remco
Back to top
DanHil
#32 Posted : Wednesday, December 5, 2012 9:10:50 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
I had this problem again yesterday. It was a more tricky variation of the previous problem.
The error I got from NCrunch was the same, but this time there were no references without a hint path and additionally, there were no references to a debug folder.

It turned out to be the following:

Each project has the same output path set (something like ..\Shell\Module), so that all the project outputs are in one place.
There is another folder (..\Shell\Runtime) that contains third party DLLs needed by our projects.
During build, these referenced files are copied to ..\Shell\Module.
Now, one of the unit test projects also needed some of those third party DLLs but didn't reference them from the Runtime folder but from the Module folder.
Back to top
 |  Edit by user
Remco
#33 Posted : Wednesday, December 5, 2012 9:32:48 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
MSBuild can be quite obscure in this way, and it can make your projects appear to be building in situations where they shouldn't be.

The 1.43 release is just a few days away, and it includes a change that checks for situations like this and will alert you to them. The warning will pick up any references to the build output directory of any project within the solution.

I'm amazed at how common this kind of reference arrangement is - I even had one in the NCrunch solution itself. Because MSBuild will implicitly reference DLLs from the output directory when it doesn't find them, it's surprisingly easy to limp along without noticing until someone performs a fresh check-out of the solution from a source control system. As small as this warning is, I have a feeling it may end up being quite a big feature for many people.
Back to top
1 user thanked Remco for this useful post.
DanHil on 12/5/2012(UTC)
DanHil
#34 Posted : Wednesday, December 5, 2012 9:35:32 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
Remco;3346 wrote:
As small as this warning is, I have a feeling it may end up being quite a big feature for many people.


I have the same feeling. This problem so far has cost me more time than NCrunch saved otherwise. I really hope that warning is specific in that it says which assembly is the problem.
Back to top
DanHil
#35 Posted : Wednesday, December 5, 2012 4:31:06 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
I have the feeling somewhere in NCrunch there lingers a bug.
Quote:
[17:28:08.7042-BuildTask-113] ERROR (Internal): System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\daniel.hilgarth\AppData\Local\NCrunch\1300\330\GA.CoreData.UnitTests\SalesQuotas\SalesQuotasViewModelTest\ApplyCommand.cs'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at nCrunch.Core.ProjectItems.SnapshotComponentMember.#=qRXf4UTRNcH1z5jIylzMoCAnFb2Tcmmdfhm21$Uud1PE=(String #=qIDcl4VGF5QsNDCrrEFo01w==)
at nCrunch.Core.ProjectItems.SnapshotComponentMember.WriteToFile(String fileToWriteTo)
at nCrunch.Core.WorkspaceManagement.WorkspaceBuilder.#=quyOMvjuRjJLlg$bsXV0j8WyvVbLWOkwSAug9mW9bjTY=(SnapshotComponent #=qDCuRCNUMnw5lOdfyM$WBrQ==, Workspace #=qjHvwLlb3x$Zum_vmRr9nrg==)
at nCrunch.Core.WorkspaceManagement.WorkspaceBuilder.UpdateExistingWorkspaceForComponent(SnapshotComponent component, Workspace& workspace)
at nCrunch.Core.WorkspaceManagement.WorkspaceManager.GetWorkspaceForComponent(SnapshotComponent snapshotComponent)
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents)
at nCrunch.Core.BuildTask.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.ProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.ProcessingQueue.#=qmw8TP7OZQi1Awa12Usj2mw==(ProcessingTask #=qbasxLAEC$whviXkzL8WKzA==)


Again, I am getting the error about a missing file. This time it is a different one, a .cs file. And again, the folder NCrunch tries to find it in doesn't even exist.
This started happening out of the blue. One second the tests were running, the next second they failed.

Resetting NCrunch helped, but it took about 2 minutes until NCrunch re-enabled itself.

I have to admit, this is getting a bit frustrating :-(
Back to top
 |  Edit by user
Remco
#36 Posted : Wednesday, December 5, 2012 9:02:53 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Do you remember much around what you were doing just before this error occurred? Were you moving or renaming files? Was the ApplyCommand.cs somehow removed from your foreground solution? If so, how was it removed?
Back to top
DanHil
#37 Posted : Wednesday, December 5, 2012 9:30:37 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
No, it hadn't been removed. A few minutes earlier, it had been added.
Back to top
Remco
#38 Posted : Wednesday, December 5, 2012 10:22:56 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Sorry, I've conducted a lengthy code review to try and identify scenarios that could create such a situation, but I still cannot reproduce it.

From what I can establish, it look as though the only way this could have occurred is if the file was somehow removed from the workspace. NCrunch would only do this while removing the workspace entirely, so I'm wondering if there is something else that could be interfering with this. Are you running a virus scanner or anything that might inhibit file I/O?
Back to top
DanHil
#39 Posted : Wednesday, December 5, 2012 10:25:22 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/12/2012(UTC)
Posts: 85

Thanks: 11 times
Was thanked: 3 time(s) in 3 post(s)
This is a corporate machine, so, yes, a virus scanner is running.

However, please take into account that not only the file is missing - the complete directory is missing.
Furthermore, this problem was consistent. Even a rebuild didn't fix it. Only a reset. So some random interference of a virus scanner seems unlikely.
Back to top
 |  Edit by user
Remco
#40 Posted : Wednesday, December 5, 2012 10:32:06 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
When you say that the directory was missing, do you mean the SalesQuotasViewModelTest directory, or the entire workspace?

Sorry for the virus scanner suggestion. I really doubt any kind of virus scanner would do this, but there is something very, very unusual going on in your environment.
Back to top
Users browsing this topic
Guest (2)
3 Pages<123>
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.096 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download