One of our goals at Microsoft is to give developers the tools they need to build native, cross-platform apps for Android, iOS and Windows. Our recent acquisition of Xamarin gives you 100% native API access so you can create truly native user experiences. If you attended Build 2016 in April, you most likely had the chance to see some of the capabilities in the latest release of Xamarin.

Whether it’s your first time delving into cross-platform mobile development, or you’re looking for ways to be more effective, watch this webinar with Xamarin’s James Montemagno. James has nearly a decade of experience as a programmer and developer in gaming and enterprise software and he’ll give an overview of cross-platform mobile app development with Xamarin and Visual Studio.

At the end of the webinar, you’ll know how to use your existing C# and Visual Studio skills to develop fully native mobile apps for Android, iOS and Windows, and how to manage the development lifecycle with Xamarin and Visual Studio.

For more details, check out the webinar registration page, or visit the Visual Studio Dev Essentials home page to learn more about cross-platform development with Visual Studio and Xamarin.

Bharat Bhat, Marketing Manager, Microsoft Developer Tools & Services @bharatsbhat Bharat believes that the tools Microsoft offers today are the best out there and can help developers create amazing apps on any OS – cloud services and tooling included.  In his past life, Bharat was a Java developer for 10 years in NYC, working mostly on financial transaction platforms and open source web projects.

Today I am happy to share Visual Studio “15” Preview 3 (which is different from Visual Studio 2015 Update 3). This is still a Preview and is unsupported, so my recommendation is to not install it on your production environments. That said, it should install right on top of any previous Visual Studio “15” Previews and side by side with previous versions of Visual Studio. Here are the Visual Studio “15” Preview Release Notes, and Visual Studio “15” Preview 3 Known Issues.

We’re still laying some of the foundational groundwork, but we do have some new features, including some improvements in IntelliSense to help you filter the member list by type and a new Exception helper that gives you instant non-modal view in to inner exceptions. The IntelliSense tray is disabled by default but can be easily turned on in Tools > Options. > Text Editor > C#/VB > IntelliSense. Check out Kasey Uhlenhuth’s post detailing the C# and VB improvements. Preview 3 also includes Xamarin 4.1, which includes bug fixes as well as support for tvOS and improved iOS Assets Catalog support. For more information, see the Xamarin release notes.

Additionally, we released Team Foundation Server “15” Preview today. You can find details on this release in the TFS “15” release notes and TFS “15” known issues.

We are also working on upgrading our feedback systems. Try the report a problem feature in the IDE to see what we’ve done, then look at the web portal view.

As always, we welcome your feedback. For problems, let us know via the Report a Problem option in Visual Studio. For suggestions, let us know through UserVoice.

John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time.

Today we are happy to announce a major update to Developer Assistant! Developer Assistant now offers contextually aware web powered solutions for C++.

Developer Assistant for Visual Studio is a productivity plugin that brings the combined power of Bing search capabilities and your development environment to solve your day-to-day developer problems. With the addition of C++, we are opening up new possibilities for millions of C++ developers on Visual Studio.

We are now expanding all the 3 important components of Developer Assistant to C++

• Code Samples access in your IDE environment
• Project search from popular sources
• Bing powered contextual search

With the addition of 43 Million C++ code samples, our total corpus is now of 64 Million code samples. In addition to MSDN, stackoverflow and GitHub we have sourced code samples from specialist C++ domains like cppreference.com and cplusplus.com which gives developers a strong base of options to choose from. Now you have access to thousands of code samples for CRT (C runtime libraries), STL (standard template library) and various other open source C++ libraries like Boost, Direct3D, OpenCV etc. from within Visual Studio. You can access all these code samples in two ways:

1. Automatic code samples in your IntelliSense experience
2. Code samples for your tasks using natural language in the “How do I – box” (Ctrl+shift+F1) or in the Bing search box

Figure 1 Intellisense Experience in your code editor

Figure 2 “How do I” search box gives code samples for your programming tasks

Now you can satisfy your programming needs by using the search box in the Visual Studio toolbar. You will get both C++ code snippets and sample projects from MSDN or GitHub within the IDE browser. All the open source projects are just a simple search away. Code sample projects are complete Visual Studio demo solutions that you can download or clone, build and run

Figure 3 Search code sample projects from within the Visual Studio

With Bing Contextual Search support for C++ you can get web help on any keyword or compiler error. Our algorithm consumes all the additional contextual parameters like your project type, programming language etc and issues multiple queries to the search engine and show re ranked results in your web browser.

For instance, imagine you’re in Visual Studio and want to know more about a particular keyword. You can simply select and do a right click as shown below

Figure 4 Select and do right click and choose Bing Contextual Search

Selecting “Bing Contextual Search” from the dropdown link will open a web results page containing everything you need about this particular keyword or compiler error from the internet.

NOTE: Currently in VS2015 the feature works only in the IDE Editor and not for compiler errors.

Figure 5 Contextual results shown in a browser for the selected keyword

Get your latest version of Developer Assistant from here. In our endeavor to improve developer productivity we have come a long way through your feedback and suggestions. Please keep writing to us at bingdevassistant@microsoft.com and help us to serve you better.

On behalf of teams from Bing, Developer Experience, Microsoft Research & Visual Studio, Thank you.

Anuj Jain, Program Manager, Bing Tech Experiences @1AJain Anuj has been with Microsoft for 3 years. He is passionate about improving developer productivity by combining the power of web by using Bing & Development Environment to provide contextually aware help to developers.

Today we’re releasing Visual Studio Tools for Unity 2.3. The Visual Studio extension natively supported by Unity on Windows makes it easier for game developers to use the rich capabilities of the Visual Studio IDE to develop cross-platform games with Unity.

Main changes

The highlights of VSTU 2.3 include:

• VSTU no longer conflicts with the Xamarin tools, preventing you from debug your Unity game.
• You can now use the text, XML, HTML and JSON string visualizers when debugging.
• Support for function breakpoints in Visual Studio 2015 is now included.
• All of Unity’s MonoBehaviours are now available from our wizards.
• Multiple issues in the expression evaluation of the debugger have been resolved.

How to Update

The easiest way to update VSTU is to use the Visual Studio IDE extension manager. If you want to update manually, you need to download and install the VSTU version that matches the Visual Studio version you have installed and want to use with Unity.

If you are running Unity 5.2 or above: VSTU is natively supported and you just need to reinstall VSTU.

If you are running Unity 5.1 or below: You’ll still need to reimport our package in your project.

We strongly encourage VSTU users to update to 2.3. VSTU works best with Unity 5.3 where it’s natively supported, but we continue to support game developers on previous versions of Unity through the use of our VSTU Unity package. The full change log for this release is in our documentation.

You can download VSTU directly from the Visual Studio IDE extension manager or from the Visual Studio Gallery:

• Visual Studio 2015 Tools for Unity
• Visual Studio 2013 Tools for Unity
• Visual Studio 2012 Tools for Unity
• Visual Studio 2010 Tools for Unity

As always, if you have any suggestion for VSTU, please post them on UserVoice, and if you encounter any issue please report it through the Report a problem option from within the Visual Studio IDE.

Jb Evain, Software Engineering Manager, Visual Studio Platform Team @jbevain Jb runs the Visual Studio Tools for Unity experience He has a passion for developer tools and programming languages, and has been working in developer technologies for over a decade.

What time is it?! Time to announce that our next stable release of Node.js Tools 1.2 for Visual Studio (NTVS) is available for download! NTVS 1.2 supports Visual Studio 2015 (including the free Visual Studio Community Edition and Express for Web).

With Node.js Tools for Visual Studio, we strive to make it easier than ever to build enterprise-grade Node.js applications by supporting you at every stage of your application—from powerful code completions, to advanced debugging and profiling, to unit testing, cloud deployment, and much, much more.

What’s new in v1.2?

Apart from support for Node.js v6.x and numerous bug fixes all across the product, we’ve focused on increasing developer productivity with the following improvements.

Faster, better ES6 IntelliSense

Whether you were running into performance issues or craving the latest and greatest JavaScript goodness, the new ES6 IntelliSense experience is now on by default, and better than ever! The new ES6 IntelliSense engine takes advantage of type definition files to provide better and more performant IntelliSense. This is applicable for the most popular Node.js frameworks, such as Commander, Express, jQuery and Knockout.

And, of course, everything just works. Whenever you include a new npm package, the associated “typings” will be automatically downloaded to your project, which will enable you to see relevant completions next time you ‘require’ a module.

That said, while we hope you’ll love the new IntelliSense features, we realize it’s a significant departure from our earlier static analysis engine. So we continue to provide that as a fallback option as we continue to iterate on this experience.

More reliable debugging

Advanced debugging is the cornerstone of NTVS, we’ve made it even better by addressing several user-reported issues. So if breakpoints weren’t working properly sometimes, or things were generally inconsistent, be sure to download this release to get the latest fixes!

Improved Performance

Hangs and crashes are a drag, but not anymore! This release provides significantly improved stability and performance, including reducing out-of-memory crashes seen in prior versions. We’ve also made several improvements to our project system, so you can expect improved project load times (especially during “Add from Existing Code”).

Still running into problems? Please, file an issue on GitHub so we can work together to resolve it!

Improved Unit Testing Experiences

While it’s generally best practice to avoid writing bugs altogether, some of us are not omniscient, and find unit tests to be pretty helpful. So we’ve made some improvements to the unit testing experience, including adding tape support thanks to @jcansdale (#989).

Want support for your favorite test framework? Let us know – we may be able to include it in the next update of NTVS. Or better yet, just submit a PR on GitHub!

Get started with Node.js Tools 1.2 for Visual Studio

Download Node.js Tools 1.2 for Visual Studio to get started developing Node.js applications in Visual Studio. And as always, for comments, compliments, or complaints, file an issue, join us on Gitter, or shoot us a tweet. We’d love to hear your feedback, especially if it comes in the form of a pull request.

Lastly, a special thanks to our community – NTVS is a free and open source project, and this release simply would not have been possible without your support, so thank you, thank you, thank you to everyone who’s already active on our GitHub repo, and looking forward to meeting all of you who just clicked this link! J

Onwards!

Sara Itani, Software Engineer, Node.js Tools @mousetraps Sara is an engineer focused on building best-of-breed Node.js developer tools. At first, she was skeptical about Node.js – that is, until she realized its full potential…. Now, she’s all in, and excited to help it take over the world by bringing the power of Visual Studio to the Node.js community. She, for one, welcomes our new JavaScript overlords.

Visual Studio is a powerful IDE with hundreds of productivity features to empower developers to do more, faster. I joined the Visual Studio team about a year ago, and here are some of the great things I’ve discovered. These are all in Visual Studio 2015, and some have been there for a few versions now so you’ll find them in previous versions of Visual Studio as well.

Quick-launch (Ctrl-Q)

Quick-Launch is an enhanced search box that sits in the title bar in the top-right corner. Not only will it let you find menu commands and options switches, it will also let you search files, settings, NuGet packages and a whole lot more! You can access it directly with the default keyboard shortcut Ctrl+Q.

Hovering over the items in the list provides useful additional information – such as shortcut keys or directory information.

Multi-language support

Visual Studio supports many popular languages out of the box, but if yours is not on the list you can easily add it. With our new support for TextMate bundles, Visual Studio will bring any language to life. TextMate capabilities include new language syntax highlighting, basic IntelliSense and symbolic search.

To take advantage of TextMate capabilities, simply add a tmbundle to the user’s extensions directory ([userdir]\.vs\extensions). There is no need to restart Visual Studio; the new language features will be available as soon as a relevant file is opened.

You can learn more about importing TextMate bundles here.

Some TextMate bundles have already been written. Here are some links to some popular ones:

• Scala bundle by Mads Kristensen
• Haskell bundle by Tim Sneath
• Php, Ruby, and lots more on the TextMate GitHub page

C# Interactive window (REPL)

This tool window lets you directly enter and run C# code. It is useful for quickly evaluating expressions or experimenting with code without the need to build and run a solution.

You can find the C# Interactive Window from the View menu, under “Other Windows”.

Navigate/GoTo (Ctrl+,)

Navigate To is a smart search feature that allows you to easily navigate to any file, class, member, or symbol in the solution. To activate the feature, type Ctrl + Comma, which will display an input box docked in the top right corner of the editor window.

Peek to definition (Alt-F12)

This feature is a favorite among the Visual Studio editor team. It allows you to look at the definition of a method or variable in a small inline window inside the current editor. You can recursively navigate more definitions inside this window, which avoids leaving a trail of open files. You can navigate through the trail with tiny breadcrumbs that appear unobtrusively at the top of the peek window. Alt-F12 will activate this window. (Or if you have installed Productivity Power Tools, Control-Click GoToDefinition will default to using this peek window.)

Preview tab

Originally introduced as an aid to debugging, the Preview Tab, which appears on the right side of the document well, allows you to step into code without leaving a trail of files open at the end of the debugging session. It’s also convenient when navigating or searching through files as, by default, all new documents will open in the Preview Tab. Because the tab will only display one document, it keeps your code searching clutter free. If you want to keep any specific file open, pin it with the keep icon on the document tab and the file will join the other open documents on the left of the document well.

Move code up or down – (Alt-Up/Down arrow)

The Move Code Up or Down feature enables code links or blocks to be easily reordered. To move code within a document, simply hold the Alt key and use the up and down arrows on the keyboard. The feature will move all lines that are selected, or if nothing is selected, it will move the line where the cursor is.

Transparent pop-up boxes (Hold the Ctrl key)

There’s lots of smart little pop-up boxes that offer context-specific actions or information, like IntelliSense and debugging DataTips. Sometimes the information in the pop-up box obscures important code on the lines below. If you want to view this code without losing the pop-up box, simply hold down the Ctrl key and the box will fade into the background allowing you to see the text underneath.

So this…

becomes this…

Version control info in status bar

Starting with Update 2 of Visual Studio 2015, you can now access version control information in the lower right-hand corner of the IDE. In the status bar you now see information such as the current branch, the number of files changed, and the number of pending commits. Clicking on the branch name opens a menu from which you can change branches or perform other version control functions.

Diagnostic Tools Window

The Diagnostic Tools window displays running memory and CPU usage while a program is in debug mode. This tool window opens automatically when you start debugging a .NET or C++ application. It lets you see how much CPU your code is using, the rate of growth of memory, and the kinds of objects that are being loaded.

For even deeper memory analysis, you can take memory snapshots at different points during execution and easily compare the difference in size between the two points, broken down into different types of objects. This can help you track down the kinds of objects that are growing, which helps to identify and solve memory leaks in your application.

For additional debugging tips, see the debugging tips and tricks post.

What are your favorite features and hidden gems of Visual Studio?
I’d love to hear from you. Please comment below to share your thoughts.

Justin Clareburt, Senior Program Manager, Visual Studio Justin Clareburt is a Program Manager on the Visual Studio team, currently working in the Visual Studio extensibility space. He has over 20 years of Software Engineering experience having previously worked for several large organizations including Amazon, NewsCorp, Symantec, and the Australian Government. He brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Today we are releasing an update to the Universal Windows App development tools in Visual Studio 2015 Update 3 to enable you to build apps that target the Windows 10 Anniversary SDK (build 14393). In addition, the Windows Store is now open for submissions of apps that target the Windows 10 Anniversary Update SDK.

The Windows 10 Anniversary Update bring 2700+ enhancements to Windows 10—including Cortana, Inking, Edge. This brings an opportunity to build apps for the more than 350 million users running Windows 10 on their desktops, phones, Xbox, HoloLens, and other devices. For more information about the enhancements to the Windows SDK, see Kevin Gallo’s blog post.

In this release of the Universal Windows App development tools (version 1.4.1), we have added enhancements to the Store submission workflow such as enabling Azure Active Directory integration for dev center accounts, support for large package deployment (useful for large games), and much more. I’ll cover some key highlights in this post.

If you have never installed Visual Studio 2015 before then go to Windows Dev Center to install. If you already have Visual Studio 2015 installed, a notification will appear to prompt you to install, you can modify your Visual Studio installation to upgrade to version 1.4.1 of the tools, or you can go to the Windows Dev Center to upgrade the tools.

Windows 10 Anniversary Update SDK Integration

Visual Studio supports the Windows 10 Anniversary Update release. By default, all projects created using Visual Studio 2015 will now target the new SDK, and users will be able to migrate their existing projects to take advantage of new APIs and features.

Improved integration with Windows Store

Once the project has been associated with the Windows Store, you will no longer need to sign in to create a package to submit to the Store. When you first create a package to submit to the Windows Store, you can now sign in with Azure Active Directory credentials for an AAD Store account. In addition, Windows Store credentials are shared with Visual Studio. This means that as long as you are signed in to Visual Studio, the tokens will still be valid in the packaging wizard. Finally, if you associate your application with a product in the Store one time, you will never need to sign in again. The association persists throughout the life of the project

Large game deployments to Xbox

This release enables new advanced remote deployment options so game developers can more quickly iterate on changes for large games. With Visual Studio 2015 Update 3, and the Windows 10 Anniversary Update SDK, you can now copy files to the remote device using a new faster underlying file transfer protocol. In addition, you can register a package layout directly from a network share to negate the requirements of file transfer altogether.

For more information about leveraging these remote deployment options, check out the latest documentation on the Windows Developer center.

Attach the debugger to application

You can now debug apps that were already running on devices such as IoT, XBOX, and HoloLens from within Visual Studio.

XAML UI Debugging improvements

Whenever the focus changes in your app, the new Track Focus feature in the Live Visual Tree will cause selection in the Live Visual Tree to update to the currently focused element. This makes it easier to map between the running app and the live visual tree. These features are available for both UWP and WPF.

Design support for Indirect Resources

You can now view and use indirect resources in your XAML code. Static Resources referencing other resources in your XAML apps will be fully rendered in the designer, have Intelligence support, and preview in the Resources Pane in Blend. You can also view the original source of an indirect resource with the Resources Pane.

.NET Native for Universal Windows Apps

.NET Native 1.4 is a minor servicing release that improves performance, addresses several customer reported bugs and improves Release build compilation times of large apps. XAML applications and Unity games that use .NET Native 1.4 will have better runtime performance. These improvements were achieved by making both reflection and native API calls faster.

Tell us what you think

With today’s launch, we continue our goal to make Windows and Visual Studio more open than ever and provide you the tools to make Windows your home. Try out the tools, and get started building and submitting apps today.

As always, we welcome your feedback. For problems, let us know via the Report a Problem option in Visual Studio. For suggestions on how we can make Visual Studio even better for building Universal Windows apps, let us know through UserVoice.

Pete Faraday, Program Manager, Visual Studio Pete works on the Windows Tools team within Visual Studio. Originally from the UK, he has been in Seattle for the last 20 years. In his spare time, he enjoys coffee, home repairs, and life near the waterfront.

Are you a web developer building mobile applications today? Are you considering joining the ranks of web developers moving beyond the mobile web to mobile app development? If so, then we have a treat for you – a new set of Visual Studio templates, building on top of the Apache Cordova platform, Ionic UI framework, and using the TypeScript language.

If you’re not familiar with it already, Ionic is a hugely popular starting point for Cordova developers; helping you build apps for Android, iOS, and Windows 10 devices with a great user experience. Native SDKs provide a set of ready-made UI controls that are optimized for mobile devices. HTML, on the other hand, only provides a set of primitives – essentially rectangles – to draw your UI. Ionic delivers HTML-based controls for the mobile developer. Do you need a tab control? Ionic’s got it. Do you need a listview? Ionic’s got it… and more.

Our Tools for Apache Cordova (TACO) team, has been working closely with the Ionic team over the past year to make sure Visual Studio developers have a first-class experience when using the Ionic framework and the TypeScript language, which is the language of choice for developing with the upcoming Ionic 2 framework. This week, we’re releasing two new sets of Ionic templates using the TypeScript language:

• A brand new set of Ionic 2 (Beta 10) Templates
• An update to the existing Ionic 1 Templates, adding TypeScript support

Download them now by clicking the links above, or read on to learn a bit more about them

Try the future today, with Ionic 2

The Ionic team is working tirelessly toward an RC release of the next version of Ionic, based on Angular 2. Our team is likewise working on having great Ionic 2 support in Visual Studio and today we’re sharing with you an early version of Ionic 2 templates, based on the current Ionic 2 Beta 10 release.

This set of templates includes the same three templates as the Ionic 1 release described above:

• Blank
• SideMenu
• Tabs

Our team is releasing these templates as an experiment in Visual Studio 2015 while working to make an excellent Ionic 2 developer experience in Visual Studio “15” – the next version of Visual Studio.

There are a few rough edges in the developer experience, which are noted in the Project Readme page you’ll see when first creating a project with the templates. Most notably, you’ll need to do the following when using these Ionic 2 templates:

• Install Update 3 or later of Visual Studio 2015
• Install the latest release of the ASP.NET Web tooling
• After creating your project for the first time, wait for the “(Restoring)” message to disappear from the dependencies item in the Solution Explorer
• Before building, open the Task Runner Explorer from the View | Other Windows | Task Runner Explorer menu. This will enable Visual Studio to run the custom Gulp build script used by this template

To learn more about the framework and how to use these beta templates, see our newly released Getting Started with Ionic 2 tutorial!

TypeScript and Ionic 1; better tooling through types

For a while now, Ionic 1 templates for JavaScript devs have been available to TACO developers. With this update we made some minor updates to the JavaScript templates and added a set of new templates using the TypeScript programming language.

The same three Ionic templates are now available for JavaScript and TypeScript developers:

• Blank
• Side Menu
• Tabs

Once installed, you’ll find these from the File | New Project… menu, under the JavaScript | Apache Cordova Apps and TypeScript | Apache Cordova Apps categories.

With TypeScript support now included, you get the same tooling benefits as other TypeScript developers. Some of the highlights include:

• High accuracy IntelliSense for your code
• Refactoring tools
• Find References throughout your source
• Move through your code with symbol-based navigation

To learn more about working with Visual Studio & Ionic 1, check out our Getting Started with Ionic 1 guide.

Help us make the Ionic experience great!

Please try the Ionic 2 and Ionic 1 TypeScript templates and let us know what you think! To learn more about working with these templates read the Getting Started with Ionic 2 and Getting Started with Ionic 1 tutorials.

You can post comments directly on the download pages for these extensions, or send us direct emails, talk with us on Stack Overflow, send us a tweet on Twitter, or provide feedback for our documentation directly on our documentation site.

Jordan Matthiesen (@JMatthiesen) Program Manager, JavaScript mobile developer tools Jordan works at Microsoft on JavaScript tooling for web and mobile application developers. He’s been a developer for over 18 years, and currently focuses on talking to as many awesome mobile developers as possible. When not working on dev tools, you’ll find him enjoying quality time with his wife, 4 kids, dog, cat, and a cup of coffee.

You’ve told us that Visual Studio makes you sign in WAY too often. Over the last year, we’ve released several improvements to help address your feedback. The keychain we released with Visual Studio 2015 made it possible to manage multiple identities in VS and gave you single sign-on across the IDE. In the last few updates, we’ve made changes to core services like licensing and roaming, which allow you to refresh your license or roam your settings for up to a year or more without a prompt for credentials. We also updated the Windows store publishing features to use the keychain for single sign-on with the rest of the IDE. Still, if you developed against Azure using a Microsoft account (e.g. @outlook.com, @hotmail.com, or @live.com) as many of us with MSDN subscription credits do, Visual Studio prompted you to sign in every 12 hours to access Azure resources from the IDE.

We’re excited to share that we completed the deployment of some improvements that allow users to safely stay signed in and eliminate the forced sign-in every 12 hours. This addresses the most commonly reported sign-in issue. The next time you’re prompted to sign-in, Visual Studio will follow the new authentication flow that lets you stay signed into the IDE without reentering your credentials every 12 hours. This server-side fix is compatible with all Visual Studio versions that support Azure development back to VS 2012 though the improvements and bug fixes described above will give you the best results on the latest version.

Thank you to all the community members who have shared feedback to improve the identity experience in Visual Studio and, as always, we welcome all your comments. Please report any problems via the Report a Problem control in Visual Studio. If you have a suggestion, please create a post on UserVoice. Keep an eye out for more improvements to come in Visual Studio “15” and beyond.

John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time.

Today we released Visual Studio “15” Preview 4, introducing many new improvements and bug fixes that bring us one stage closer to the product’s completion.

The highlight of this release is that nearly all of VS is running on the new setup engine, resulting in a smaller, faster and less impactful installation. The smallest install is less than 500 MB on disk (compared to 6GB in the previous release of Visual Studio). There are a couple of “workloads” that aren’t present yet, including .NET Core tooling and Azure tooling, but the rest of the existing VS 2015 feature set is available.

For more background to the new installer, there are two earlier blog posts on the principles that guided our new installation engine and the process of redesigning around workloads. Expect to see further improvements before we release, including support for automated deployments, offline installation and further refactoring and componentization.

Apart from the new installer, Preview 4 also includes many other improvements. We have revamped the Start Page experience by adding new Open and Create features to the most frequently used Recent list and the News feed. And C++ has a whole lot of improvements across the board. We are also working on upgrading our feedback systems. Try the report a problem feature in the IDE to see what we’ve done, then look at the developer community portal view.

For the complete list of everything in this release, along with some known issues, take a look at the Visual Studio “15” Preview 4 Release Notes page.

A couple of important caveats about Preview 4. First, this is an unsupported preview so don’t install it on machines that you rely on for critical production work. Second, Preview 4 should work side by side with previous versions of Visual Studio, but you should remove any previous Visual Studio “15” Preview installations before beginning the setup process. Check out this Preview 4 FAQ for other common questions.

As always, we welcome your feedback. For problems, let us know via the Report a Problem option, either from the installer or the Visual Studio IDE itself. For suggestions, let us know through UserVoice.

John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time.

Over the past couple of previews, new C# language features have been trickling in, but Preview 4 marks a point where the majority of C# 7.0 are now available.

Here’s a code sample that uses a good number of these features, and that works in Preview 4 today:

class Program
{
    static void Main(string[] args)
    {
        object[] numbers =
            { 0b1, 0b10, new object[] { 0b100, 0b1000 },   // binary literals
             0b1_0000, 0b10_0000 };                        // digit separators
        var (sum, count) = Tally(numbers);                 // deconstruction
        WriteLine($"Sum: {sum}, Count: {count}");
    }
    static (int sum, int count) Tally(object[] values)     // tuple types
    {
        var r = (s: 0, c: 0);                              // tuple literals
        void Add(int s, int c) { r = (r.s + s, r.c + c); } // local functions
        foreach (var v in values)
        {
            switch (v)                                     // switch on any value
            {
                case int i:                                // type patterns
                    Add(i, 1);
                    break;
                case object[] a when a.Length > 0:         // case conditions
                    var t = Tally(a);
                    Add(t.sum, t.count);
                    break;
            }
        }
        return r;
    }
}

For a full write-up about tuples, deconstruction, pattern matching, local functions, and the rest of C# 7.0, head over to the .NET Blog.

Earlier versions of some of these features were shown at Build 2016.

Happy hacking!

Mads Torgersen, C# Language Program Manager @MadsTorgersen Mads leads the design of the C# language. During his 11 years at Microsoft he also contributed to Typescript, Roslyn, Visual Basic, and LINQ. Before that he was a professor at Aarhus University, doing research on programming languages and type systems.

Today, I am excited to announce that our popular developer event Connect(); is back for a third year on November 16^th and 17^th and will be live-streamed globally from New York City. I encourage you to save the date for what promises to be our best Connect(); yet.

At Connect(); 2016, Executive Vice President Scott Guthrie and Principal Program Manager Scott Hanselman, alongside leading industry innovators, will share the latest innovations from Visual Studio, .NET, Xamarin, Azure, SQL, Windows, Office and more.  Over the two days, you’ll have the opportunity to engage in live, interactive Q&A sessions with our engineering teams, customers and partners and learn how it’s now easier than ever before to build and manage breakthrough intelligent apps that work across Android, iOS, Linux and Windows.

Al Hilwa, IDC recently said, “Microsoft’s Connect(); developer event has grown into a significant milestone for developers building modern apps for cloud, mobile and DevOps deployment scenarios, in the process helping drive positive business impact at their companies.”

Developers inspired us to create the Connect(); event. You are at the center of incredible business transformation and the disruption of entire industries through the development of powerful apps that change the world.  For the past two years, we’ve unveiled new innovative technologies and solutions at Connect(); that represent our relentless drive to meet the needs of any developer, building any application on any platform.  Connect(); 2016 is the next step on our cloud-first, mobile-first world journey.

We’re looking forward to welcoming you on November 16th and 17th.

Mitra Azizirad, Corporate Vice President, Cloud Application Development & Data Marketing With an expansive technical, business and marketing background, Mitra has led multiple and varied businesses across Microsoft for over two decades. She leads product marketing for C+E’s developer and data platform offerings spanning SQL Server, Azure data services, Visual Studio, .NET, Xamarin and associated developer services.

Today we released Visual Studio “15” Preview 5. With this Preview, I want to focus mostly on performance improvements, and in the coming days we’ll have some follow-up posts about the performance gains we’ve seen. I’m also going to point out some of the productivity enhancements we’ve made.

So kick off the installer here and read the rest of the post. You can also grab the release notes here.

A big step forward in performance and memory efficiency

I’d like to start with a side-by-side video that will give you a sense of all the performance improvements in one look. This video compares starting Visual Studio and loading the solution for the entire .NET Compiler Platform “Roslyn” in 30 seconds with Visual Studio ‘15’ compared to 60 seconds with Visual Studio 2015:

The faster load time is a result of a couple of the improvements we’ve made – lightweight project load and on-demand loading of extensions. Here are some of the key performance gains in Preview 5:

• Shorter solution load time with lightweight project load: Working on solutions that contain upwards of 100 projects doesn’t mean you need to work with all the files or projects at a given time. VS “15” provides editing and debugging functionality without waiting for Visual Studio to load every project. You can try out this capability with managed projects in Preview 5 by turning on “Lightweight Solution Load” from Tools -> Options -> Projects and Solutions.
• Faster startup with on-demand loading of extensions: The idea is simple: load extensions when they’re needed, rather than when VS starts. In Preview 5 we started this effort by moving our Python and Xamarin extensions to load on demand and are working on moving all extensions we ship with Visual Studio and extensions shipped by third party extension vendors to this model. Curious about which extensions impact startup, solution load, and typing performance? You can see this information in Help -> Manage Visual Studio Performance. Do you develop an extension? We will be publishing guidance to help extension developers move to on-demand loading.
• Moving subsystems from the main VS process to separatel processes: We moved some memory-intensive tasks such as Git Source Control, and our JavaScript and TypeScript language services to separate processes. This makes it less likely for you to experience delays caused by code running in the main Visual Studio process, or Visual Studio becoming sluggish and even crashing as the main process approaches the 4GB memory limit of 32-bit processes. We will continue to move components out-of-process in coming releases.
• Faster project load, coding, and debugging for C++: We have made loading C++ projects faster. Check out this video showing the improvement. You can enable this by setting “Enable Faster Project Load” to True from Tools -> Options -> Text Editor -> C/C++ -> Experimental. We have also made improvements to our linker and PDB loading libraries to make incremental builds and launching the debugger much faster while significantly reducing memory consumption while debugging.
• Improved speed when using Git, Debugging, and editing XAML Code: We have improved the speed of source control operations by switching from libgit2 to git.exe. We have also improved debugging performance by optimizing initialization costs and other costs related to IntelliTrace and the Diagnostic Tools window, and removed several delays that occur when editing XAML files.

This is just the start and we are dedicated to making improvements like these to make Visual Studio start faster, be more responsive, and use less memory. Keep an eye out for more posts on the Visual Studio blog over the coming days where we’ll go deep into the technical details behind these improvements.

We rigorously test these changes to anticipate issues and deliver the best performance but there is no substitute for real world code. We need your help! So please install Preview 5, try it out with your large solutions, and tell us what you think by using the Report-a-problem tool within the IDE.

Improvements in productivity

Visual Studio “15” also has a lot of features aimed at keeping productivity high.

Editing Code

IntelliSense filtering is now available in C#, VB and C++. While exploring complex APIs, you can narrow to just the type you need (for example, just methods, properties, or events). In C# and Visual Basic we determine the “target type” required at a position and preselect items in the list matching that type. This speeds up your typing flow and removes the burden of having to figure out the expected type at a given location.

In C++, an experimental Predictive IntelliSense feature shows a filtered list of IntelliSense results so you don’t have to scroll through a long list. Only items of the expected type are listed based on need based probability. You can turn on this feature in Tools > Options > Text Editor > C/C++ > Experimental.

In XAML, we have added IntelliSense completion for x:Bind which provides a completion list when you attempt to bind to properties and events. Namespace completion offers to auto-complete the prefix if the reference to the namespace already exists. XAML IntelliSense has also been updated to filter out types and properties that do not match. The closest match is selected, so you only see relevant results and don’t have to scroll through a long list of types.

In JavaScript, we have completely revamped the language service that powers IntelliSense. Previously, as you typed, a JavaScript engine continuously executed your code to provide runtime-like completion lists and signature help. This was great for dynamic JavaScript code, however it often provided an inconsistent editing experience. The new language service uses static analysis powered by TypeScript to provide more detailed IntelliSense, full ES6/ES7 coverage, and a more consistent editing experience.

Quick Fixes and Refactorings

To help you maintain a readable codebase and catalyze your development workflow, we’ve added more Quick Actions and Refactorings for C# and Visual Basic. Move Type to Matching File moves a type into a new file that has the same name and Sync File and Type Name gives you the option to rename your type to match your file name (and vice versa). Lastly, Convert to Interpolated String lets you embrace C# 6.0 and VB14 goodness by transforming your `string.Format` expressions into interpolated strings.

Navigating Code

Getting around, and knowing where you are in a large codebase can be challenging; we’ve added several new navigation features to help with this. Go To: (Ctrl + , or Ctrl + T) lets you quickly find files, types, methods, and other kinds of objects in your code.

Find All References (Shift+F12) now helps you get around easily, even in complex codebases. It provides advanced grouping, filtering, sorting, searching within results, and (for some languages) colorization, so you can get a clear understanding of your references.

Debugging

In Preview 5 we have introduced and experimental feature: Run to Click. You no longer need to set a temporary breakpoint to skip ahead and stop on the line you desire. When stopped in the debugger, simply click the icon that appears next to the line of code your mouse is over. Your code will run and stop on that line the next time it is hit. You can turn on this feature in Debug > Options > Enable Run to Click.

The New Exception Helper: See what you need more quickly with the new Exception Helper. View the most useful exception information at a glance, including seeing what variable was null, in a compact non-modal dialog with instant access to inner exceptions.

Try it out

For the complete list of everything in this release, along with some known issues, look at the Visual Studio “15” Preview 5 Release Notes page.

A couple of important caveats about Preview 5. First, this is an unsupported preview so don’t install it on machines that you rely on for critical production work. Second, Preview 5 should work side by side with previous versions of Visual Studio, but you must remove any previous Visual Studio “15” Preview installations before beginning the setup process. Check out this Preview 5 FAQ for other common questions.

As always, we welcome your feedback. For problems, let us know via the Report a Problem option, either from the installer or the Visual Studio IDE itself. Track your feedback on the developer community portal. For suggestions, let us know through UserVoice.

Last but not least, check out Mitra’s post from earlier today to learn more about the upcoming developer conference Connect(); 2016.

John Montgomery, Director of Program Management for Visual Studio @JohnMont John is responsible for product design and customer success for all of Visual Studio, C++, C#, VB, JavaScript, and .NET. John has been at Microsoft for 17 years, working in developer technologies the whole time.

In Visual Studio 2015 Update 3, we introduced support for building apps that target the Windows Anniversary Update SDK. Visual Studio “15” continues where VS 2015 left off and brings several new experiences and enhancements for UWP developers. We have been focusing on improving three major areas:

1. Quick and easy getting started experience with building a UWP application
2. Productive experiences when authoring or debugging code
3. Performance and reliability improvements

While you’ll continue to see a steady stream of improvements in upcoming releases of VS “15”, there are several new experiences in this release for you to try and give feedback.

UWP tools with the new Visual Studio “15” installer

Getting started with tools for UWP development has never been easier or faster. With Visual Studio “15”, we have optimized the Universal Windows Platform development workload for developers to get up and running as quickly as possible. We give you just the right tools to be productive in authoring, debugging, and publishing UWP apps. Don’t worry, if something is missing by default, you will be able to add it later.

With the default experience for the Universal Windows Platform development workload, the size on disk has reduced by over 60% compared to Visual Studio 2015. That means shorter download time, quicker install, and faster to get to coding!

Visual Assets for apps made easier

We’ve visually refreshed the Manifest Designer and made it easier to create branding manifest assets for your UWP apps. With the Manifest Asset Generator, you can create all the visual assets for your apps from within the Manifest Designer. Using a single source image, you can create tiles, logos, icons and splash screens at any or all scales to fit every type of device your app targets. We take care of adhering to all the design guidelines suggested for Windows 10 apps like padding and background colors. The current release supports C# and Vb. Support for C++ and JS is planned for a future release of Visual Studio.

Discover accessibility and performance issues with the new UI Analysis tool

To help you discover hard to find issues around accessibility and performance, we’ve expanded on the XAML UI Debugging tools with the new UI Analysis tool. The tool can be enabled for UWP apps by enabling it in the Select Tools menu of the Diagnostics Tools Window.

Once enabled, the UI Analysis tools will examine the elements in your app, searching for common performance or accessibility issues. These will show up in the Events window along with links to MSDN. If an element isn’t exposing a Name property, a property critical to screen readers, the UI Analysis tool will flag the element as being problematic. Similarly, a ListBox that isn’t properly virtualizing its contents can cause significant performance issues. The UI Analysis tool will detect this and provide documentation on how to fix it. These are just a few of the issues that the UI Analysis tool can help identify. The Filter menu provides the complete list of issues that can be detected.

Improvements to the XAML Designer

Creating elements from the toolbox will now create leaner XAML with less tags. For instance, elements dragged directly from the toolbox onto the artboard will be created without explicitly setting the Width and Height. Our goal is cleaner, more readable XAML and this represents a major ask from our customers.

A new options menu on the artboard allows the developer to quickly change the theme for the artboard. By clicking the options gear, the developer can switch the visual theme and/or modify the High Contrast settings, and these settings will be reflected immediately on the design surface. This will allow developers to view a wider range of settings immediately without having to constantly change the settings on their development machine.

Finally, the numeric value editors in the Properties window now support basic arithmetic (thanks for the UserVoice suggestion!). The value editor will evaluate the equation and replace it with the corresponding value, and insert that value into the XAML. For instance, if a developer wished to increase the Width of a 36px wide Button by 8px, they could calculate that value in their head, or merely type “36+8”. The value editor will evaluate that equation and replace it with 44.

Faster XAML tab switch and snappier XAML typing experience

We have made investments to make interacting with XAML files snappier. One area where this would be most apparent is navigating away from XAML files or switching between XAML files. We have data that suggests 1 in 4 developers experience at least one XAML tab switch delay of more than 1 second every day. These delays could be higher in projects that have a large number of XAML files and/or resource dictionaries among other things. With Preview 5, the tab switching experience will be almost instantaneous for a majority of developers. Projects that experienced larger delays should see improvements by an order of magnitude. On sample customer apps, we saw more that 90% improvement in tab switch times.

We have also fixed several XAML editor typing delay issues. Most developers should find the XAML editor and the XAML IntelliSense to be more responsive. This would be most apparent when editing a XAML file in projects that consume third party controls or large control libraries.

Tell us what you think

As always, we welcome your feedback. For problems, let us know via the Report a Problem option in Visual Studio. Track your feedback on the developer community portal. For suggestions on how we can make Visual Studio even better for building Universal Windows apps, let us know through UserVoice.

Karan Nandwani, Program Manager, Visual Studio @karann9 Karan works on the XAML Tools Team in Visual Studio. He owns XAML editor features and enjoys designing next-gen productivity enhancement tooling. In his free time, he likes biking, FPS games, and EDM.

As John mentioned last Wednesday in the preview 5 announcement post, we are investing heavily performance improvements in this release. This is part one of a five-part series covering performance improvements for Visual Studio “15”.

Today, I’ll walk you through a set of investments we made to improve the Visual Studio startup experience in this latest release and specifically cover the following topics:

• Using our new performance center, how you can determine if you are using extensions or tool windows that are impacting experiences such as startup, solution load, or code editing. And of course, how to optimize it.
• How moving extensions out of the startup path using an on-demand-load approach and optimizing and deferring cache initializations help us improve the startup times.

As the Visual Studio user base has grown tremendously over the years, so has the variety of partner technologies used in Visual Studio. Unfortunately, some of the extensions significantly impact Visual Studio startup time as features and extensions load automatically at startup.

Below is an example indicating how Visual Studio startup time could easily get 50% slower when loading extensions at startup.

What is involved in Visual Studio startup?

There are three different Visual Studio startup types:

1. First launch: the very first launch of Visual Studio after setup has finished. First launch of Visual Studio is considerably slower than other startups because the Visual Studio environment is configured with various caches and prebuilt tables.
2. Normal startup: we call subsequent Visual Studio launches, following the first launch, as normal startup; such launches exclude debug instances, or instances launched using command line arguments, as well as instances where an extension or update was installed before. 80% of Visual Studio startups fall into the normal startup category.
3. Configuration change: a startup that occurs after when an extension or update is installed.

These types help us identify the root cause of potential slow-downs and enable further investigations for optimizations.

First launch improvements

In Visual Studio 2015, a first launch startup involves scanning installed components and creating a configuration hive, initializing default settings, getting user sign-in information, and initializing caches such as the Managed Extensibility Framework (MEF), extension manager, toolbox, and font/color caches.

In Visual Studio “15”, we have considered each of these steps to see which ones can be deferred or optimized:

• We experimented with deferring toolbox initialization in Visual Studio 2015 which had a positive impact on load time and changed it permanently in Visual Studio “15”.
• Some caches like the font and color cache are no longer initialized at first launch. Instead, we significantly improved cache configuration allowing us to defer their initialization until a later time without impacting the user experience at first launch.
• By having MEF and the extension manager service be asynchronous, we can now initialize those caches in parallel while sign-in runs.

With all these changes, we are happy to announce that Visual Studio “15” launches up to 3x faster than Visual Studio 2015. Here is a very early read from our telemetry:

Normal startup improvements

A normal startup of Visual Studio, at minimum, involves initializing core services. Every release we continue to monitor these services to ensure core initialization doesn’t get longer. On top of core services, startup can be impacted by two major additions; extensions that are automatically loaded at startup and tool windows that persist in the window layout from a previous instance. Our telemetry suggests that automatically loading extensions, including both Microsoft and 3^rd party ones, significantly increase Visual Studio startup time.

As mentioned above, our primary focus in Visual Studio “15” has been avoiding automatic loading of extensions and providing more options for those extensions to be able to load later without impacting the user experience. As part of that work, we have delivered features like:

• Enabling asynchronous loading support for Visual Studio packages
• Extending metadata rules that control automatic package loading and command visibility
• Supporting asynchronous query of core Visual Studio services

Xamarin and Python tooling are the first to adopt the on-demand-load approach in Visual Studio “15”. You should now see that startup is considerably faster in cases where you have these extensions installed.

Another factor that impacts startup is tool windows that are visible on the IDE at the startup time. These tool windows persist from the previous instance and such tool windows add time depending on the size of the features they initialize; and some of them are quite noticeable. We continue to focus on improving performance of such tool windows based on our telemetry. In addition, the Manage Visual Studio Performance dialog helps you override default persistence behavior for these tool windows going forward. You will learn more about this dialog in the next section.

Monitoring extension and tool window performance

While we are minimizing the need for auto loading features at startup, we also added a feature in Visual Studio “15” to help users understand the impact of their extensions and tool windows at startup and other scenarios such as solution load and editing. Yes, this feature does auto-load to monitor what happens during Visual Studio startup.

When you launch Visual Studio, for a slower extension you will get a one-time notification regarding the extension’s performance impact on startup.

At any time, you can go to Help -> Manage Visual Studio Performance to open the dialog and see which extensions or tool windows are impacting your Visual Studio’s startup, solution load or typing performance. From the Manage Visual Studio Performance dialog, you can disable the extension.

Like extensions, you can see the impact of a tool window in the same dialog. If a tool window slows down the Visual Studio startup significantly, you will also get a notification. You can override the default persistence behavior by choosing from one of the two options below:

• Use default behavior; no change to the current behavior. Hence, you won’t get any benefit if you chose this option.
• Do not show window at startup; tool window will never persist between instances. You can open it later from a menu.
• Auto hide window at startup; if tool window is visible at startup, this selection will collapse its group to avoid initializing the tool window. This option is my favorite.

You can always revert these options by going back to Manage Visual Studio Performance dialog and changing the option to Use default behavior.

Continue to help us

While this post focuses on startup improvements, there are also significant investments in solution load area that my colleague Will Buik will talk about in the next post. Together these changes should allow Visual Studio to start faster when opened with a solution selected from Windows Explorer as well.

You can help us make Visual Studio a better product for you in several ways:

• First, we monitor telemetry from all our releases, including pre-releases. Please download and use Visual Studio “15” Preview 5.
• Secondly, if you are an extension author, stay tuned; in the upcoming weeks, we will post details on how extension authors can analyze their extension. As any extension that chooses to auto load at startup or when a solution is being opened can negatively impact performance of Visual Studio. The coming guidance will help evaluating if new features in Visual Studio “15” can be used to remove the need for auto loading or reduce the impact of auto loading. For those extensions that need to auto load, the guidance will also help with measuring the impact on startup.

Thanks!

Selma

Selma Ikiz, Program Manager, Visual Studio IDE Selma has been working in developer technologies since she joined Microsoft in 2009. Her major focus has been delivering performant and stable IDE to developers. She is currently working on improving the new Visual Studio Installer through telemetry.

This is the 2^nd post in a five-part series covering performance improvements for Visual Studio “15”.

Yesterday Selma shared some of the ways we have made Visual Studio “15” startup quicker than ever. Today, I will talk about a new feature in Visual Studio “15” called lightweight Solution load. This feature significantly reduces Solution load time so you can be more productive, faster in the IDE.

Lightweight Solution Load

At a high level, when lightweight Solution load is enabled, Visual Studio will not fully load projects until you start working with them. Many common tasks, such as navigating through your codebase, editing code, and building your projects will not require any projects to be loaded at all.

We released lightweight Solution load in a limited capacity in Visual Studio “15” Preview 4, to gain some real world insight about how it works with your projects. So far, these performance improvements have been promising:

In our limited roll out of this feature, we have seen Solution load time cut as much as two to four times.

The end goal of this feature is all about allowing you to get productive in the IDE as quickly as possible. Developers using lightweight Solution load were able to begin navigating through and building their code one to two minutes faster. We expect similar results in Preview 5 with the broader release of the feature.

Try it Out

Lightweight Solution load is not enabled by default in Preview 5, but we would like to encourage any developers with medium to large, managed Solutions to try the feature out and give feedback. To turn on lightweight Solution load, navigate to Tools->Options, Projects and Solutions->General and check the “Lightweight Solution load” setting at the bottom of the page:

Once lightweight Solution load is enabled, you can open and work with your projects and Solutions as usual. The setting will take effect the next time you load a Solution; restarting the IDE is not necessary.

Lightweight Solution load focuses on managed projects in Preview 5. If you work with medium to large C# or VB Solutions, we strongly encourage you to try out this feature. You can open mixed Solutions with C++ or other project types too – but keep in mind, not all of the performance enhancements are available yet for other types of projects (more details below*).

Once lightweight Solution is turned on, you can more or less go about your business as usual – just a little faster. A few things in particular to try out:

• Navigate across your codebase with Navigate To (Ctrl+,), Go to Definition (F12), Find in Files, or Find all References.
• Refactor or inline rename.
• Build or debug your Solution.

You may notice that some operations take a brief moment to load project data in the background:

Keep in mind, lightweight Solution load is still experimental, so there are still a few rough edges:

• If a feature related to a project seems to be missing from the IDE, try expanding that project in the Solution Explorer. Please let us know if anything doesn’t seem to be working as expected.
• NuGet package restore isn’t yet integrated with lightweight Solution load. We recommend restoring packages before turning on the feature or using the command line.
• The Test Explorer will not see tests unless a project is fully loaded.
• If you need to retarget or upgrade all projects in a Solution, disable Lightweight Solution load for best results.

*Even though the focus of lightweight Solution load is managed projects in Preview 5, don’t worry if you are a C++ developer. There are plenty of performance improvements coming your way in Preview 5 as well – check out part four of this series on Thursday for more details. These improvements will be integrated into lightweight Solution load in a future release.

Send Us Feedback!

We would love to hear feedback about your experiences using lightweight Solution load. If you run into any issues you can use the “Report a Problem” tool in the upper right hand corner of the IDE to let us know. For performance issues, such as the IDE loading slowly or becoming non-responsive, please report issues to us using the Report-a-problem tool. This guide links to a tool that will automatically collect the traces and other assets we need to diagnose performance issues.

If you work with large codebases and are interested in sharing feedback with us about your experiences, please consider filling out this brief survey with your contact information and a few details about the type of development you do. Your feedback helps us deliver the best development experience possible.

Will Buik – Program Manager, Visual Studio IDE Project and Build Will is a long time user of Visual Studio. Since his foray into programing with Visual Basic 4, he has loved programming, software development, and hardware hacking.  He loves working on the development tools that he has leveraged for many years.

This is the third post in a five-part series covering performance improvements in Visual Studio “15” Preview 5. The previous 2 posts talked about faster startup, and shorter solution load times in Visual Studio 15″.

Visual Studio is chock-full of features that millions of developers rely on to be productive at their work. Supporting these features, with the responsiveness that developers expect, consume memory. However, in Visual Studio 2015, in certain scenarios the memory usage grew too large. This led to adverse impact such as out-of-memory crashes and UI sluggishness. We received feedback from a lot of customers about these problems. In VS “15” we are tackling these issues while not sacrificing the rich functionality and performance of Visual Studio.

While we are optimizing a lot of feature areas in Visual Studio, this post presents the progress in three specific areas – JavaScript and TypeScript language services, symbol loading in the debugger, and Git support in VS. Throughout this post I will compare the following two metrics for each of the measured scenarios, to show the kind of progress we have made:

Peak Virtual Memory: Visual Studio is a 32bit application, which means the virtual memory consumed can grow up to 4GB. Memory allocations that cause total virtual memory to cross that limit will cause Visual Studio to crash with an “Out of memory” (OOM) error. Peak Virtual Memory is a measure of how close the process is to the 4GB limit, or in other words, how close the process is to crashing.

Peak Private Working Set: A subset of the virtual memory which contains code that the process executes or data that the process touches, needs to be in physical memory. “Working set” is a metric that measures the size of such physical memory consumption. A portion of this working set, called “Private Working Set”, is memory that belongs to a given process and that process alone. Since such memory is not shared across processes, their cost on the system is relatively higher. Measurements in this post report the peak private working set of Visual Studio (devenv.exe) and relevant satellite processes.

JavaScript language service

Over a third of Visual Studio developers write JavaScript (JS) on a regular basis, making the JS language service a component that is loaded in a significant number of Visual Studio sessions. The JS language service provides such features as IntelliSense, code navigation, etc., that make JS editing a productive experience.

To support such productivity features and to ensure they are responsive, the language service consumes a non-trivial amount of memory. The memory usage depends on the shape of the solution, with project count, file count, and file sizes being key parameters. Moreover, the JS language service is often loaded in VS along with another language service such as C#, which adds to the memory pressure in the process. As such, improving the memory footprint of the JS language service is crucial to reducing the number of OOM crashes in VS.

In VS “15”, we wanted to ensure Visual Studio reliability is not adversely impacted by memory consumption regardless of the size and shape of the JS code. To achieve this goal without sacrificing the quality of the JavaScript editing experience, in VS “15” Preview 5 we have moved the entire JS language service to a satellite Node.js process that communicates back to Visual Studio. We have also merged the JavaScript and TypeScript language services, which means we achieve net memory reduction in sessions where both language services are loaded.

To measure the memory impact, we compared Visual Studio 2015 Update 3 with VS “15” Preview 5 in this scenario:

• Open WebSpaDurandal solution. This is an Asp.Net sample, which we found to represent the 95^th percentile in terms of JS code size we see opened in VS.
• Create and enable auto syncing of _references.js
• Open 10 JS files
• Make edits, trigger completions, create/delete files, run the format tool

Here are the results:

Chart 1: Memory usage by the JavaScript language service

Peak virtual memory usage within Visual Studio is reduced by 33%, which will provide substantial relief to JS developers experiencing OOM crashes today. The overall peak private working set, which in Preview 5 represents the sum of the Visual Studio process and our satellite node process, is comparable to that of Visual Studio 2015.

Symbol loading in the debugger

Symbolic information is essential for productive debugging. Most modern Microsoft compilers for Windows store symbolic information in a PDB file. A PDB contains a lot of information about the code it represents, such as function names, their offsets within the executable binary, type information for classes and structs defined in the executable, source file names, etc. When the Visual Studio debugger displays a callstack, evaluates a variable or an expression, etc. it loads the corresponding PDB and reads relevant parts of it.

Prior to Visual Studio 2012, the performance of evaluating types with complex natvis views, was poor. This was because a lot of type information would be fetched on demand from a PDB, which would result in random IOs to the PDB file on disk. On most rotational drives this would perform poorly.

In Visual Studio 2012, a feature was added to C++ debugging that would pre-fetch large amounts of symbol data from PDBs early in a debugging session. This provided significant performance improvements when evaluating types, by eliminating the random IOs.

Unfortunately, this optimization erred too much on the side of pre-fetching symbol data. In certain cases, it resulted in a lot more symbol data being read than was necessary. For instance, while displaying a callstack, symbol data from all modules on the stack would get pre-fetched, even though that data was not needed to evaluate the types in the Locals or Watch windows. In large projects having many modules with symbol data available, this caused significant amounts of memory to be used during every debug session.

In VS “15” Preview 5, we have taken a step towards reducing memory consumed by symbol information, while maintaining the performance benefit of pre-fetching. We now enable pre-fetching only on modules that are required for evaluating and displaying a variable or expression.

We measured the memory impact using this scenario:

• Load the Unreal Engine solution, UE4.sln
• Start Unreal Engine Editor
• Attach VS debugger to Unreal Engine process
• Put Breakpoint on E:\UEngine\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl_Variadics.inl Line 640
• Wait till breakpoint is hit

Here are the results:

Chart 2: Memory usage when VS Debugger is attached to Unreal Engine process

VS 2015 crashes due to OOM in this scenario. VS “15” Preview 5 consumes 3GB of virtual memory and 1.8GB of private working set. Clearly this is an improvement over the previous release, but not stellar memory numbers by any means. We will be continuing to drive down memory usage in native debugging scenarios during rest of VS “15” development.

Git support in Visual Studio

When we introduced Git support in Visual Studio, we utilized a library called libgit2. For various operations, libgit2 maps the entire git index file into memory. The size of the index file is proportional to the size of the repo. This means that for large repos, Git operations can result in significant virtual memory spikes. If VS was already under virtual memory pressure, these spikes can cause OOM crashes.

In VS “15” Preview 5, we no longer use libgit2 and instead call git.exe, thus moving the virtual memory spike out of VS process. We moved to using git.exe not only to reduce memory usage within VS, but also because it allows us to increase functionality and build features more easily.

To measure the incremental memory impact of a Git operation, we compared Visual Studio 2015 Update 3, with VS “15” Preview 5 in this scenario:

• Open Chromium repo in Team Explorer
• Go to “Changes” panel to view pending changes
• Hit F5 to refresh

Here are the results:

Chart 3: Incremental memory usage when “Changes” panel in Team Explorer is refreshed

In VS 2015, the virtual memory spikes by approximately 300MB for the duration of the refresh operation. In VS “15”, we see no measurable virtual memory increase. The incremental private working set increase in VS 2015 is 79MB, while in VS “15” it is 72MB and entirely from git.exe.

Conclusion

In VS “15” we are working hard at reducing memory usage in Visual Studio. In this post, I presented the progress made in three feature areas. We still have a lot of work ahead of us and are far from being done.

There are several ways, you can help us on this journey:

• First, we monitor telemetry from all our releases, including pre-releases. Please download and use VS “15” Preview 5. The more usage we have with external sources in day to day usage scenarios, better the signal we get and that will immensely help us.
• Secondly, report high memory (or any other quality) issues to us using the Report-a-problem tool. The most actionable are reports that help us reproduce the issues at our end, by providing us with sample or real solutions that demonstrate the issue. I realize that is not always an option, so the next best are reports that come attached with a recording of the issue (Report-a-problem tool lets you do this easily) and describe the issue in as much detail as possible.

Ashok Kamath, Principal Software Engineering Manager, Visual Studio Ashok leads the performance and reliability team at Visual Studio. He previously worked in the .NET Common Language Runtime team.

With Visual Studio ‘15’ our goal is to considerably improve productivity for C++ developers. With this goal in mind we are introducing many new improvements, which you can try out in the recently released Preview 5 build. The highlights of this release include the following:

Faster C++ solution load

‘Fast project load’ is a new experimental feature for C++ projects. The first time you open a C++ project it will load faster, and the time after that it will load even faster! To try out this experimental feature set ‘Enable Faster Project Load’ to true in Tools -> Options as shown in the figure below:

The small demo below depicts these improvements on the large Chromium Visual Studio Solution which has 1968 projects. Check out this blog post to learn more about how faster C++ solution load operates.

There is another experimental effort underway in Visual Studio to improve solution load called “lightweight solution load”.  This is a completely different approach and you can read about it here.
Generally, it will avoid loading projects at all and will only load a project when a user explicitly expands a project in Solution Explorer.  The C++ team has been focused on Fast Project Load and so our support for lightweight solution load is currently minimal.  In the RC release of Visual Studio 15, we expect to support fast project load feature in conjunction with Lightweight Solution Load.  This combination should provide a great experience.

Faster build cycle with /Debug:fastlink

Developer builds will now build faster, because of faster links with an integrated /debug:fastlink experience. Expect to see 2-4x linker improvements for your application builds.

The figure below illustrates how /debug:fastlink helps improve link times for some popular C++ sources. You can learn more about /debug:fastlink and its integration into Visual Studio in the Faster C++ build cycle blog post we published last week.

Reducing out-of-memory crashes in VS while debugging

With VS “15” Preview 5, we have also taken a step towards reducing memory consumed by symbol information, while maintaining the performance benefit of pre-fetching symbol data. We now enable pre-fetching only on modules that are relevant for evaluating and displaying a variable or expression. As a result, we are now able to successfully debug the Unreal engine process and contain it within 3GB of virtual memory and 1.8GB of private working set. Previously in VS 2015 when debugging the Unreal engine process, we would run out-of-memory. Clearly this is an improvement over the previous release, but we’re not done yet. We will be continuing to drive down memory usage in native debugging scenarios during the rest of VS “15” development.

Wrap Up

As always, we welcome your feedback and we would love to learn from your experiences as you try out these features. Do let us know how these improvements scale for your C++ code base.
If you run into any problems, let us know via the Report a Problem option, either from the installer or the Visual Studio IDE itself. You can also email us your query or feedback if you choose to interact with us directly! For new feature suggestions, let us know through User Voice.

Jim Springfield, Principal Architect, Visual C++ team. Jim is passionate and guru about all things C++ and is actively involved in redesigning of the compiler frontend, language service engine, libraries and more. Jim is also the author of popular C++ libraries MFC, and ATL and his most recent work also involves development of the initial cross-platform C++ language service experience for upcoming editor Visual Studio Code.

Ankit Asthana, Senior Program Manager, Visual C++ team. Ankit’s focus area is cross-platform mobile development along with native code generation tools. Ankit is also knowledgeable in compilers, distributed computing and server side development. He has in the past worked for IBM and Oracle Canada as a developer building Java 7 (hotspot) optimization and telecommunication products. Ankit back in 2008 also published a book on C++ titled ‘C++ for Beginners to Masters’ which sold over a few thousand copies.

This is the final post in a five-part series covering performance improvements for Visual Studio “15”.

This series covers the following topics:

• Part 1: Faster Visual Studio “15” Startup
• Part 2: Shorter Solution Load Time in VS “15”
• Part 3: Reduced out-of-memory crashes in VS “15”
• Part 4: VS “15” gets faster for C++
• Part 5: Improving overall VS “15” responsiveness

In this post we will highlight some of the improvements we’ve made in the Preview 5 release that make using Visual Studio more responsive as part of your daily use. We’ll first talk about improvements to debugging performance, Git source control, editing XAML, and finally how you can improve your typing experience by managing your extensions.

Debugging is faster and doesn’t cause delays while editing

In Visual Studio 2005 we introduced what’s known as the hosting process for WPF, Windows Forms, and Managed Console projects to make “start debugging” faster by spinning up a process in the background that can be used for the next debug session. This well-intentioned feature was causing Visual Studio to temporarily become unresponsive for seconds when pressing “stop debugging” or otherwise using Visual Studio after the debug session ended.

In Preview 5 we have turned off the hosting process and optimized “start debugging” so that it is just as fast without the hosting process, and even faster for projects that never used the hosting process such as ASP.NET, Universal Windows, and C++ projects. For example, here are some startup times we’ve measured on our test machines for our sample UWP Photo Sharing app, a C++ app that does Prime Visualization, and a simpler WPF app:

To achieve these improvements, we’ve optimized costs related to initializing the Diagnostic Tools window and IntelliTrace (which appears by default at the start of every debugging session) from the start debugging path. We changed the initialization from IntelliTrace so that it can be initialized in parallel with the rest of the debugger and application startup. Additionally we eliminated several inefficiencies with the way the IntelliTrace logger and Visual Studio processes communicate when stopping at a breakpoint.

We also eliminated several places where background threads related to the Diagnostic Tools window had to synchronously run code on the main Visual Studio UI thread. This made our ETW event collection more asynchronous so that we don’t have to wait for old ETW sessions to finish when restarting debugging.

Source code operations are faster with Git.exe

When we introduced Git support in Visual Studio we used a library called libgit2. With libgit2, we have had issues with functionality being different between libgit2 and the git.exe you use from the command prompt and that libgit2 can add 100s of megabytes of memory pressure to the main Visual Studio process.

In Preview 5, we have swapped this implementation out and are calling git.exe out of process instead, so while git is still using memory on the machine it is not adding memory pressure to the main VS process. We expect that using git.exe will also allow us to make git operations faster over time. So far we have found git clone operations to faster with large repos: cloning the Roslyn .NET Compiler repo on our machines is 30% faster: takes 4 minutes in Visual Studio ‘15’ compared with 5 minutes, 40 seconds with Visual Studio 2015. The following video shows this (for convenience the playback is at 4x speed):

In the coming release we hope to make more operations faster with this new architecture.

We have also improved a top complaint when using git: switching branches from the command line can in cause Visual Studio to reload all projects in the solution one at a time. In the file change notification dialog we’ve replaced ‘Reload All’ with ‘Reload Solution’:

This will kick off a single async solution reload which is much faster than the individual project reloads.

Improved XAML Tab switch speed

Based on data and customer feedback, we believe that 25% developers experience at least one tab switch delay > 1 sec in a day when switching between XAML tabs. On further investigation, we found that these delays were caused by running the markup compiler, and we’ve made use of the XAML language service to make this substantially faster. Here’s a video showing the improvements we’ve made:

The markup compiler is what creates the g.i.* file for each XAML file which, among other things, contains fields that represent the named elements in the XAML file that enables you to reference those named elements from code-behind. For example, given <Button x:Name=”myButton” />, the g.i.* file will contain a field named button of type Button that allows you to use “myButton” in code.

Certain user actions such as saving or switching away from an unsaved XAML file will cause Visual Studio to update the g.i.* file to ensure that IntelliSense has an up-to-date view of your named elements when you open your code-behind file. In past releases, this g.i.* update was always done by the markup compiler. In managed (C#/VB) projects the markup compiler is run on the UI thread resulting in a noticeable delay switching between tabs on complex projects.

We have fixed this issue in Preview 5 by leveraging the XAML Language Service’s knowledge of the XAML file to determine the names and types of the fields to populate IntelliSense, and then update the g.i.* file using Roslyn on a background thread. This is substantially faster than running the markup compiler because the language service has already done all the parsing and type metadata loading that causes the compiler to be slow. If the g.i.* file does not exist (e.g. after renaming a XAML file, or after you delete your project’s obj directory), we will need to run the markup compiler to generate the g.i.* file from scratch and you may still see a delay.

Snappier XAML typing experience

The main cause of UI delays in our XAML Language Service were related to initialization, responding to metadata changes, and loading design assemblies. We have addressed all three of these delays by moving the work to a background thread.

We’ve also made the following improvements to the design of assembly metadata loading include:

• A new serialization layer for design assembly metadata that significantly reduces cross boundary calls.
• Reuse of the designer’s assembly shadow cache for WPF projects. Reuse of the shadow cache across sessions for all project types. The shadow cache used to be recreated on every metadata change.
• Design assembly metadata is now cached for the duration of the session instead of being recomputed on every metadata change.

These changes also allow XAML IntelliSense to be available before the solution is fully loaded.

Find out which extensions cause typing delays

We have received a number of reports about delays while typing. We are continuing to make bug fixes to improve these issues, but in many cases delays while typing are caused by extensions running code during key strokes. To help you determine if there are extensions impacting your typing experience, we have added reporting to Help -> Manage Visual Studio performance, and will notify you when we detect extensions slowing down typing.

Notification of extensions slowing down typing

You can see more details about extensions in Help -> Manage Visual Studio Performance

Try it out and report issues

We are continuing to work on improving the responsiveness of Visual Studio, and this post contains some examples of what we have accomplished in Preview 5. We need your help to focus our efforts on the areas that matter most to you, so please download Visual Studio ‘15’ Preview 5, and use the Report-a-Problem tool to report areas where we can make Visual Studio better for you.

Dan Taylor, Senior Program Manager Dan Taylor has been at Microsoft for 5 years working on performance improvements to .NET and Visual Studio, as well as profiling and diagnostic tools in Visual Studio and Azure

Last month I had the pleasure of participating in a panel discussion at the Microsoft Ignite conference where we discussed mobile app development. I spoke about Visual Studio’s Tools for Apache Cordova (a.k.a. “TACO” for short) side-by-side with James Montemagno of Xamarin fame, Ankit Asthana from the Visual Studio C++ team, and Daniel Jacobson from the UWP team. I heard a lot of really good questions from the audience. Some of these questions are so common that I figure many of our Visual Studio blog readers may find them interesting. In this post I’m going to share the answers to our most common TACO questions. (Sorry, no definitive answer to the most pressing question of all: hard or soft shell tacos?)

Feel free to ask new questions via the comments section at the bottom of this post! If I get a strong response, I may even look at writing a follow-up post to answer them.

• What is TACO?
• I have both .NET and web development skills, should I use Xamarin or Cordova to go mobile?
• I have an existing web app; how can I use Cordova to make it mobile?
• Using Apache Cordova, can I use native features such as push notifications?
• How can I make a mobile app that will live for 5-10 years?

What is TACO?

The Tools for Apache Cordova – or “TACO” for short – constitute a set of utilities that make it easier, friendlier and faster to develop mobile applications using web technologies (HTML, JavaScript, CSS). You can use these tools to build apps for Android, iOS, or Windows devices. TACO is a suite of products built by Microsoft, including:

• Visual Studio TACO – a complete IDE for building and debugging Apache Cordova apps. You can download it for free from the Visual Studio website.
• The Cordova Tools extension for Visual Studio Code – an extension for Visual Studio Code that provides IntelliSense, debugging, and build support for Apache Cordova and Ionic projects.

I have both .NET and web development skills, should I use Xamarin or Cordova to go mobile?

Many of our blog readers, myself included, have experience building with both .NET and web-based technologies. Consequently, both Xamarin (which lets you take your .NET skills mobile) and Apache Cordova (taking your web skills mobile) may be appealing for mobile development. That’s why this has been our #1 most asked question for years, and even more so now that Xamarin has joined Microsoft and is included for free in Visual Studio!

The short answer is that “it depends” – not all apps or development teams are the same, so you want to look at where the two technologies excel and consider the skills of your existing team (which may just be you). Both products make it possible for you to share nearly 100% of your code across iOS, Android, and Windows applications.

Cordova is great if you:

• Prefer working with JavaScript, HTML, CSS, and libraries built on top of that tech.
• Already have web sites/content that you’d like to re-use in a mobile app.
• Plan to use the most common device features, like the camera.
• Want to take advantage of services like CodePush, which give you the ability to publish bug fixes and incremental updates to your app without resubmitting to the stores.

While you could build just about any mobile app using Cordova, I’d say you generally wouldn’t use Cordova to build a graphics or data processing intense application like a game; nor would you want to use it to build an app with the richest native-app user experience and animations (though there are frameworks that you can use to build an app that feels just about as good as native). Among the customers we’ve spoken with, a common use for Cordova is to take existing “line of business” or data entry/forms-based web applications and make them mobile. These can be apps like expense and time tracking, retail inventory management, or investment portfolio tracking.

Both Xamarin and Cordova provide you a way to get at native device features, but there’s a big difference in how they work. Xamarin has built-in support for all native APIs on devices, but in Cordova you have to navigate the ecosystem of open source plugins (read more about plugins, below). Plugins can vary in quality and may not be updated as quickly as Xamarin. Companies like Adobe and Microsoft are vigilantly maintaining the plugins most often used by businesses/enterprises to make sure they work great, but other plugins are the domain of the larger community.

Xamarin is great if you:

• Want to have full access to native API features.
• Need to build apps using the latest user interface guidelines.
• Prefer working with C#, .NET, XAML (In the case of Xamarin.Forms) and frameworks built on top of that tech.
• Already have .NET libraries (like JSON.NET) or other .NET assets you’d like to re-use in a mobile app.
• Want to take advantage of the full performance of a device.

Xamarin offers the ability to use existing .NET ecosystem technologies, such as NuGet, to build a fully native application that runs with the same performance that is expected from a native app. As Xamarin utilizes the APIs for each platform, Xamarin also offers the ability to use the latest and greatest of what each platform has to offer. Any app that you could build using the native platforms, you can build using Xamarin.

Regardless of your choice

No matter which way you go, I do recommend trying out the tools first and build a prototype or two to see what comfortably suits your development style and application needs.

I have an existing web app; how can I use Cordova to make it mobile?

The simplest thing you can do to take your existing web application to mobile is to build something called a hosted web application. This is a Cordova application that has all its content hosted on a web server, instead of stored locally on the device. It follows the traditional web server hosted model that web developers know and love today. This means you can leverage your existing web assets and create an app that can be loaded to an app store. You can learn more about this technique in the Create a hosted web app using Apache Cordova tutorial on the TACO documentation site. The hosted web app model goes a step further than just hosting a website in the application, it also makes it possible for you to enable the hosted web application to access native device capabilities by leveraging the Cordova plugin model.

With this model you do have some downsides – you still must do extra work if you want to have an application that can work offline/with no network connectivity (because, you wouldn’t be able to get the app’s content from a web server when there’s no network connection).

You might also consider building a separate version of your application tailored just to mobile devices, but still share some common code – see below for some suggestions there.

How does Cordova compare to the new Progressive Web Apps model?

Progressive Web Apps, or “PWA” for short, allow you to build a mobile version of your website that end users can add on their dev’s home screen. This PWA app will run from a web server, but has added capabilities to handle offline caching, send push notifications, and make background content updates. Using web standard APIs already available today, such as Geolocation, you can pretty simply make a web experience that functions like a native app without having to go through an app store. (take a look at this article from our friend’s in the Ionic team, to learn more).

I’d say the three key differences between PWAs in their current form, and Apache Cordova, are:

1. PWAs do not provide you access to full native device features; only those supported by standard web APIs today. Cordova makes it possible to get at all device capabilities, as long as a plugin has been created to provide that functionality.
2. A PWA cannot be discovered through app stores; if you want to build an app that can be discovered through an app store, you’d want to use Cordova to create that app. Note: The Microsoft Edge team is exploring how PWAs could be listed through the Windows Store.
3. Mobile platform support for PWAs are currently limited; neither iOS nor Windows devices currently support the PWA model, only recent versions of Android and Chrome provide support. As of this writing, you can use PWAs with the Chrome browser and as an experimental feature in Firefox and Opera web browsers. Microsoft Edge has also announced work to support PWAs going forward. If you want to reach the broadest sets of end users across all the major device manufacturers and form factors, you’ll want to stick with Cordova for now.

Using Apache Cordova, can I use native features such as push notifications?

Yes! Using plugins with Apache Cordova, you can use a variety of native device features. Plugins exist for device features such as the camera, battery status, and push notifications. You can find a wide variety of plugins for the most common device features by searching the Cordova plugin repository. To work with push notifications, specifically, you can read about how to add push notifications to your Cordova app using Azure App Services.

In creating a plugin, the author provides:

• A single JavaScript API that can be used across all supported platforms.
• The native code implementation for each supported platform (e.g. Swift code for iOS, Java for Android, and C# for Windows).

Our team at Microsoft is helping to make sure that the plugins most important to business are working well; while an active community of Cordova developers work on building out other features. We make sure that the core/most important plugins are working well on Android, iOS, and Windows devices, so long as those platforms support the technology.

How can I make a mobile app that will live for 5-10 years?

I know there are projects I’ve worked on in the past where we were building a solution that was expected to last 5 or more years with relatively little maintenance required from a developer team. I’ve heard from many of you that have had similar experiences and the question has come up if you can make a mobile app that would last this long. If you’ve built a mobile web application that can last this long, then you certainly build that same app as a mobile application using Cordova.

My answer is different if you’re building a more complex application with multiple screens that accesses native device features and works with 3^rd party services for features like push notifications. For this type of application, you’d need to not only design for the devices available today, but have an eye toward where you think devices will be in those 5-10 years. How will the UI behave on these future devices and what device features will still be supported? You’d also need to select services that you know can still be rely on in the future. I think for many of us, these future requirements would be too hard for us to predict.

During our mobile panel discussion at the Microsoft Ignite conference, we generally agreed that it’s not possible to predict the future of mobile apps this far out whether you’re using Cordova, Xamarin, Objective-C, Swift, Java or something else. Instead, you should focus on building a service layer that can scale to support future requirements and mobile device changes. For example, instead of coding business logic into the application directly, create a backend service layer that is called by the application (e.g. via RESTful APIs) to handle that same logic. Then, as your application needs change over time, or new mobile apps are created, your existing service layer can still be used by those apps without having to modify that code.

In support of the service layer of your app, you may want to consider the following Microsoft services to see how well they’d work for you:

• Setup a mobile backend using Azure App Services.
• Write and deploy test scripts to run on Xamarin Test Cloud.
• Distribute beta apps using HockeyApp.
• Automate your DevOps lifecycle using Visual Studio Team Services.

Have more questions? Share them with us!

While these are the most common questions I hear from developers, I suspect you have some more. Feel free to ask them in the comments below, or send us a direct email. If you have some questions about Cordova issues or best practice our visual-studio-cordova tag on Stack Overflow is also a great place to ask them. Also, be sure to check out documentation site to learn more about TACO!

Jordan Matthiesen (@JMatthiesen) Program Manager, Tools for Apache Cordova Jordan works at Microsoft on JavaScript tooling for web and mobile application developers. He’s been a developer for over 18 years, and currently focuses on talking to as many awesome mobile developers as possible. When not working on dev tools, you’ll find him enjoying quality time with his wife, 4 kids, 2 cats, 1 dog, and a really big cup of coffee.