Unable to deploy non-trivial app (UploadChanges timeout)

I've been working on porting a multi-platform (Win/WinPhone) app to Android and iOS using Visual Studio 2013 and Xamarin. I have been able to build and deploy my app using the Xamarin.iOS build host on my Mac for the past week or so. All of the sudden I can no longer deploy the app (to a device or the simulator). I can still build/deploy the HelloWorld iOS app just fine.

I've only added half a dozen classes, with maybe a few hundred lines of code total, since it was working. I also added the ModernHttpClient component from the Xamarin component store (which includes AFNetworking, which isn't exactly small). I've tried pulling ModernHttpClient/AFNetworking, but that had no effect.

When building my app on the Visual Studio client I see:

<br /> 1>Done building target "_PrepareApplicationBundle" in project "MaaasClientIOS.csproj".<br /> 1>Target "_BuildNativeApplication" in file "C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.MonoTouch.Common.targets" from project "C:\Users\Bob\dev\Maaas\MaaasClient\MaaasClientIOS\MaaasClientIOS.csproj" (target "_RemoteBuild" depends on it):<br /> 1>Server command 'UploadChanges': failed to upload changes to the server<br /> 1>Command execution task ended with exception<br /> 1>Exception System.Net.WebException: The request was aborted: The operation has timed out.<br /> 1>Exception details can be found in the log file<br /> 1><br /> 1><br /> 1>Remote build step failed.<br /> 1>Done building target "_BuildNativeApplication" in project "MaaasClientIOS.csproj" -- FAILED.<br /> 1>Done building project "MaaasClientIOS.csproj" -- FAILED.<br /> 1>Build FAILED.<br />

And when checking the mtbserver.log file on my Mac I see a bunch of correct looking steps and then:

<br /> [28-Dec-2013 01:26:54] Handling with command: [UploadChanges: CommmandUrl=UploadChanges] (12)<br /> [28-Dec-2013 01:26:54] Attempting to acquire command execution lock, timeout set to 00:10:00<br />

And then nothing after that.

I'm not sure what that lock is waiting for, but even with two relatively decent machines (the Windows machine is a Surface Pro and the Mac is a 2.5Ghz i7 8Gb MacBook Pro) the builds are not exactly smoking (the full deployment of my app when it was working was easily a minute plus). These machines are sitting next to each other and are connected via a very reliable and high speed wifi connection (they're connected to the same AP).

Before I started trying to prune my app back a file at a time to see if I could get it to work, I thought it would be good to see if someone who knew what it was timing out on could take a look at this. I'd heard horror stories about Xamarin kind of falling apart once apps got to a real-world size, but was pretty skeptical of that until now.

I am up to date on the "stable" channel on Windows and running Xamarin.iOS 7.0.6.166 on the build server.

At this point I'm stuck.

Posts

  • I tried clearing out my logs on the server, as they were getting a little large. No effect.

    Next I tried deploying "release" (note that I had not tried this before, so I have no idea if it ever worked - given the number of other, er, 'anomalies' I have experienced, who knows). That didn't work either, but it failed in a slightly different way. This time the 'uploadChanges' step failed but reported 'No response received from the server' after a fairly long delay. The server log showed:

    <br /> [28-Dec-2013 11:42:58] Handling with command: [UploadChanges: CommmandUrl=UploadChanges] (11)<br /> [28-Dec-2013 11:42:58] Attempting to acquire command execution lock, timeout set to 00:10:00<br /> [28-Dec-2013 11:52:58] Error: Failed to acquire command execution lock, the request timed out (00:10:00)<br /> [28-Dec-2013 11:52:58] Command [UploadChanges: CommmandUrl=UploadChanges] finished (11)<br />

    So at least now I know what an actual timeout looks like (and I know that I'm not actually timing out on the server in the debug deployment failure case that is my primary issue).

    Not that I'm any closer to a solution...

  • Well, I got it working, and now I'm even more annoyed. I was able to get to a single line of code that would cause the deploy to fail if included and to succeed if commented out. That line was:

    <br /> using MonoTouch.CoreGraphics<br />

    The code that actually used CoreGraphics was commented out through this entire episode (it was some dead code that I commented out early on, and forgot to remove the unneeded 'using').

    OK, so I wasn't exactly happy to find that the presence of an unused 'using' determined success/failure of deploy/debug, but at least I was back in business.

    I re-added the code that used AFNetworking (UIImageView.setImageURL) and it immediately exited when run on the device (exit code 1, no crash log, no other diagnostics on the device console or any logs). Fun. Not sure how I'm going to debug that one.

    Then I tried running on the simulator, and that worked great. I soldiered on and worked on some internal classes (no code that was even being executed on startup, nothing that changed the footprint in terms of components/references). Then just for fun, I tried deploying to the device again, and this time it ran. WTF? I put the MonoTouch.CoreGraphics back in just to see, and it deployed/ran fine. Neato.

    So I hit two separate failure modes, each of which gave me no indication of the actual underlying problem, and each of which just magically went away at some point based on adding more application code.

  • And now after adding little more code (some pretty innocuous stuff involving parsing color names and setting a font color), I'm back into a state where I can't deploy release or debug to the simulator or the device (of course HelloWorld deploys just fine). About half the time it fails with the "fake" timeout (the System.Net.WebException above) and the other half it takes 10+ minutes and fails with an actual client timeout. In neither case is there anything useful in the build server log. So I'm stuck again and starting to think "hey, maybe Objective-C and XCode aren't that bad"...

Sign In or Register to comment.