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

Notification

Icon
Error
3 Pages<123>
NCrunch 1.33b occasionally fails to build an assembly, but provides no error information
Options
Previous Topic Next Topic
jeremygray
#21 Posted : Thursday, September 29, 2011 9:02:41 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)
Using 1.34b I have yet to see this problem rear its head for normal code file changes, but it is still causing problems when editing non-code files that are included in projects, even things like text files which have no build action, not even to be copied in as content! Luckily, my bug submission attempt went through without error so hopefully you'll be seeing some interesting details on your end.
Back to top
Remco
#22 Posted : Thursday, September 29, 2011 9:30:43 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I did get that one! Thanks for kicking it though. I've dropped it on my list of things to take a look at :)
Back to top
jeremygray
#23 Posted : Tuesday, October 11, 2011 5:33: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)
Following up after my latest submitted bug report regarding this issue: After NCrunch failed while editing a non-code file, editing a code file in the project resulted in no change in the NCrunch build failed status, regardless of whether or not the source change I made could be built (the first and third attempts) or could not be built (the second attempt.) As usual, clicking the NCrunch reset button got NCrunch working again.
Back to top
Remco
#24 Posted : Wednesday, October 12, 2011 11:35:38 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I've had a look at this one in detail and I think it's because of read-only file locking problems. Are you using TFS?
Back to top
jeremygray
#25 Posted : Wednesday, October 12, 2011 5:26:20 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)
Perforce, actually/sadly/happily/etc., so much the same in the file locking department.
Back to top
 |  Edit by user
Remco
#26 Posted : Thursday, October 13, 2011 6:18:17 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I've introduced a fix in 1.35b for the read-only file locks, so I think this should sort out the problem for you. I'll drop a note as soon as the build goes out the door. Meanwhile, hitting the reset button should cause NCrunch to throw out the workspaces containing the locks and allow you to keep working :)
Back to top
jeremygray
#27 Posted : Thursday, October 13, 2011 3:50:56 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)
Thanks for the update. I'll keep my eyes peeled for 1.35b.
Back to top
Remco
#28 Posted : Tuesday, October 18, 2011 6:26:16 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
This issue should be fixed in the 1.35b build that was released this morning.
Back to top
jeremygray
#29 Posted : Friday, October 21, 2011 4:08:09 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 have yet to see this issue re-occur, but I've not been making many, if any, of the kinds of edits since 1.35b that I was doing with the earlier versions. I'll let you know if something does pop up but in the meantime 1.35b is working nicely.
Back to top
partnerinflight
#30 Posted : Tuesday, November 29, 2011 3:18:42 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
Still seeing this issue on 1.35.0.16b. Filed a bug.

Basically have a WP7 solution with 6 projects. 4 fail to build with no error info, and red Xs; two just have question marks. Any ideas?
Back to top
Remco
#31 Posted : Tuesday, November 29, 2011 10:49:53 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi, thanks for posting.

I've had a look at the bug report you sent through. Is your application using silverlight for the windows phone? NCrunch doesn't support this platform yet, so I'd be surprised if this builds. I'm curious about the lack of information the engine is giving you about this though. Do you see any build messages in the processing queue window?
Back to top
partnerinflight
#32 Posted : Wednesday, November 30, 2011 1:06:19 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
yup, SL on WP7. Processing queue window?
Back to top
Remco
#33 Posted : Wednesday, November 30, 2011 2:11:02 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
You can get to the processing queue by choosing it from the NCrunch menu at the top of your IDE. It's a more physical view of what the engine is doing ... not great for keeping open while you work, but it's a good place to look if you want to know what's going on.
Back to top
partnerinflight
#34 Posted : Wednesday, November 30, 2011 7:18:44 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
Ah, yes. I do see info in the queue window. So what's the ETA for getting this working? ;)

[11:16:53.1602-BuildTask-45] ERROR (Internal): System.InvalidOperationException: Cannot modify an evaluated object originating in an imported file "C:\Program Files (x86)\MSBuild\Microsoft\Silverlight for Phone\v4.0\Microsoft.Silverlight.WindowsPhone71.Overrides.targets".

Server stack trace:
at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args)
at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowInvalidOperation(Boolean condition, String resourceName, Object arg0)
at Microsoft.Build.Evaluation.Project.VerifyThrowInvalidOperationNotImported(ProjectRootElement otherXml)
at Microsoft.Build.Evaluation.Project.RemoveItemHelper(ProjectItem item)
at Microsoft.Build.Evaluation.Project.RemoveItem(ProjectItem item)
at nCrunch.VSIntegration2010.MSBuildIntegration.BuildableProject.RemoveItems(String itemName)
at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.Build(ComponentBuildParameters parameters)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=q4KH$p4ixtdBrFcc94fR1muycNRVHYZAENVbIHJpqLq0=.#=qe12O05RR30a0U7lrtArlViAhwMyNTENKwIrlXB0_S3j2lA$7sUdht_ZqIa81nbWZ(IRemoteBuildRunner #=qzI24CDuxFN5h45ug7npZK2zEVgaOXwZIR4Mr7Se8Vyo=)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=qfO4zMrAChS8R_IQWnfyYjpeef3BvuspR0sBt6_2$6Ggx6S5B0z9zKeG0G3jWnY0Y(Action`1 #=qzby81Gl79jMNsZ2ydluulw==)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.BuildComponentInExternalProcess(ComponentBuildParameters parameters)
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.#=q1dEw74QvFCHZvLaC0gI4_g==(ProcessingTask #=qQGKNQUwpcPIMHmMcq9HbgA==)
Back to top
Remco
#35 Posted : Wednesday, November 30, 2011 9:29:16 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Yes that looks the usual silverlight exception. I can't give an ETA at the moment but a number of people have been asking for this lately, so it is moving up the priority list. The best I can offer would be that it will be some time after Christmas.
Back to top
partnerinflight
#36 Posted : Monday, December 5, 2011 6:38:05 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
You know, the way we address the lack of UT support in Silverlight is we simply create a CrossTarget project that links to the SL files, and run UTs on that project. This works great, except nCrunch has to be able to understand this semantic -- when working in a file X, see if X is linked from a .NET 4.0 project, and if so run unit tests against that....

Would that make your job easier?

(The WP7 projects can be done the same way.)
Back to top
Remco
#37 Posted : Monday, December 5, 2011 10:28:24 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
In theory this is possible. You could make use of the 'UseBuildConfiguration' setting in NCrunch to tell it to use a different build configuration, then rig up your project file to build for non-SL .NET 4.0 under this build configuration. I guess it would create quite a bit of work for you though, as you'd need to specify each referenced assembly twice (once for each build configuration). You may also run into some subtle differences between the SL framework and the non-SL framework, which could trip you up ... Is this what you're suggesting?
Back to top
partnerinflight
#38 Posted : Monday, December 5, 2011 10:50:45 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
Not exactly. So we actually have two separate projects, like

A.Silverlight.csproj (SL project)
a.cs
b.cs
c.cs

A.CrossTarget.csproj (.net project)
->a.cs
->b.cs
->c.cs

where -> represent links to .cs files. (the "Use Existing" option when adding files to a project). Yes, there can be some SL-specific code, we just #if it out to allow cross-compilation.

The trick is though for ncrunch to recognize that when I'm editing a.cs in the context of A.Silverlight.csproj it's actually covered by unit tests targeting A.Crosstarget.csproj. (i.e. a way to specific an explicit link between the two projects)
Back to top
Remco
#39 Posted : Tuesday, December 6, 2011 3:14:03 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Gotcha. I was thinking the same thing, but piggybacking off the same project file.

I think the key question here would be the target framework used for building the tests that cover the cross-target project. Right now NCrunch can't build SL application domains, so the tests themselves would need to be in a project that was also targeting a non-SL .NET framework. This in itself would solve the problem you've described, as the test project could be made to target the A.CrossTarget.csproj file in its Project reference and NCrunch would simply disregard the Sliverlight.csproj file. You could even build your own solution file containing the .NET projects and excluding the SL ones, then use the SL ones only for your main build that could be run in order to test your UI. It's still a bit of work though :)
Back to top
partnerinflight
#40 Posted : Tuesday, December 6, 2011 5:00:49 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/23/2011(UTC)
Posts: 8
Actually you know, this seems to work ok. The issue I was concerned about was that intellisense, and ReSharper, appear to treat a.cs when opened from inside A.SL.csproj as SL code, and color their compilation warnings/errors accordingly. nCrunch though appears to not care where the file is opened from... so looks like we're good. :) Now if there was an easy automatic way to create this project crosstarget mirroring... :) There's a tool for this from the Prism guys, but it still takes quite a bit of manual setup.
Back to top
Users browsing this topic
Guest
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.100 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download