Hannin

1. Visual Studio Build Tools
2. Visual Studio Build Machine License
3. Visual Studio License For Build Machine
4. Visual Studio Build Log Verbosity

This post was originally published at Microsoft Build 2018: New releases for Visual Studio, Visual Studio for Mac,.NET Core and Xamarin.Forms. Microsoft Build has always been a time when we deliver a wealth of developer-focused announcements.

Last year at Build, we launched Visual Studio for Mac, our native macOS IDE for developers building cloud, web, and mobile applications using .NET. Updates have been rolling out at a steady pace ever since, and we’re excited to announce the release of Visual Studio for Mac version 7.5. We have also continued to bring more Visual Studio 2017 code to the Mac.

Our mission has always been to delight developers, and we have something for everyone in this release. You can get started by downloading the new release or updating your existing install to the latest build in the Stable channel.

Here are some of the features we’re most excited to share with you:

• ASP.NET Core developers now have full Razor editor support. We’ve also introduced JavaScript and TypeScript support.
• For iOS developers, we added WiFi debugging support for iOS and tvOS applications. We also improved the iOS provisioning system.
• Android developers will enjoy the new Android SDK manager built right into the IDE, as well as a device manager to keep track of all your devices and emulators
• Xamarin.Forms developers will enjoy an improved XAML editing experience
• Cloud developers have support for Azure Functions development using .NET Core.
• We support .NET Core 2.1 RC and C# 7.2.
• Code-styling rules can be configured per-project using .editorconfig files.
• A preview of Team Foundation Version Control support for Team Foundation Server and Visual Studio Team Services is now available.

We’re also shipping improvements to performance and stability, accessibility, and multi-language support, along with fixes for a number of bugs reported by our vibrant developer community. You can find the full list of changes in our release notes.

ASP.NET Core development with Razor, JavaScript, and TypeScript Editor Support

We partnered with the Roslyn and Visual Studio JavaScript tooling teams to reuse Razor, JavaScript, and TypeScript editor source code, bringing the editing experiences you know and love from Visual Studio 2017 to the Mac.

Official Razor support includes IntelliSense and syntax highlighting in .cshtml files

Our JavaScript editor has been rewritten to provide the core editor experience you expect, including IntelliSense, enhanced colorization, and brace completion. We’ve also added TypeScript editing support, which shares the same IntelliSense and colorization as our JavaScript experience.

Use .editorconfig files to Set Code Style Rules in Projects

One of my favorite features is finally here: .editorconfig

Visual Studio for Mac will now format your code following the conventions specified in the .editorconfig file. This will allow you to set your coding style, preferences, and warnings for your project; making it simpler for code that you contribute to other projects to follow the practices of those projects.

Xamarin.Forms Development

We now ship Xamarin.Forms templates that take advantage of .NET Standard Libraries.

Working with XAML just got better, too, with IntelliSense improvements providing better support for self-closing elements and more completions.

Android Development with Xamarin

On the Android side of the house, we added an integrated Android Device Manager dialog, eliminating the need to rely upon 3^rd-party tools for device and emulator management. You can find this under Tools > Device Manager.

iOS Development with Xamarin

iOS fans will enjoy a streamlined Entitlements editor experience, making it a breeze to add capabilities and services to your iOS apps.

Simply open the Entitlements.plist file and jump right in! Not only that, our new Automatic Signing experience makes deploying your application to devices very simple. In the Signing section of the Info.plist editor, you’ll find using Automatic Signing makes the burdens of manually tracking your entitlements and provisioning devices things of the past.

Building Serverless solutions with Azure Functions

Our new Azure Functions templates now support the Azure Functions .NET Core SDK, empowering you to build, debug, and test Azure Functions locally. In addition, item templates provide guidance for building functions using the most common triggers, enabling you to get up and running with new functions in minutes.

After creating a new Azure Functions project, right-click and select Add > Add Function, then choose your favorite function from the template dialog.Check out our documentation for a walkthrough to create your first Function in Azure.

.NET Core 2.1 RC and C# 7.2

Visual Studio for Mac version 7.5 now supports .NET Core 2.1 RC. Major improvements include faster build performance, better compatibility with .NET Framework, and closing gaps in both ASP.NET Core and EF Core. You can read more about the .NET Core 2.1 RC release in the announcement blog post. Support for the newest C# release, version 7.2, is also available today.

Working with your source with Team Foundation Version Control

One of our most popular feature requests has been to add support for Team Foundation Version Control (TFVC) to access source saved in Team Foundation Server or Visual Studio Team Services. We heard you loud and clear! Today, we’re previewing a new extension to do just that.

To install the extension, navigate to Visual Studio > Extensions… in the Visual Studio for Mac menu and search the gallery for “team foundation”. We support Get, Commit (with associated work items), version history, and more.

Feedback

We hope you’ll find Visual Studio for Mac version 7.5 as delightful as we do. Let us know what you think! Your feedback helps us improve our products and better understand your needs as a developer.

Please let us know about issues via Help > Report a Problem. You’ll be able to track your issues and receive updates in the Visual Studio Developer Community.

You can also provide product suggestions via the Help > Provide a Suggestion menu and vote on suggestions at the Visual Studio for Mac UserVoice site.

Miguel de Icaza

When we started working for Xamarin as consultants, 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 Arthur C. Clark way).

During the past year and a half since the we joined Xamarin, we iterated (among other things) on this key component of the developer experience, culminating in our most recent release, Xamarin 4. 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. 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 incremental build. 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

Visual Studio Build Tools

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 ;)). 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:

1. 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)
2. Agents use the exposed API (IMessagingClient) to send/post/reply messages (remember it’s bidirectional!)
3. 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.
4. The process is the exact opposite if the Mac side agents need to communicate with the VS ones, which are in turn registered to receive certain messages.

In previous versions of Xamarin, an unexpected error on any of the individual components on the Mac could cause the whole build host to stop working, requiring manual intervention by restarting it. In Xamarin 4, we implemented process-level isolation for unrelated components:

One key change from our previous versions is that now Visual Studio drives the Mac side too. Since it connects remotely to the Mac via SSH as a local interactive user account, it can start processes, copy files, fetch logs, etc.

Visual Studio controls deployment, versioning and manages processes on the Mac

Visual Studio Build Machine License

As shown in the previous image, there is another isolation boundary at the Visual Studio process level. This ensures that multiple instances of VS can simultaneously connect to the Mac seamlessly. The broker and individual agents can all be recycled independently too. The ports used by the broker and agents are negotiated automatically to avoid collisions too.

Visual Studio License For Build Machine

And as soon as Visual Studio disconnects from a Mac, all processes are stopped.

Visual Studio Build Log Verbosity

In a future post, I’ll go into more detail on the protocol underlying the Messaging layer. If you’re curious, it’s MQTT :)