Visual Studio, both the full IDE and the Code programmer’s editor, are key pieces of the Windows development story, and Build is an important part of the packages’ story. While Connect(); is perhaps the main developer tools event, Build still sees Visual Studio getting its share of the news.
Visual Studio 2017 15.7
With the release of Visual Studio 2017 15.7 at Build 2018, Microsoft has added new tooling for working with cloud-first Kubernetes-based distributed applications running on Azure. New debugging tools help manage your code, and you can use the Helm package management tool to simplify deployment using Helm Charts with Azure’s AKS cloud service. The new Kubernetes tooling is now available, with project templates for Container Applications using .NET Core (and the option to wrap any .NET Core web application in a container). Once built, apps can be deployed directly to a Kubernetes cluster, integrating with Azure’s new Dev Spaces. Visual Studio will automatically generate a Helm chart, as well as the appropriate Dockerfiles.
Visual Studio IntelliCode
Another new feature announced at Build is Visual Studio’s IntelliCode tooling. Extending the original IntelliSense concept to machine learning-powered developer tooling, IntelliCode uses it to respond to what you’re actually doing in Visual Studio. Trained on over 2000 GitHub repos, it can recommend the API you’re calling as well as suggesting the appropriate calling options. The more you use it, the more it learns about your specific ways of working.
You can get started right now with an experimental IntelliCode extension for C#: https://go.microsoft.com/fwlink/?linkid=872707
Future releases will add automated styles and formatting, tooling for code reviews, handling misplaced variables, and suggestions of which files in a project may need reviewing.
Introducing .NET Core 3
Now nearly 20 years old, .NET remains at the heart of Windows development. The full .NET SDK continues to add features for large scale enterprise applications, while the open source .NET Core is rapidly gaining both complexity and support, with tooling for cross platform application development and as part of the UWP Windows 10 development platform. Alongside the .NET platform, the .NET Standard APIs allow you to build apps that work across different releases and versions of the .NET runtime.
At Build 2018 Microsoft went into some detail about the future of .NET. First it released the release candidate for .NET Core 2.1. A significant performance improvement over .NET Core 2.0, the 2.1 RC has a “Go Live” licence, ready for use with production code. There’s also support for ARM v7 and v8 chipsets, so your code can run on higher end Raspberry Pi devices, as well as providing support for new Always Connected PCs running Windows on ARM and the processor used in Microsoft’s Azure Sphere secure microcontroller.
The announcement of the next major release, .NET Core 3.0, brought major changes to the platform. Where previous versions of .NET Core focused on mobile, console, and server applications, .NET Core 3.0 will also support desktop Windows applications, via “Windows Desktop Packs”, supporting not just UWP, but also WinForms and WPF applications. This gives you a migration path for your code, away from using a single runtime for all your .NET code to self-contained applications that can run with separate installations of .NET Core – and will even compile down to a single EXE to simplify installation and distribution.
Having .NET Core 3.0 supporting desktop code also gives you the opportunity and the tools (with .NET Standard) to update code to take advantage of newer language and API features. Legacy code can replace the .NET Runtime with .NET Core for a quick performance win, and you can then add new features as necessary. While desktop code running on .NET Core will only run on Windows, it can help you consider how you might use it as part of a cross platform delivery, using the same .NET Core code in the same Visual Studio solution to target different application releases using different UI tooling, like Xamarin Forms or Blazor.
One key element in this application modernisation strategy are XAML Islands, new controls that let you use UWP controls in WPF and WinForms code that’s intended to run on Windows 10. The initial XAML Islands support will bring the Edge HTML control, replacing the current IE-based one, letting you update your apps for modern web standards. Additional controls will follow, using the UWP community control library. One thing to note is that there’s currently no fall back to older controls once you’ve replaced them with XAML Islands, so your code will only run on platforms with XAML support.
The evolution of .NET Core is key to Microsoft’s strategy to migrate development away from WinForms and WPF. New controls and APIs will come from UWP, with support for new user experience features, like handwriting and speech, while older UI elements can still be used before being eventually upgraded to newer versions that support Microsoft’s Fluent design language.
MSIX: Updating the Windows Installer
Getting your applications installed is as important as writing code. But that adds a new problem: what installer do you use? Do you just xcopy the files, or wrap them in a msi, or use appx and the Windows Store? It’s an issue for IT pros as much as for developers, as the right installer makes getting code on corporate desktops easy.
In the past you’d take an app, apply appropriate customisations and package it as an msi file, before deploying via System Center. That meant a complete rebuild of the installer with each new release, and no way to use apps in public or private Microsoft Stores. MSIX separates app and customisations, so you can add them to an existing MSIX package, before delivering it to InTune for delivery as a signed package. MSIX also makes it easier to secure code, with a manifest and tools for tamper protection. It can also handle different languages and different versions, packaging 32-bit, 64-bit and ARM code in a single installer, along with appropriate regional resources.
MSIX also supports UWP and desktop bridge apps, installing them into secure containers. Available as a new project type in Visual Studio, the MSIX packaging tool handles creating installers, working with existing projects and solutions as well as with new code.
Azure Surface Fabric: the service mesh
One of the key underlying technologies in Azure is Service Fabric, the Platform as a Service engine that powers most of Microsoft’s public cloud. With support for message and event-driven code, and the ability to host containers and manage virtual machines, it’s a powerful tool for building large-scale distributed systems.
At Build 2018, Microsoft announced an extension to Service Fabric, the Service Fabric Mesh, with enhanced container support. Treating containers as serverless hosts for microservices, Service Fabric Mesh supports rapid scaling with per-second billing. By letting Azure handle orchestration for you, you can reduce management overheads, using Service Fabric Mesh where you’d have used Service Fabric’s tooling. It also announced that it would be improving development tooling for in-cloud and on-premises clusters, with enhanced support for both Ubuntu and Red Hat as hosts – and for hosting Service Fabric in IoT Edge containers on remote devices.
Our Developer team are specialists in Visual Studio and Azure licensing and can help you with a licensing consultation or technical advice for your use case: +44 (0)1364 655 181.