![]() When we started working for Xamarin, a couple years ago, it was nothing short of amazing for us that Xamarin had already achieved a pretty solid “F5 experience” with an app building on the Mac and debugging like any regular local.NET app. I had the same feeling the first time I did the same thing against an Azure website. Felt like magic (in the way). During the past year and a half since, we iterated (among other things) on this key component of the developer experience, culminating in our most recent release,. What started as a (more or less) batch process of “zip sources, HTTP post to Mac, build, run” (with frequent rebuilds needed), is now a fine-tuned granular incremental build system driven by MSBuild, connecting to the Mac over a resilient, auto-deployed and always-on messaging layer running on top of a bi-directional binary protocol over TCP, secured by an SSH tunnel. At the user experience level, it might seem that little has changed other than a fancy new connection dialog. But as Tim Cook said “the only thing that changed is everything”, so I’ll go over the details of how it works today with the new Xamarin 4 experience. MSBuild and Incremental Builds For anything but trivial apps, achieving incremental builds is key for productivity: you don’t want to be copying unnecessary files over the network to the Mac, neither you want to be optimizing PNGs, compiling storyboards and what-not if none of the source files have changed. MSBuild (and XBuild on the Mac) already support incremental builds, so the first challenge was to move away from batch-style of invoking XBuild remotely, to a fully “MSBuild-native” solution. January 9 edited January 9 in Visual Studio I'm at the end of my tether working with VS for Mac due to it's very slow build times. It's a shame because otherwise I find it to be an excellent product. For people who must keep existing Windows 10 OS installed, the slow android emulators (under Android Emulator Manager) can be used or just use a mac machine for android development. Edited by blertonh Friday, June 3, 2016 5:17 PM. Also, we wanted to share 100% of the build logic from Xamarin.iOS targets on the Mac. So the way it works today is: You can see that exactly the same targets and tasks are shared between the Mac and Windows. This allows us to minimize inconsistencies between VS and XS builds. The only difference is that the Windows version of the tasks do a remote invocation to the Mac whenever the tasks that need to run on the Mac are executed. We evaluate tasks individually to determine if they must run remotely or if they can be run locally. The unit of remote invocation to the Mac is the MSBuild Task.Execute One example of a task that always runs remotely is compiling iOS storyboards, since the tools to do so are provided by Xcode. An example that doesn’t is the C# compiler itself, since the source code can be compiled to IL by Microsoft’s compiler on Windows without requiring a roundtrip to the Mac. Some parts of the build are done on Windows, some parts on the Mac The next step was to improve the targets to provide relevant Inputs/Outputs to enable. An interesting challenge there was that for MSBuild to determine that a given target doesn’t need run again (or that certain outputs are out of date with regards to their inputs), the Outputs files need to exist on the Windows side. But since all we need those output files for is for incremental build support, they are actually written as empty files on Windows:). MSBuild doesn’t care, as long as the timestamp on those files can be compared with the Inputs to detect the out-of-date items. This mechanism existed prior to Xamarin 4, and we just replaced the underlying remote call protocol, which was almost trivial to do since the core changes to unify XS/VS builds had already been done. Our goal was to have at least comparable performance to our previous releases. Now that the underlying communication infrastructure has shipped, we’ll focus on fine tuning the targets and tasks to leverage incremental build support even more. Our goal is to achieve substantial performance gains moving forward, and we could certainly use your feedback, especially if you find some cases where builds are considerably slower than local builds on the Mac with Xamarin Studio. Remote Communication The underlying communication facilities that Xamarin provides within Visual Studio are consumed by fairly independent components (we call them Agents): • Activation: ensures that the Mac is properly activated • Build: performs the remote build task invocation • Designer: provides the rendering for the iOS designer • IDB: provides similar functionality to ADB (Android Debug Bridge), hence the name, an acronym of iOS Debug Bridge (we don’t like the name so much nowadays;)). Download oracle 11g 32 bit. Basically exposes list of simulators and devices available on the Mac • Stats: we support collecting some stats (execution time, payload sizes, etc.) for diagnostics. From top to bottom, the flow is: • When Xamarin starts within Visual Studio, it automatically establishes an SSH connection with the Mac, deploys the Broker (if necessary), starts it and then starts all the Agents (which you see in real-time in the status bar or the spinner icon tooltip on the connection dialog) • Agents use the exposed API (IMessagingClient) to send/post/reply messages (remember it’s bidirectional!) • The Messaging layer communicates over TCP/IP within the SSH tunel with the Broker, which forwards the message to the Mac-side agent that registered to receive the message.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |