Idontthinkso

Contents
Cross-Platform Mobile Development in Visual Studio

Visual Studio Tools for Xamarin
Visual Studio Tools for Apache Cordova
Visual Studio Tools for Unity
Get Started with Visual Studio Tools for Unity
Use Visual Studio Tools for Unity
Use .NET 4.x in Unity
Program Visual Studio Tools for Unity
Customize Project Files Created by VSTU
Share the Unity Log Callback with VSTU
Program with Unity and Azure
Troubleshooting and Known Issues (Visual Studio Tools for Unity)
Change Log (Visual Studio Tools for Unity, Windows)
Change Log (Visual Studio Tools for Unity, Mac)
DevOps with Unity Apps
Visual C++ for Cross-Platform Mobile Development
Install Visual C++ for Cross-Platform Mobile Development
Install And Configure Tools to Build using iOS
Create an Android Native Activity App
Build an OpenGL ES Application on Android and iOS
Import an XCode Project
Sync Changes Between XCode and Visual Studio
Cross-Platform Mobile Development Examples
C++ Cross-Platform Project Properties
General Project Properties (Android C++)
Android Debugger Properties
Clang Project Properties (Android C++)
General Project Properties (Android C++ Makefile)
Clang Linker Properties (Android C++)
NMake Properties (Android C++)
Develop apps for the Universal Windows Platform (UWP)
Visual Studio Emulator for Android
System Requirements for the Visual Studio Emulator for Android
Troubleshoot the Visual Studio Emulator for Android
Cross-platform mobile development in Visual Studio
1/9/2019 • 9 minutes to read • Edit Online
You can build apps for Android, iOS, and Windows devices by using Visual Studio. As you design your app, use
tools in Visual Studio to easily add connected services such as Office 365, Azure App Service, and Application
Insights.
Build your apps by using C# and the .NET Framework, HTML and JavaScript, or C++. Share code, strings, images,
and in some cases even the user interface.
If you want to build a game or immersive graphical app, install Visual Studio tools for Unity and enjoy all of the
powerful productivity features of Visual Studio with Unity, the popular cross-platform game/graphics engine and
development environment for apps that run on iOS, Android, Windows, and other platforms.
Build an app for Android, iOS, and Windows (.NET Framework)
With Visual Studio Tools for Xamarin, you can target Android, iOS, and Windows in the same solution, sharing
code and even UI.
LEARN MORE
Install Visual Studio (VisualStudio.com)
Learn about Xamarin in Visual Studio (VisualStudio.com)
Xamarin mobile app development documentation
DevOps with Xamarin apps
Learn about Universal Windows apps in Visual Studio (VisualStudio.com)
Learn about the similarities between Swift and C# (download.microsoft.com)
Target Android, iOS, and Windows from a single code base

You can build native apps for Android, iOS, and Windows by using C# or F# (Visual Basic is not supported at this
time). To get started, install Visual Studio 2017, select the Mobile Development with .NET option in the installer.
If you already have Visual Studio 2017 installed, re-run the Visual Studio Installer and select the same Mobile
Development with .NET option for Xamarin (as above).
When you're done, project templates appear in the New Project dialog box. The easiest way to find Xamarin
templates is to just search on "Xamarin."
Xamarin exposes the native functionality of Android, iOS, and Windows as .NET classes and methods. This means
your apps have full access to native APIs and native controls, and they're just as responsive as apps written in the
native platform languages.
After you create a project, you'll leverage all of the productivity features of Visual Studio. For example, you'll use a
designer to create your pages, and use IntelliSense to explore the native API's of the mobile platforms. When
you're ready to run your app and see how it looks, you can use the Android SDK emulator and run Windows apps
natively. You can also use tethered Android and Windows devices directly. For iOS projects, connect to a networked
Mac and start the iOS emulator from Visual Studio, or connect to a tethered device.
Design one set of pages that render across all devices by using Xamarin.Forms
Depending on the complexity of your apps design, you might consider building it by using Xamarin.Forms
templates in the Mobile Apps group of project templates. Xamarin.Forms is a UI toolkit that lets you create a
single interface that you can share across Android, iOS, and Windows. When you compile a Xamarin.Forms
solution, you'll get an Android app, an iOS app, and a Windows app. For more details, see Learn about mobile
development with Xamarin and the Xamarin.Forms documentation.
Share code between Android, iOS, and Windows apps
If you're not using Xamarin.Forms and choose to design for each platform individually, you can share most of your
non-UI code between platform projects (Android, iOS, and Windows). This includes any business logic, cloud
integration, database access, or any other code that targets the .NET Framework. The only code that you can't share
is code that targets a specific platform.
You can share your code by using a shared project, a Portable Class Library project, or both. You might find that
some code fits best in a shared project, and some code makes more sense inside a Portable Class Library project.
LEARN MORE
Sharing Code Options (Xamarin)
Code sharing options with .NET
Target Windows 10 devices
If you want to create a single app that targets the full breadth of Windows 10 devices, create a universal Windows
app. You'll design the app by using a single project and your pages will render properly no matter what device is
used to view them.
Start with a Universal Windows Platform (UWP ) app project template. Design your pages visually, and then open
them in a preview window to see how they appear for various types of devices. If you don't like how a page
appears on a device, you can optimize the page to better fit the screen size, resolution, or various orientations such
as landscape or portrait mode. You can do all of that by using intuitive tool windows and easily accessible menu
options in Visual Studio. When you're ready to run your app and step through your code, you'll find all of the
device emulators and simulators for different types of devices together in one drop-down list that is located on the
Standard toolbar.
LEARN MORE
Intro to the Universal Windows Platform
Create your first app
Develop apps for the Universal Windows Platform (UWP)
Migrate apps to the Universal Windows Platform (UWP)
Build an app for Android, iOS, and Windows (HTML/JavaScript)
If you're a web developer, and you're familiar with HTML and JavaScript, you can target Windows, Android, and
iOS by using Visual Studio Tools for Apache Cordova. These apps can target all three platforms and you can build
them by using the skills and processes that you're most familiar with.
Apache Cordova is a framework that includes a plug-in model. This plug-in model provides a single JavaScript API
that you can use to access the native device capabilities of all three platforms (Android, iOS, and Windows).
Because these APIs are cross-platform, you can share most of what you write between all three platforms. This
reduces your development and maintenance costs. Also, there's no need to start from scratch. If you've created
other types of web applications, you can share those files with your Cordova app without having to modify or
redesign them in any way.
To get started, install Visual Studio 2017 and choose the Mobile Development with Javascript feature during
setup. The Cordova tools automatically install all third-party software that's required to build your multi-platform
app.
After you've installed the extension, open Visual Studio and create a Blank App (Apache Cordova) project. Then,
you can develop your app by using JavaScript or Typescript. You can also add plug-ins to extend the functionality
of your app, and APIs from plug-ins appear in IntelliSense as you write code.
When you're ready to run your app and step through your code, choose an emulator, such as the Apache Ripple
emulator or Android Emulator, a browser, or a device that you've connected directly to your computer. Then, start
your app. If you're developing your app on a Windows PC, you can even run it on that. All of these options are built
into Visual Studio as part of the Visual Studio Tools for Apache Cordova.
Project templates for creating Universal Windows Platform (UWP ) apps are still available in Visual Studio so feel
free to use them if you plan to target only Windows devices. If you decide to target Android and iOS later, you can
always port your code to a Cordova project.
LEARN MORE
Install Visual Studio (VisualStudio.com)
Get started with Visual Studio Tools for Apache Cordova
Learn about the Visual Studio Emulator for Android (VisualStudio.com)
Build an app for Android and Windows (C++)
First, install Visual Studio 2017 and the Mobile Development with C++ workload. Then, you can build a native
activity application for Android or an app that targets Windows. C++ templates that target iOS are not yet
available. You can target Android and Windows in the same solution if you want, and then share code between
them by using a cross-platform static or dynamic shared library.
If you need to build an app for Android that requires any sort of advanced graphics manipulation, such as a game,
you can use C++ to do it. Start with the Native-Activity Application (Android) project. This project has full
support for the Clang toolchain.
When you're ready to run your app and see how it looks, use the Android Emulator. It's fast, reliable, and easy to
install and configure.
You can also build an app that targets the full breadth of Windows 10 devices by using C++ and a Universal
Windows Platform (UWP ) app project template. Read more about this in the Target Windows 10 devices section
that appears earlier in this topic.
You can share C++ code between Android and Windows by creating a static or dynamic shared library.
You can consume that library in a Windows or Android project, like the ones described earlier in this section. You
can also consume it in an app that you build by using Xamarin, Java, or any language that lets you invoke functions
in an unmanaged DLL.
As you write code in these libraries, you can use IntelliSense to explore the native APIs of the Android and
Windows platforms. These library projects are fully integrated with the Visual Studio debugger so you can set
breakpoints, step through code, and find and fix issues by using all of the advanced features of the debugger.
LEARN MORE
Download Visual Studio. (VisualStudio.com)
Install the Visual C++ for Cross-Platform Mobile Development tools. (MSDN Library)
Learn more about using C++ to target multiple platforms. (VisualStudio.com)
Install what you need, and then create a native activity application for Android (MSDN Library)
Learn more about sharing C++ code with Android and Windows apps (VisualStudio.com)
Cross-platform mobile development examples for C++ (MSDN Library)
Additional cross-platform mobile development examples for C++ (code.msdn)
Build a cross-platform game for Android, iOS, and Windows by using

Visual Studio tools for Unity
Visual Studio Tools for Unity is a free extension for Visual Studio that integrates Visual Studio's powerful code
editing, productivity, and debugging tools with Unity, the popular cross-platform gaming/graphics engine and
development environment for immersive apps that target Windows, iOS, Android, and other platforms including
the web.
With Visual Studio Tools for Unity (VSTU ), you can use Visual Studio to write game and editor scripts in C# and
then use its powerful debugger to find and fix errors. The latest release of VSTU brings support for Unity 2018.1
and includes syntax coloring for Unity's ShaderLab shader language, better synchronization with Unity, richer
debugging, and improved code generation for the MonoBehavior wizard. VSTU also brings your Unity project
files, console messages, and the ability to start your game into Visual Studio so you can spend less time switching
to and from the Unity Editor while writing code.
LEARN MORE
Learn more about building Unity games with Visual Studio
Read more about Visual Studio Tools for Unity
Start using Visual Studio Tools for Unity
Read about the latest enhancements to the Visual Studio Tools for Unity 2.0 Preview (Visual Studio blog)
Watch a video introduction to the Visual Studio Tools for Unity 2.0 Preview (Video)
Learn about Unity (Unity website)
See Also
Add Office 365 APIs to a Visual Studio project
Azure App Services - Mobile Apps
Visual Studio App Center
Visual Studio Tools for Unity
Visual Studio Tools for Unity is a free Visual Studio extension that turns Visual Studio into a powerful tool for
developing cross-platform games and apps with Unity.
While the Unity editor is great for putting your game world together, you can't write your code in it. With Visual
Studio Tools for Unity, you can use the familiar code editing, debugging and productivity features of Visual Studio
to create editor and game scripts for your Unity project using C#, and you can debug them using Visual Studio's
powerful debugging capabilities.
But Visual Studio Tools for Unity is more than that; it also has deep integration with Unity editor so that you'll
spend less time switching back and forth to do simple tasks, provides Unity-specific productivity enhancements,
and puts the Unity documentation at your fingertips.
Overview
Visit the Build Unity Games with Visual Studio page for an overview of the advantages of using Visual Studio for
Unity development, or continue below to dig deeper into the key features of Visual Studio Tools for Unity:
Compatible with Visual Studio Community and bundled with Unity
Visual Studio Community is available for free, and is bundled with Unity installs starting with Unity 2018.1. See the
Visual Studio Tools for Unity getting started documentation for more information.
IntelliSense for Unity messages
IntelliSense code-completion makes it fast and easy to implement Unity API messages like OnCollisionEnter ,
including their parameters.
Superior debugging
Visual Studio Tools for Unity supports the robust debugging features that you expect from Visual Studio:
Set breakpoints, including conditional breakpoints.
Evaluate complex expressions in the Watch window.
Inspect and modify the value of variables and arguments.
Drill down into complex objects and data structures.
Visual Studio for Mac Tools for Unity
Visual Studio for Mac also supports Unity projects. For more information, see the Visual Studio for Mac Tools for
Unity documentation.
Next steps
Get started with Visual Studio Tools for Unity
Get started with Visual Studio Tools for Unity
Install Visual Studio

Unity bundled installation
Starting with Unity 2018.1, Visual Studio is the default C# script editor for Unity, and is included in the Unity
Download Assistant, as well as the Unity Hub installation tool.
Download Unity from store.unity.com.
During installation, ensure that Visual Studio is checked in the list of components to install with Unity:
Unity Hub
Unity Download Assistant

Check for updates to Visual Studio
The version of Visual Studio included with your Unity installation may not be the latest. It is recommended to
check for updates to ensure you have access to the latest tools and features.
Update Visual Studio
Manual installation
If you already have Visual Studio 2017 installed, or prefer to manually install, run the Visual Studio installer.
1. Download the Visual Studio installer, or open it if already installed.
2. Click Modify (if already installed) or Install (for new installations) for your desired version of Visual Studio.
3. On the Workloads tab, scroll to the Mobile & Gaming section and select the Game development with
Unity workload.
4. Click Modify (if already installed) or Install (for new installations) in the bottom-right corner of the
installer window.
Configure Unity for use with Visual Studio

Starting with Unity 2018.1, Visual Studio should be the default external script editor in Unity. You can confirm this
or change the external script editor to a specific version of Visual Studio:
1. Select Preferences from the Edit menu.
2. In the Preferences dialog, select the External Tools tab.
3. From the External Script Editor dropdown list, choose your desired version of Visual Studio if it is listed,
otherwise select Browse....
4. If Browse... was selected, navigate to the Common7/IDE directory inside your Visual Studio installation
directory and select devenv.exe. Then click Open.
5. Once Visual Studio is selected in the External Script Editor list, confirm that the Editor Attaching
checkbox is selected.
6. Close the Preferences dialog to complete the configuration process.
Support for older versions

Download and install Visual Studio Tools for Unity from the Visual Studio Marketplace. You'll need to install the
right package for your version of Visual Studio.
For Visual Studio 2015 Community, Visual Studio 2015 Professional, or Visual Studio 2015 Enterprise:
Download Visual Studio 2015 Tools for Unity
NOTE
Visual Studio Tools for Unity requires Unity 5.2 and above, as well as a version of Visual Studio that supports extensions,
such as Visual Studio Community, Professional, Premium, or Enterprise. To verify that Visual Studio Tools for Unity are
enabled in your installation of Unity, select About Unity from the Help menu and look for the text "Microsoft Visual Studio
Tools for Unity enabled" in the bottom-left of the dialog.
Next steps
To learn how to work with and debug your Unity project in Visual Studio, see Visual Studio Tools for Unity.
Use Visual Studio Tools for Unity
In this section, you'll learn how to use Visual Studio Tools for Unity's integration and productivity features, and
how to use the Visual Studio debugger for Unity development.
Open Unity scripts in Visual Studio

Once Visual Studio is set as the external script editor for Unity, opening any script from the Unity editor will
automatically launch or switch to Visual Studio with the chosen script open. Just double click a script in your Unity
project.
Alternatively, you can open Visual Studio with no script open in the source editor by selecting Open C# Project
from the Assets menu in Unity.
Unity documentation access

You can access the Unity scripting documentation quickly from Visual Studio. If Visual Studio Tools for Unity
doesn't find the API documentation locally, it will try to find it online.
In Visual Studio, highlight or place the cursor over the Unity API you want to learn about, then press
Ctrl+Alt+M, Ctrl+H
Intellisense for Unity API Messages

Intellisense code-completion makes it easy to implement Unity API messages in MonoBehaviour scripts, and
assists with learning the Unity API. To use IntelliSense for Unity messages:
1. Place the cursor on a new line inside the body of a class that derives from MonoBehaviour .
2. Begin typing the name of a Unity message, such as OnTriggerEnter .
3. Once the letters "ontri" have been typed, a list of IntelliSense suggestions appears.
4. The selection on the list can be changed in three ways:

With the Up and Down arrow keys.
By clicking with the mouse on the desired item.
By continuing to type the name of the desired item.
5. IntelliSense can insert the selected Unity message, including any necessary parameters:
By pressing Tab.
By pressing Enter.
By double-clicking the selected item.
Unity MonoBehavior scripting wizard
You can use the MonoBehavior wizard to view a list of all the Unity API methods and quickly implement an empty
definition. This feature, particularly with the Generate method comments option enabled, is helpful if you are
still learning what's available in the Unity API.
To create empty MonoBehavior method definitions with the MonoBehavior wizard:
1. In Visual Studio, position the cursor where you want the methods to be inserted, then press Ctrl+Shift+M
to launch the MonoBehavior wizard.
2. In the Create script methods window, mark the checkbox next to the name of each method you want to
add.
3. Use the Framework version dropdown to select your desired version.
4. By default, the methods are inserted at the position of the cursor. Alternatively, you can choose to insert
them after any method that's already implemented in your class by changing the value of the Insertion
point dropdown to the location you want.
5. If you want the wizard to generate comments for the methods you selected, mark the Generate method
comments checkbox. These comments are meant to help you understand when the method is called and
what its general responsibilities are.
6. Choose the OK button to exit the wizard and insert the methods into your code.
Unity Project Explorer
The Unity Project Explorer shows all of your Unity project files and directories in the same way that the Unity
Editor does. This is different than navigating your Unity scripts with the normal Visual Studio Solution Explorer,
which organizes them into projects and a solution generated by Visual Studio.
On the main Visual Studio menu, choose View > Unity Project Explorer. Keyboard shortcut:
Alt+Shift+E
Unity debugging
Visual Studio Tools for Unity lets you debug both editor and game scripts for your Unity project using Visual
Studio's powerful debugger.
Debug in the Unity editor
Start debugging
1. Connect Visual Studio to Unity by clicking the Play button labeled Attach to Unity, or use the keyboard
shortcut F5.
2. Switch to Unity and click the Play button to run the game in the editor.
3. When the game is running in the Unity editor while connected to Visual Studio, any breakpoints
encountered will pause execution of the game and bring up the line of code where the game hit the
breakpoint in Visual Studio.
Stop debugging
Click the Stop button in Visual Studio, or use the keyboard shortcut Shift + F5.
To learn more about debugging in Visual Studio, see First look at the Visual Studio Debugger.
Attach to Unity and Play
For added convenience, you can change the Attach to Unity button to Attach to Unity and Play mode.
1. Click the small down arrow next to the Attach to Unity button.
2. Select Attach to Unity and Play from the dropdown menu.
The play button becomes labeled Attach to Unity and Play. Clicking this button or using the keyboard shortcut
F5 now automatically switches to the Unity editor and runs the game in the editor, in addition to attaching the
Visual Studio debugger.
Clicking the Stop button in Visual Studio or using the keyboard shortcut Shift+F5 will automatically stop the
game in the Unity editor.
Debug Unity player builds
You can debug development builds of various Unity players with Visual Studio.
Enable script debugging in a Unity player
1. In Unity, open the Build Settings by selecting File > Build Settings.
2. In the Build Settings window, mark the Development Build and Script Debugging checkboxes.
Select a Unity instance to attach the debugger to

In Visual Studio, on the main menu, choose Debug > Attach Unity Debugger.
The Select Unity Instance dialog displays some information about each Unity instance that you can
connect to.
Project
The name of the Unity project that's running in this instance of Unity.
Machine The name of the computer or device that this instance of Unity is running on.
Type Editor if this instance of Unity is running as part of the Unity Editor; Player if this instance of Unity is
a stand-alone player.
Port The port number of the UDP socket that this instance of Unity is communicating over.
IMPORTANT
Because Visual Studio Tools for Unity and the Unity instance are communicating over a UDP network socket, your firewall
might ask about it. If this happens, you'll have to authorize the connection so that VSTU and Unity can communicate.
Debug a DLL in your Unity project

Many Unity developers are writing code components as external DLLs so that the functionality they develop can
be easily shared with other projects. Visual Studio Tools for Unity makes it easy to debug code in these DLLs
seamlessly with other code in your Unity project.
NOTE
At this time, Visual Studio Tools for Unity only supports managed DLLs. It does not support debugging of native code DLLs,
such as those written in C++.
Note that the scenario described here assumes that you have the source code—that is, you are developing or re-
using your own first-party code, or you have the source code to a third-party library, and plan to deploy it in your
Unity project as a DLL. This scenario does not describe debugging a DLL for which you do not have the source
code.
To debug a managed DLL project used in your Unity project
1. Add your existing DLL project to the Visual Studio solution generated by Visual Studio Tools for Unity. Less
commonly, you might be starting a new managed DLL project to contain code components in your Unity
project; if that's the case, you can add a new managed DLL project to the Visual Studio solution instead. For
more information on adding a new or existing project to a solution, see How to: Add Projects to a Solution.
In either case, Visual Studio Tools for Unity maintains the project reference, even if it has to regenerate the
project and solution files again, so you only need to perform these steps once.
2. Reference the correct Unity framework profile in the DLL project. In Visual Studio, in the DLL project's
properties, set the Target framework property to the Unity framework version you're using. This is the
Unity Base Class Library that matches the API compatibility that your project targets, such as the Unity full,
micro, or web base class libraries. This prevents your DLL from calling framework methods that exist in
other frameworks or compatibility levels, but which might not exist in the Unity framework version you're
using.
3. Copy the DLL to your Unity project's Asset folder. In Unity, assets are files that are packaged and deployed
together with your Unity app so that they can be loaded at run-time. Since DLLs are linked at runtime, DLLs
must be deployed as assets. To be deployed as an asset, the Unity Editor requires the DLLs to be put inside
the Assets folder in your Unity project. There are two ways you can do this:
Modify the build settings of your DLL project to include a post-built task that copies the output DLL
and PDB files from its output folder to the Assets folder of your Unity project.
Modify the build settings of your DLL project to set its output folder to be the Assets folder of your
Unity project. Both DLL and PDB files will be placed in the Assets folder.
The PDB files are needed for debugging because they contain the DLL's debugging symbols, and map the
DLL code to its source code form. Visual Studio Tools for Unity will use information from the DLL and PDB
to create a DLL.MDB file, which is the debug symbol format used by the Unity scripting engine.
4. Debug your code. You can now debug your DLL source code together with your Unity project's source code,
and use all the debugging features you are used to, such as breakpoints and stepping through code.
Keyboard shortcuts
You can quickly access the Unity Tools for Visual Studio functionality by using their keyboard shortcuts. Here's a
summary of the shortcuts that are available.
COMMAND SHORTCUT SHORTCUT COMMAND NAME
Open the MonoBehavior Wizard Ctrl+Shift+M EditorContextMenus.CodeWindow.I

mplementMonoBehaviours
Open the Unity Project Explorer Alt+Shift+E View.UnityProjectExplorer

COMMAND SHORTCUT SHORTCUT COMMAND NAME
Access Unity documentation Ctrl+Alt+M, Ctrl+H Help.UnityAPIReference
Attach to Unity debugger (player or no default Debug.AttachUnityDebugger

editor)
You can change the shortcut key combinations if you don't like the default. For information on how to change it,
see Identify and customize keyboard shortcuts in Visual Studio.
Using .NET 4.x in Unity
C# and .NET, the technologies underlying Unity scripting, have continued to receive updates since Microsoft
originally released them in 2002. But Unity developers may not be aware of the steady stream of new features
added to the C# language and .NET Framework. That's because before Unity 2017.1, Unity has been using a .NET
3.5 equivalent scripting runtime, missing years of updates.
With the release of Unity 2017.1, Unity introduced an experimental version of its scripting runtime upgraded to a
.NET 4.6, C# 6 compatible version. In Unity 2018.1, the .NET 4.x equivalent runtime is no longer considered
experimental, while the older .NET 3.5 equivalent runtime is now considered to be the legacy version. And with the
release of Unity 2018.3, Unity is projecting to make the upgraded scripting runtime the default selection, and to
update even further to C# 7. For more information and the latest updates on this roadmap, read Unity's blog post
or visit their Experimental Scripting Previews forum. In the meantime, check out the sections below to learn more
about the new features available now with the .NET 4.x scripting runtime.
Prerequisites
Unity 2017.1 or above (2018.2 recommended)
Visual Studio 2017
Enabling the .NET 4.x scripting runtime in Unity

To enable the .NET 4.x scripting runtime, take the following steps:
1. Open PlayerSettings in the Unity Inspector by selecting Edit > Project Settings > Player.
2. Under the Configuration heading, click the Scripting Runtime Version dropdown and select .NET 4.x
Equivalent. You will be prompted to restart Unity.
Choosing between .NET 4.x and .NET Standard 2.0 profiles

Once you've switched to the .NET 4.x equivalent scripting runtime, you can specify the Api Compatibility Level
using the dropdown menu in the PlayerSettings (Edit > Project Settings > Player). There are two options:
.NET Standard 2.0. This profile matches the .NET Standard 2.0 profile published by the .NET Foundation.
Unity recommends .NET Standard 2.0 for new projects. It's smaller than .NET 4.x, which is advantageous for
size-constrained platforms. Additionally, Unity has committed to supporting this profile across all platforms
that Unity supports.
.NET 4.x. This profile provides access to the latest .NET 4 API. It includes all of the code available in the
.NET Framework class libraries and supports .NET Standard 2.0 profiles as well. Use the .NET 4.x profile if
your project requires part of the API not included in the .NET Standard 2.0 profile. However, some parts of
this API may not be supported on all of Unity's platforms.
You can read more about these options in Unity's blog post.
Adding assembly references when using the .NET 4.x Api Compatibility Level
When using the .NET Standard 2.0 setting in the Api Compatibility Level dropdown, all assemblies in the API
profile are referenced and usable. However, when using the larger .NET 4.x profile, some of the assemblies that
Unity ships with aren't referenced by default. To use these APIs, you must manually add an assembly reference. You
can view the assemblies Unity ships with in the MonoBleedingEdge/lib/mono directory of your Unity editor
installation:
For example, if you're using the .NET 4.x profile and want to use HttpClient , you must add an assembly reference
for System.Net.Http.dll. Without it, the compiler will complain that you're missing an assembly reference:
Visual Studio regenerates .csproj and .sln files for Unity projects each time they're opened. As a result, you cannot
add assembly references directly in Visual Studio because they'll be lost upon reopening the project. Instead, a
special text file named mcs.rsp must be used:
1. Create a new text file named mcs.rsp in your Unity project's root Assets directory.
2. On the first line in the empty text file, enter: -r:System.Net.Http.dll and then save the file. You can replace
"System.Net.Http.dll" with any included assembly that might be missing a reference.
3. Restart the Unity editor.
Taking advantage of .NET compatibility

In addition to new C# syntax and language features, the .NET 4.x scripting runtime gives Unity users access to a
huge library of .NET packages that are incompatible with the legacy .NET 3.5 scripting runtime.
Add packages from NuGet to a Unity project
NuGet is the package manager for .NET. NuGet is integrated into Visual Studio. However, Unity projects require a
special process to add NuGet packages. This is because when you open a project in Unity, its Visual Studio project
files are regenerated, undoing necessary configurations. To add a package from NuGet to your Unity project do the
following:
1. Browse NuGet to locate a compatible package you'd like to add (.NET Standard 2.0 or .NET 4.x). This
example will demonstrate adding Json.NET, a popular package for working with JSON, to a .NET Standard
2.0 project.
2. Click the Download button:
3. Locate the downloaded file and change the extension from .nupkg to .zip.
4. Within the zip file, navigate to the lib/netstandard2.0 directory and copy the Newtonsoft.Json.dll file.
5. In your Unity project's root Assets folder, create a new folder named Plugins. Plugins is a special folder
name in Unity. See the Unity documentation for more information.
6. Paste the Newtonsoft.Json.dll file into your Unity project's Plugins directory.
7. Create a file named link.xml in your Unity project's Assets directory and add the following XML. This will
ensure Unity's bytecode stripping process does not remove necessary data when exporting to an IL2CPP
platform. While this step is specific to this library, you may run into problems with other libraries that use
Reflection in similar ways. For more information, please see Unity's docs on this topic.
<linker>
<assembly fullname="System.Core">
<type fullname="System.Linq.Expressions.Interpreter.LightLambda" preserve="all" />
</assembly>
</linker>
With everything in place, you can now use the Json.NET package.
using Newtonsoft.Json;
using UnityEngine;
public class JSONTest : MonoBehaviour

{
class Enemy
{
public string Name { get; set; }
public int AttackDamage { get; set; }
public int MaxHealth { get; set; }
}
private void Start()
{
string json = @"{
'Name': 'Ninja',
'AttackDamage': '40'
}";
var enemy = JsonConvert.DeserializeObject<Enemy>(json);
Debug.Log($"{enemy.Name} deals {enemy.AttackDamage} damage.");

// Output:
// Ninja deals 40 damage.
}
}
This is a simple example of using a library which has no dependencies. When NuGet packages rely on other NuGet
packages, you would need to download these dependencies manually and add them to the project in the same way.
New syntax and language features

Using the updated scripting runtime gives Unity developers access to C# 6 and a host of new language features
and syntax.
Auto -property initializers
In Unity's .NET 3.5 scripting runtime, the auto-property syntax makes it easy to quickly define uninitialized
properties, but initialization has to happen elsewhere in your script. Now with the .NET 4.x runtime, it's possible to
initialize auto-properties in the same line:
// .NET 3.5
public int Health { get; set; } // Health has to be initialized somewhere else, like Start()
// .NET 4.x
public int Health { get; set; } = 100;
String interpolation
With the older .NET 3.5 runtime, string concatenation required awkward syntax. Now with the .NET 4.x runtime,
the $ string interpolation feature allows expressions to be inserted into strings in a more direct and readable
syntax:
// .NET 3.5
Debug.Log(String.Format("Player health: {0}", Health)); // or
Debug.Log("Player health: " + Health);
// .NET 4.x
Debug.Log($"Player health: {Health}");
Expression-bodied members
With the newer C# syntax available in the .NET 4.x runtime, lambda expressions can replace the body of functions
to make them more succinct:
// .NET 3.5
private int TakeDamage(int amount)
{
return Health -= amount;
}
// .NET 4.x
private int TakeDamage(int amount) => Health -= amount;
You can also use expression-bodied members in read-only properties:
// .NET 4.x
public string PlayerHealthUiText => $"Player health: {Health}";
Task-based Asynchronous Pattern (TAP)

Asynchronous programming allows time consuming operations to take place without causing your application to
become unresponsive. This functionality also allows your code to wait for time consuming operations to finish
before continuing with code that depends on the results of these operations. For example, you could wait for a file
to load or a network operation to complete.
In Unity, asynchronous programming is typically accomplished with coroutines. However, since C# 5, the preferred
method of asynchronous programming in .NET development has been the Task-based Asynchronous Pattern (TAP )
using the async and await keywords with System.Threading.Task. In summary, in an async function you can
await a task's completion without blocking the rest of your application from updating:
// Unity coroutine
using UnityEngine;
public class UnityCoroutineExample : MonoBehaviour
{
{
StartCoroutine(WaitOneSecond());
DoMoreStuff(); // This executes without waiting for WaitOneSecond
}
private IEnumerator WaitOneSecond()
{
yield return new WaitForSeconds(1.0f);
Debug.Log("Finished waiting.");
}
}
// .NET 4.x async-await
using UnityEngine;
using System.Threading.Tasks;
public class AsyncAwaitExample : MonoBehaviour
{
private async void Start()
{
Debug.Log("Wait.");
await WaitOneSecondAsync();
DoMoreStuff(); // Will not execute until WaitOneSecond has completed
}
private async Task WaitOneSecondAsync()
{
await Task.Delay(TimeSpan.FromSeconds(1));
Debug.Log("Finished waiting.");
}
}
TAP is a complex subject, with Unity-specific nuances developers should consider. As a result, TAP isn't a universal
replacement for coroutines in Unity; however, it is another tool to leverage. The scope of this feature is beyond this
article, but some general best practices and tips are provided below.
Getting started reference for TAP with Unity
These tips can help you get started with TAP in Unity:
Asynchronous functions intended to be awaited should have the return type Task or Task<TResult> .
Asynchronous functions that return a task should have the suffix "Async" appended to their names. The
"Async" suffix helps indicate that a function should always be awaited.
Only use the async void return type for functions that fire off async functions from traditional synchronous
code. Such functions cannot themselves be awaited and shouldn't have the "Async" suffix in their names.
Unity uses the UnitySynchronizationContext to ensure async functions run on the main thread by default. The
Unity API isn't accessible outside of the main thread.
It's possible to run tasks on background threads with methods like Task.Run and Task.ConfigureAwait(false) .
This technique is useful for offloading expensive operations from the main thread to enhance performance.
However, using background threads can lead to problems that are difficult to debug, such as race conditions.
The Unity API isn't accessible outside the main thread.
Tasks that use threads aren't supported on Unity WebGL builds.
Differences between coroutines and TAP
There are some important differences between coroutines and TAP / async-await:
Coroutines cannot return values, but Task<TResult> can.
You cannot put a yield in a try-catch statement, making error handling difficult with coroutines. However, try-
catch works with TAP.
Unity's coroutine feature isn't available in classes that don't derive from MonoBehaviour. TAP is great for
asynchronous programming in such classes.
At this point, Unity doesn't suggest TAP as a wholesale replacement of coroutines. Profiling is the only way to
know the specific results of one approach versus the other for any given project.
NOTE
As of Unity 2018.2, debugging async methods with break points isn't fully supported; however, this functionality is expected
in Unity 2018.3.
nameof operator
The nameof operator gets the string name of a variable, type, or member. Some cases where nameof comes in
handy are logging errors, and getting the string name of an enum:
// Get the string name of an enum:

enum Difficulty {Easy, Medium, Hard};
{
Debug.Log(nameof(Difficulty.Easy));
RecordHighScore("John");
// Output:
// Easy
// playerName
}
// Validate parameter:
private void RecordHighScore(string playerName)
{
Debug.Log(nameof(playerName));
if (playerName == null) throw new ArgumentNullException(nameof(playerName));
}
Caller info attributes

Caller info attributes provide information about the caller of a method. You must provide a default value for each
parameter you want to use with a Caller Info attribute:
private void Start ()

{
ShowCallerInfo("Something happened.");
}
public void ShowCallerInfo(string message,
[System.Runtime.CompilerServices.CallerMemberName] string memberName = "",
[System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "",
[System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
{
Debug.Log($"message: {message}");
Debug.Log($"member name: {memberName}");
Debug.Log($"source file path: {sourceFilePath}");
Debug.Log($"source line number: {sourceLineNumber}");
}
// Output:
// Something happened
// member name: Start
// source file path: D:\Documents\unity-scripting-upgrade\Unity Project\Assets\CallerInfoTest.cs
// source line number: 10
Using static
Using static allows you to use static functions without typing its class name. With using static, you can save space
and time if you need to use several static functions from the same class:
// .NET 3.5
using UnityEngine;
public class Example : MonoBehaviour
{
{
Debug.Log(Mathf.RoundToInt(Mathf.PI));
// Output:
// 3
}
}
// .NET 4.x
using UnityEngine;
using static UnityEngine.Mathf;
public class UsingStaticExample: MonoBehaviour
{
{
Debug.Log(RoundToInt(PI));
// Output:
// 3
}
}
IL2CPP Considerations
When exporting your game to platforms like iOS, Unity will use its IL2CPP engine to "transpile" IL to C++ code
which is then compiled using the native compiler of the target platform. In this scenario, there are several .NET
features which are not supported, such as parts of Reflection, and usage of the dynamic keyword. While you can
control using these features in your own code, you may run into problems using 3rd party DLLs and SDKs which
were not written with Unity and IL2CPP in mind. For more information on this topic, please see the Scripting
Restrictions docs on Unity's site.
Additionally, as mentioned in the Json.NET example above, Unity will attempt to strip out unused code during the
IL2CPP export process. While this typically isn't an issue, with libraries that use Reflection, it can accidentally strip
out properties or methods that will be called at runtime that can't be determined at export time. To fix these issues,
add a link.xml file to your project which contains a list of assemblies and namespaces to not run the stripping
process against. For full details, please see Unity's docs on bytecode stripping.
.NET 4.x Sample Unity Project

The sample contains examples of several .NET 4.x features. You can download the project or view the source code
on GitHub.
Additional resources
Unity Blog - Scripting Runtime Improvements in Unity 2018.2
History of C#
What's New in C# 6
Asynchronous programming in Unity, Using Coroutine and TAP
Async-Await Instead of Coroutines in Unity 2017
Unity Forum - Experimental Scripting Previews
Program Visual Studio Tools for Unity
In this section, you'll find examples for using the Visual Studio Tools for Unity API.
Examples
Here are some examples that show how you can use the Visual Studio Tools for Unity APIs.
Customize project files created by VSTU
Visual Studio Tools for Unity provides a Unity-style callback during project file generation. To learn how you can
modify the project file whenever it's regenerated, see Example: Project file generation.
Share the Unity log callback with VSTU
Visual Studio Tools for Unity registers a log callback with Unity to be able to stream its console to Visual Studio. If
your editor scripts also register a log callback with Unity, the VSTU callback might interfere with it. To learn how
you can share the Unity log callback with VSTU, see Example: Log callback.
Customize project files created by VSTU
Visual Studio Tools for Unity provides a Unity-style callback during project file generation. Register with the
VisualStudioIntegration.ProjectFileGeneration event to modify the project file whenever it's regenerated.
Demonstrates
How to customize the Visual Studio project files generated by Visual Studio Tools for Unity.
Example
#if ENABLE_VSTU
using System;
using System.IO;
using System.Linq;
using System.Text;
using System.Xml.Linq;
using UnityEngine;
using UnityEditor;
using SyntaxTree.VisualStudio.Unity.Bridge;
[InitializeOnLoad]
public class ProjectFileHook
{
// necessary for XLinq to save the xml project file in utf8
class Utf8StringWriter : StringWriter
{
public override Encoding Encoding
{
get { return Encoding.UTF8; }
}
}
static ProjectFileHook()
{
ProjectFilesGenerator.ProjectFileGeneration += (string name, string content) =>
{
// parse the document and make some changes
var document = XDocument.Parse(content);
document.Root.Add(new XComment("FIX ME"));
// save the changes using the Utf8StringWriter

var str = new Utf8StringWriter();
document.Save(str);
return str.ToString();
};
}
}
#endif
See also
Example: Log callback
Share the Unity log callback with VSTU
Visual Studio Tools for Unity registers a log callback with Unity to be able to stream its console to Visual Studio. If
your editor scripts also register a log callback with Unity, the VSTU callback might interfere with your callback. To
prevent this possibility, use the VisualStudioIntegration.LogCallback event to cooperate with VSTU.
Demonstrates
How to share the Unity Log Callback created by Visual Studio Tools for Unity.
Example
#if ENABLE_VSTU
using System;
using UnityEngine;
using UnityEditor;
using SyntaxTree.VisualStudio.Unity.Bridge;
[InitializeOnLoad]
public class LogCallbackHook
{
static LogCallbackHook()
{
VisualStudioIntegration.LogCallback += (string condition, string trace, LogType type) =>
{
// place code that implements your log callback here
};
}
}
#endif
See also
Example: Project file generation
Program with Unity and Azure
Azure provides a scalable solution to storing telemetry and other game data in the cloud. With the release of Unity
2017, Unity's experimental support for .NET 4.6 makes Azure integration simpler than ever by allowing use of
Azure .NET SDKs.
Experimental Azure SDKs

NOTE
These SDKs are unsupported, but provided to help customers try out Unity's experimental .NET 4.6 support.
Visit The Sandbox to try the following experimental Azure SDKs with Unity:
Azure Storage SDK for Unity
Azure Event Hubs SDK for Unity
Azure Mobile Apps SDK for Unity
Azure SDK sample

There is also a simple sample game using the Azure Easy Tables SDK and Unity. The game uses Azure Easy Tables
data storage to track the high score leaderboard and store in-game telemetry, and is available for download from
GitHub.
Troubleshooting and known issues (Visual Studio
Tools for Unity)
In this section, you'll find solutions to common issues with Visual Studio Tools for Unity, descriptions of known
issues, and learn how you can help improve Visual Studio Tools for Unity by reporting errors.
Troubleshooting the connection between Unity and Visual Studio

Confirm Editor Attaching is enabled
In the Unity Menu, select Edit > Preferences and then select the External Tools tab. Confirm that the Editor
Attaching checkbox is enabled. For more information, see the Unity Preferences documentation.
Unable to attach
Try to temporarily disable your antivirus or create exclusion rules for both VS and Unity.
Try to temporarily disable your firewall or create rules for allowing TCP/UDP networking between VS and
Unity.
Some programs, like Team Viewer, can interfere with process detection. You can try to temporarily stop any
extra software to see if it changes something.
Do not rename the main Unity executable, as VSTU is only monitoring "Unity.exe" processes.
Visual Studio crashes

This issue can be due to the Visual Studio MEF cache being corrupted.
Try removing the following folder to reset the MEF cache (close Visual Studio before doing this):
%localappdata%\Microsoft\VisualStudio\<version>\ComponentModelCache
This should fix your issue. In case you are still experiencing the problem, run a Developer Command Prompt for
Visual Studio as Administrator and use the following command:
devenv /setup
Visual Studio hangs

Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are
using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does
blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and
hang.
For FMOD, there is a workaround, you can pass FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE initialization flag to disable
asynchronous processing and perform all processing on the main thread.
Incompatible project in Visual Studio

First, check that Visual Studio is set as your external script editor in Unity (Edit/Preferences/External Tools). Then
check that the Visual Studio plugin is installed in Unity (Help/About must display a message like Microsoft Visual
Studio Tools for Unity is enabled at the bottom). Then check that the extension is properly installed in Visual Studio
(Help/About).
Extra reloads, or Visual Studio losing all open windows

Be sure to never touch project files directly from an asset processor or any other tool. If you really need to
manipulate the project file, we expose an API for that. Please check the Assembly references issues section.
If you experience extra reloads or if Visual Studio is losing all open Windows on reload, make sure that you have
proper .NET targeting packs installed. Check the following section about frameworks for more information.
The debugger does not break on exceptions

When using the legacy Unity runtime (.NET 3.5 equivalent), the debugger will always break when an exception is
unhandled (=outside a try/catch block). If the exception is handled, the debugger will use the Exception Settings
Window to determine if a break is required or not.
With the new runtime (.NET 4.6 equivalent), Unity introduced a new way for managing user exceptions and as a
result, all exceptions are seen as "user-handled" even if they are outside a try/catch block. That's why you now need
to explicitly check them in the Exception Settings Window if you want the debugger to break.
In the Exception Settings window (Debug > Windows > Exception Settings), expand the node for a category of
exceptions (for example, Common Language Runtime Exceptions, meaning .NET exceptions), and select the check
box for the specific exception you want to catch within that category (for example System.NullReferenceException).
You can also select an entire category of exceptions.
On Windows, Visual Studio asks to download the Unity target

framework
Visual Studio Tools for Unity requires the .NET framework 3.5, which isn't installed by default on Windows 8 or 10.
To fix this issue, follow the instructions to download and install the .NET framework 3.5.
When using the new Unity runtime, .NET targeting packs version 4.6 and 4.7.1 are also required. It is possible to
use the VS2017 installer to quickly install them (modify your VS2017 installation, individual components, .NET
category, select all 4.x targeting packs).
Assembly reference issues

If your project is complex reference-wise or if you want to better control this generation step, you can use our API
for manipulating the generated project or solution content. You can also use response files in your Unity project
and we'll process them.
Breakpoints with a warning

If Visual Studio is unable to find a source location for a specific breakpoint you will see a warning around your
breakpoint. Check that the script you are using is properly loaded/used in the current Unity scene.
Breakpoints not hit

Check that the script you are using is properly loaded/used in the current Unity scene. Quit both Visual Studio and
Unity then delete all generated files (*.csproj, *.sln) and the whole Library folder.
Unable to debug Android players

We use multicast for player detection (which is the default mechanism used by Unity), but after that we use a
regular TCP connection to attach the debugger. The detection phase is the main issue for Android devices.
Wifi is versatile but super slow compared to USB because of latency. We saw a lack of proper multicast support for
some routers or devices (Nexus series are well known for this).
USB is super-fast for debugging, and Visual Studio Tools for Unity is now able to detect USB devices, and talk to
the adb server to properly forward ports for debugging.
Issues with Visual Studio 2015 and IntelliSense or code coloration

Try upgrading your Visual Studio 2015 to update 3.
Known issues
There are known issues in Visual Studio Tools for Unity that result from how the debugger interacts with Unity's
older version of the C# compiler. We're working to help fix these problems, but you might experience the following
issues in the meantime:
When debugging, Unity sometimes crashes.
When debugging, Unity sometimes freezes.
Stepping into and out of methods sometimes behaves incorrectly, especially in iterators or within switch
statements.
Report errors
Please help us improve the quality of Visual Studio Tools for Unity by sending error reports when you experience
crashing, freezes, or other errors. This helps us investigate and fix problems in Visual Studio Tools for Unity. Thank
you!
How to report an error when Visual Studio freezes
There are reports that Visual Studio sometimes freezes when debugging with Visual Studio Tools for Unity, but we
need more data to understand this problem. You can help us investigate by following the steps below.
To r e p o r t t h a t Vi su a l St u d i o fr e e z e s w h i l e d e b u g g i n g w i t h Vi su a l St u d i o To o l s fo r U n i t y
On Windows:
1. Open a new instance of Visual Studio.
2. Open the Attach to Process dialog. In the new instance of Visual Studio, on the main menu, choose Debug,
Attach to Process.
3. Attach the debugger to the frozen instance of Visual Studio. In the Attach to Process dialog, select the
frozen instance of Visual Studio from the Available Processes table, then choose the Attach button.
4. Pause the Debugger. In the new instance of Visual Studio, on the main menu, choose Debug, Break All, or
just press Ctrl+Alt+Break.
5. Create a thread-dump. In the Command window, enter the following command and press Enter:
Debug.ListCallStack /AllThreads /ShowExternalCode
You might need to make the Command window visible first. In Visual Studio, on the main menu, choose
View, Other Windows, Command Window.
On Mac:
1. Open a terminal and get the PID of Visual Studio for Mac:
ps aux | grep "[V]isual Studio.app"
2. Launch the lldb debugger:
lldb
3. Attach to the Visual Studio for Mac instance using the PID:
process attach --pid THE_PID_OF_THE_VSFM_PROCESS
4. Retrieve the stacktrace for all the threads:
bt all
Finally, send the thread-dump to vstusp@microsoft.com, along with a description of what you were doing when
Visual Studio became frozen.
Change log (Visual Studio Tools for Unity, Windows)
Visual Studio Tools for Unity change log.
3.9.0.3
Released November 28, 2018
Bug fixes
Integration:
Fixed project reloading and intellisense issues when adding or removing scripts located in the very first
project.
3.9.0.2
Bug fixes
Debugger:
Fixed a deadlock in the library used to communicate with Unity’s debugger engine, making Visual Studio
or Unity freeze, especially when hitting ‘Attach to Unity’ or restarting game.
3.9.0.1
Bug fixes
Integration:
Fixed Unity plugin activation when another default editor was selected.
3.9.0.0
Bug fixes
Project Generation:
Rolled back the workaround for a Unity performance bug that has been fixed by Unity.
3.8.0.7
Released September 20, 2018
Bug fixes
Debugger:
(Backported from 3.9.0.2) Fixed a deadlock in the library used to communicate with Unity’s debugger
engine, making Visual Studio or Unity freeze, especially when hitting ‘Attach to Unity’ or restarting game.
3.8.0.6
Released August 27, 2018
Bug fixes
Integration:
Fixed reloading of projects and solution.
3.8.0.5
Bug fixes
Integration:
Fixed project monitoring subscription disposal.
3.8.0.4
New Features
Evaluation:
Added support for pointer values.
Added support for generic methods.
Bug fixes
Integration:
Smart reload with multiple projects changed.
3.8.0.3
Released July 24, 2018
Bug fixes
Project Generation:
(Backported from 3.9.0.0) Rolled back the workaround for a Unity performance bug that has been fixed
by Unity.
3.8.0.2
Bug fixes
Project Generation:
Transient workaround for a Unity performance bug: cache MonoIslands when generating projects.
3.8.0.1
Released June 26, 2018
New Features
Debugging:
Added support for UserLog and UserBreak commands.
Added lazy type-load support (optimizing the network load and debugger response latency).
Bug fixes
Evaluation:
Improved binary-operator expression evaluation and method search.
3.8.0.0
Released May 30, 2018
New Features
Debugging:
Added support for displaying variables in async constructs.
Added support for processing nested types when setting breakpoints, to prevent warnings with
compiler constructs.
Integration:
Added support for textmate grammars for Shaders (the C++ workload is no longer needed for Shader
code coloration).
Bug fixes
Project Generation:
Do not convert portable pdb to mdb anymore when using the new Unity runtime.
3.7.0.1
Bug fixes
Installer:
Fixed dependency issue when using experimental builds.
3.7.0.0
New Features
Debugging:
Added support for orchestrated debugging (debugging multiple players/editor with the same Visual
Studio session).
Added support for Android USB player debugging.
Added support for UWP/IL2CPP player debugging.
Evaluation:
Added support for hexadecimal specifiers.
Improved watch window evaluation experience.
Bug fixes
Integration:
Fixed usage of exception settings.
Project Generation:
Exclude package manager compilation units from generation.
3.6.0.5
Released March 13, 2018
New Features
Project Generation:
Added support for the new project generator in Unity 2018.1.
Bug fixes
Integration:
Fixed handling corrupted states with custom projects.
Debugger:
Fixed setting the next statement.
3.6.0.4
Bug fixes
Project Generation:
Fixed Mono version detection.
Integration:
Fixed timing issues with 2018.1 and plugin activation.
3.6.0.3
Released February 23, 2018
New Features
Project Generation:
Added support for .NET Standard.
Bug fixes
Project Generation:
Fixed Unity target framework detection.
Debugger:
Fixed breaking on exceptions that are thrown outside of usercode.
3.6.0.2
New Features
Integration:
Update UnityMessage API surface for 2017.3.
Bug fixes
Integration:
Only reload projects on external change (with throttling).
3.6.0.1
Released January 24, 2018
Bug fixes
Integration:
Fixed automatic pdb to mdb debug symbol conversion.
Fixed indirect call to EditorPrefs.GetBool impacting the inspector while trying to change array size.
3.6.0.0
New Features
Project Generation:
Added support for 2018.1 MonoIsland reference model.
Evaluation:
Added support for $exception identifier.
Debugger:
Added support for DebuggerHidden/DebuggerStepThrough attributes with the new Unity runtime.
Wizards:
Introduce 'Latest' version for wizards.
Bug fixes
Project Generation:
Fixed project guid computation for player projects.
Debugger:
Fixed a race in handling breaking events.
Wizards:
Refresh roslyn context before inserting method.
3.5.0.3
Bug fixes
Integration:
3.5.0.2
Released December 4, 2017
New Features
Integration:
Unity projects are now automatically reloaded in Visual Studio when you add or remove a script from
Unity.
Debugger:
Added an option to use the Mono debugger shared by Xamarin and Visual Studio for Mac to debug
the Unity Editor.
Added support for portable debug symbol files.
Bug fixes
Integration:
Fixed setup dependencies issues.
Fixed Unity API help menu not showing.
Project Generation:
Fixed player project generation when working on a UWP game with the IL2CPP/.NET 4.6 backend.
Fixed extra .dll extension wrongly added to the assembly filename.
Fixed usage of a specific project API compatibility level instead of the global one.
Do not force the AllowAttachedDebuggingOfEditor Unity flag as the default is now 'true'.
3.4.0.2
New Features
Project Generation:
Added support for assembly.json compilation units.
Stopped copying Unity assemblies to the project folder.
Debugger:
Added support for setting the next statement with the new Unity runtime.
Added support for Decimal type with the new Unity runtime.
Added support for implicit/explicit conversions.
Bug fixes
Evaluation:
Fixed array creation with implicit size.
Fixed compiler generated items with locals.
Project Generation:
Fixed reference to Microsoft.CSharp for 4.6 API level.
3.3.0.2
Bug fixes
Project Generation:
Fixed the Visual Studio solution generation on Unity 5.5 and previous versions.
3.3.0.0
New Features
Evaluation:
Added support for creating structs with the new Unity runtime.
Added minimalist support for pointers.
Bug fixes
Evaluation:
Fixed method invocation on primitives.
Fixed field evaluation with types marked with BeforeFieldInit.
Fixed non supported calls with binary operators (substract).
Fixed issues when adding items to the Visual Studio Watch.
Project Generation:
Fixed assembly name references with mcs.rsp files.
Fixed defines with API levels.
3.2.0.0
New Features
Installer:
Added support for cleaning the MEF cache.
Bug fixes
Code Editor:
Fixed classification/completion with custom attributes.
Fixed flickering with Unity messages.
3.1.0.0
Released April 7, 2017
New Features
Debugger:
Added support for the new Unity runtime (with .NET 4.6 / C# 6 compatibility).
Project Generation:
Added support for .NET 4.6 profile.
Added support for mcs.rsp files.
Always enable unsafe compilation switch when Unity 5.6 is used.
Added support for "Player" project generation when using Windows Store platform and il2cpp
backend.
Bug fixes
Code Editor:
Fixed caret position after inserting method with auto-completion.
Project Generation:
Removed assembly version post-processing.
3.0.0.1
This version includes all new features and bug fixes introduced with 2.8.x series.
2.8.2.0 - 3.0 Preview 3

Bug fixes
Project Generation:
Fixed regression where Plugins projects where referenced twice, first as a binary DLL then as a project
reference.
2.8.1.0 - 3.0 Preview 2

Bug fixes
Code Editor:
Fixed a crash when starting an attribute declaration without brace completion.
Debugger:
Fixed function breakpoints with coroutines under the new Unity compiler/runtime.
Added warning in case of an unbindable breakpoint (when no corresponding source-location is
found).
Project Generation:
Fixed csproj generation with special/localized characters.
Fixed references outside of Assets, such as Library (like the Facebook SDK).
Misc:
Added check to prevent Unity from running when installing or uninstalling.
Switched to https to target the remote Unity documentation.
2.8.0.0 - 3.0 Preview

New Features
General:
Added Visual Studio 2017 installer support.
Added Visual Studio 2017 extension support.
Added localization support.
Code Editor:
Added C# IntelliSense for Unity messages.
Added C# code coloration for Unity messages.
Debugger:
Added support for is , as , direct cast, default , new expressions.
Added support for string concat expressions.
Added support for hexadecimal display of integer values.
Added support for creating new temporary variables (statements).
Added support for implicit primitive conversions.
Added better error messages when a type is expected or not found.
Project Generation:
Removed the CSharp suffix from the project names.
Removed reference to a system wide msbuild targets file.
Wizards:
Added support for Unity messages in non Behaviour types such as Editor or EditorWindow.
Switched to Roslyn to inject and format Unity messages.
Bug fixes
Debugger:
Fixed a bug crashing Unity when evaluating generic types.
Fixed handling of nullable types.
Fixed handling of enums.
Fixed handling of nested member types.
Fixed collection indexer access.
Fixed support for debugging iterator frames with new C# compiler.
Project Generation:
Fixed bug that prevented compilation when targeting the Unity Web player.
Fixed bug that prevented compilation when compiling a script with a web encoded file name.
2.3.0.0
New Features
General:
Added an option to disable Unity console logs in Visual Studio's error list.
Added an option to allow generated project properties to be modified.
Debugger:
Added Text, XML, HTML and JSON string visualizers.
Wizards:
Added missing MonoBehaviors.
Bug fixes
General:
Fixed a conflict with ReSharper that prevented controls inside Visual Studio settings from being
displayed.
Fixed a conflict with Xamarin that prevented debugging in some cases.
Debugger:
Fixed an issue that caused Visual Studio to freeze when debugging.
Fixed an issue with function breakpoints in Visual Studio 2015.
Fixed several expression evaluation issues.
2.2.0.0
New Features
Wizards:
Added smart search in the Implement MonoBehavior wizard.
Made wizards context aware; for example, NetworkBehavior messages are only available when
working with a NetworkBehavior.
Added support for NetworkBehavior messages in the wizards.
UI:
Added an option to configure the visibility of MonoBehavior messages.
Removed Visual Studio property pages that are not relevant to Unity projects.
Bug fixes
Project generation:
Fixed references to UnityEngine and UnityEditor on Unity 4.6.
Fixed generation of project files when Unity is running on OSX.
Fixed handling of project names containing hashmark (#) characters.
Restricted generated projects to C# 4.
Debugger:
Fixed an issue with expression evaluation when debugging inside a Unity coroutine.
Fixed an issue that caused Visual Studio to freeze when debugging.
UI:
Fixed an incompatibility with the Tabs Studio Visual Studio extension.
Installer:
Support machine-wide installation of VSTU (install for all users) by creating HKLM registry entries.
Fixed issues with uninstallation of VSTU when the same version of VSTU is installed for multiple
different versions of Visual Studio. For example, when VSTU 2015 2.1.0.0 and VSTU 2013 2.1.0.0
were both installed.
2.1.0.0
New Features
Support for Unity 5.2
Bug fixes
Display menu items on Unity < 4.2
An error message is no longer displayed when Visual Studio locks XML intellisense files.
Handle <<When Changed>> conditional breakpoints when conditional argument is not a boolean value.
Fixed references to UnityEngine and UnityEditor assemblies for Windows Store apps.
Fixed error when stepping in the debugger: Unable to step, general exception.
Fixed hit-count breakpoints in Visual Studio 2015.
2.0.0.0
Bug fixes
Unity Integration:
Fixed the conversion of debug symbols created with Visual Studio 2015 when importing a DLL and
its debug symbols (PDB ).
Always generate MDB files when importing a DLL and its debug symbols (PDB ), except when an
MDB file is also provided.
Fixed pollution of the Unity project directory with an obj directory.
Fixed generation of references to System.Xml.Link and System.Runtime.Serialization.
Added support for multiple subscribers to the project file generation API hooks.
Always complete project file generation even when one of the files to be generated is locked.
Added support for * wildcards in the extension filter when specifying files to be included in the C#
project.
Visual Studio integration:
Fixed a compatibility issue with the Productivity Power Tools.
Fixed generating MonoBehaviors around events and delegates declarations.
Debugger:
Fixed a potential freeze when debugging.
Fixed an issue where locals would not be displayed in certain stack frames.
Fixed inspecting empty arrays.
1.9.9.0 - 2.0 Preview 2

New features
Unity Project Explorer:
Automatically rename class when renaming a file in the Unity Project Explorer (See Options dialog).
Automatically select newly created scripts in the Unity Project Explorer.
Track the active script in the Unity Project Explorer (See Options dialog).
Dual-synchronize the Visual Studio Solution Explorer (See Options dialog).
Adopt Visual Studio icons in Unity Project Explorer.
Debugger:
Select the active debug target from a list of saved or recently-used debug targets (See Options
dialog).
Create function breakpoints on MonoBehavior methods and apply them to multiple MonoBehavior
classes.
Support Make Object ID in the debugger.
Support breakpoint hit count in the debugger.
Support break-on-exception in the debugger (Experimental. See Options Dialog).
Support creation of objects and arrays when evaluating expressions in the debugger.
Support null comparison when evaluation expressions in the debugger.
Filter out obsolete members in debugger watch windows.
Installer:
Optimized Visual Studio Tools for Unity extension registration.
Install Visual Studio Tools for Unity package for Unity 5.
Documentation: Improve performance of documentation generation.
Wizards: Support new MonoBehavior methods for Unity 4.6 and Unity 5.
Unity: Lookup unsafe flags and custom defines in .rsp files during project file generation.
UI: Added Visual Studio Tools for Unity Options dialog in Visual Studio.
Bug fixes
Unity Project Explorer:
Refresh the Unity Project Explorer after files are moved or renamed from the Visual Studio Solution
Explorer.
Preserve selections when renaming files in the Unity Project Explorer.
Prevent automatic expand and collapse when files are double clicked in the Unity Project Explorer.
Ensure that newly selected files are visible in the Unity Project Explorer.
Debugger:
Prevent a possible Visual Studio freeze when evaluating expressions in the debugger.
Ensure that method invocations happen on the proper domain in the debugger.
Unity:
Correct the location of UnityVS.OpenFile with Unity 5.
Correct the location of pdb2mdb with Unity 5.
Prevent a possible exception during project file generation.
Prevent a possible freeze when running Unity on OSX.
Handle internal exceptions.
Send Unity console logs to the VS error list.
Documentation: Correct documentation generation for the new unity documentation.
Project: Move and rename Unity .meta files when needed, even in folders.
Wizards: Correct the order of MonoBehavior method parameters when generating code.
UI: Support Visual Studio themes for context menu and icons.
1.9.8.0 - 2.0 Preview

New features
Support for Visual Studio 2015.
Code Coloration for Unity shaders in Visual Studio 2015.
Improved visualization of values when debugging:
Better visualization for ArrayLists, Lists, Hashtables and Dictionaries.
Show Non-Public members and Static members as categories in watch and local views.
Improved display of Unity's SerializedProperty to only evaluate the value field valid for the property.
DebuggerDisplayAttribute support for classes and structs.
DebuggerTypeProxyAttribute support.
Make the insertion of MonoBehaviour methods using our wizards to respect the user coding conventions.
Implement support for Compile Time Text Templates in UnityVS generated projects.
Implement support for ResX resources in UnityVS generated projects.
Support opening shaders in Visual Studio from Unity.
Bug fixes
Cleanup sockets before starting the game in Unity after Attach and Play was triggered in Visual Studio. This
fixes some issues with the stability of the connection between Unity and VS when using Attach and Play.
Avoid calling methods in Unity's scripting engine debugger interface that are prone to freeze Unity. This
fixes the Unity freeze when attaching the debugger.
Fix displaying of callstacks when no symbols are available.
Do not register the log callback if we don't have to.
1.9.2.0
Released October 9, 2014
New features
Improve detection of Unity players.
When using our file opener, make Unity pass the line number as well as the file name.
Default to the online Unity documentation if there's no local documentation.
Bug fixes
Fix potential Unity crash when hitting a breakpoint after a domain reload.
Fix exceptions shown in the Unity console when closing our Configuration or About windows, after a
domain reload.
Fix detection of 64bits Unity running locally.
Fix filtering of MonoBehaviours per Unity version in wizards.
Fix bug where all assets were included in the project files if the extension filter was empty.
1.9.1.0
New features
Optimize binding breakpoint to source locations.
Support for overloaded methods in the Expression Evaluation of the debugger.
Support for boxing primitives and value types in the Expression Evaluation of the debugger.
Support recreating the C# local variables environment when debugging anonymous methods.
Delete and rename .meta files when deleting or renaming files from Visual Studio.
Bug fixes
Fix handling of Visual Studio themes. Previously, dialogs on black themes could appear empty.
Fix Unity freeze when connecting the debugger while Unity is recompiling.
Fix breakpoints when debugging remote editors or players compiled on another system.
Fix a possible Visual Studio crash when a breakpoint is hit.
Fix breakpoints binding to avoid breakpoints showing as unloaded.
Fix handling of variable scope in the debugger to avoid live variables that appear out of scope.
Fix lookup of static members in the Expression Evaluation of the debugger.
Fix displaying of types in the Expression Evaluation of the debugger to show static fields and properties.
Fix generation of solution when the Unity project names includes special characters that Visual Studio
forbids (Connect issue #948666).
Fix the Visual Studio Tools Unity package to immediately stop sending console events after the option has
been unchecked (Connect issue #933357).
Fix detection of references to properly regenerate references to new APIs like UnityEngine.UI in the UnityVS
generated projects.
Fix installer to require that Visual Studio is closed before installation to avoid corrupted installations.
Fix installer to install the Unity Reference Assemblies as a proper standalone component, shared between all
versions of VSTU.
Fix opening scripts with VSTU in 64 bits versions of Unity.
1.9.0.0
New features
In the Attach Unity Debugger window, add the ability to enter a custom IP and port to debug.
Add configuration option to set Unity to run in the background or not.
Add configuration option to generate solution and project files or project files only.
Startup target: choose to Attach to Unity or Attach to Unity and Play.
Display of multi-dimensional arrays in the debugger.
Handle new Unity Player debugging ports.
Handle references to new Unity assemblies like Unity's 4.6 GUI assemblies.
Deconstructs closures to properly display local variables when debugging.
Deconstructs generated iterators variables into arguments when debugging.
Preserve Unity Project Explorer's state after a project reload.
Add a command to synchronize the Unity Project Explorer with the current document.
Bug fixes
Fix conditional breakpoints whose conditions are set before starting the debugger.
Fix references to UnityEngine to avoid warnings.
Fix parsing versions for Unity betas.
Fix issue where variables would not appear in the local variables window when hitting a breakpoint or
stepping.
Fix variables tooltips in Visual Studio 2013.
Fix generation of the IntelliSense documentation for Unity 4.5.
Fix the Unity / Visual Studio communication after a domain reload (play/stop in Unity).
Fix handling of parts of Visual Studio themes.
IMPORTANT
C# being the predominant language in the Unity ecosystem - the new Sample Assets are in C#, the Unity documentation will
default to C# - we removed our basic support for UnityScript and Boo to better focus on the C# experience. As a result, VSTU
solutions are now C# only and are much faster to load.
1.8.2.0
New features
Work around an issue in Unity's scripting engine's network layer on Mavericks for remote discovery of
editors.
Handle new ports to discover remote Unity players.
Reference the UnityEngine assembly specific to the current build target.
Add setting to filter files to include in generated projects.
Add setting to disable sending console logs to Visual Studio error list. This is useful if you're using
PlayMaker or Console Pro as there could be only one callback registered in Unity to receive console logs.
Add setting to disable the generation of mdb debug symbols. This is useful if you're generating the mdb
yourself.
Bug fixes
Fix a regression when files opened in VS from Unity >= 4.2 would lose IntelliSense.
Fix our VS dialogs to handle custom themes.
Fix closing the context menu of the UPE.
Prevent crash in Unity when the version specific generated assembly if out of sync.
1.8.1.0
New features
Adjusted the MonoBehaviour wizards with Unity 4.3 APIs.
MonoBehaviour wizards are filtering Unity APIs depending on the version you use.
Add a reference to System.Xml.Linq to the projects for Unity > 4.1.
Prettify our calls to Debug.Log to not include the beginning of the stacktrace in the message.
Bug fixes
Fixed a bug where we would interfere with the default handling of JavaScript files in Visual Studio.
Fixed a white pixel appearing in VS, for real this time.
Fixed deletion of the UnityVS.VersionSpecific assembly if it's marked as readonly by a SCM.
Fixed exceptions when creating sockets in the UnityVS package.
Fixed a crash in Visual Studio when loading stock images from Visual Studio assemblies.
Fixed a bug in the generation of the UnityVS.VersionSpecific for source builds of Unity.
Fixed a possible freeze when opening a socket in the Unity package.
Fixed the handling of Unity project with a dash (-) in their name.
Fixed opening scripts from Unity to not confuse the ALT+TAB order for Unity 4.2 and above.
1.8.0.0
New features
Drastically improved debugger connection speed.
Automatically handle navigation to file and line on Unity 4.2 and above.
Conditional breakpoints.
Project file generator now handles T4 templates.
Update MonBehavior wizards with new APIs.
IntelliSense documentation in C# for Unity types.
Arithmetic and logical expressions evaluation.
Better discovery of remote editors for the remote debugging preview.
Bug fixes
Fixed a bug where we would leak a thread in VS after disconnecting the debugger.
Fixed a white pixel appearing in VS.
Fixed the handling of clicks on the status bar icon.
Fixed the generation of references with assemblies in Plugins folders.
Fixed creation of sockets from the UnityVS package in case of exceptions.
Fixed the detection of new versions of UnityVS.
Fixed the prompt of the license manager when the license expired.
Fixed a bug that could render the process list empty in the attach debugger to process window of VS.
Fixed changing values of Booleans in the local view.
1.2.2.0
Bug fixes
Handle fully qualified names in expression evaluator.
Fixed a freeze related to exception handling where the Unity scripting engine is sending us incorrect
stackframe data.
Fixed build process for Web targets.
Fixed an error that could happen if Visual Studio was started and that a deleted file was in the list of files to
open at startup.
Fixed UnityVS.OpenFile to handle non script files, like compiled shaders.
We now reference Boo.Lang and UnityScript.Lang from all the C# projects.
Fixed generation of references in projects if the project has special characters.
Workaround a VS issue where method calls to disposed projects would trigger multiple
NullReferenceException MessageBox.
Fixed handling of Unity 4.2 Beta assemblies.
1.2.1.0
Bug fixes
Fixed local deployment of Unity assemblies for code completion in the event of an IO error (such as read-
only files, or files locked by Visual Studio).
Fixed a regression where opening a script from Unity would not focus the file if it was already opened in
Visual Studio.
Fixed performance issue of the new exception handling.
Fixed binding of breakpoints in some external DLLs.
1.2.0.0
New features
Drastically improved debugger connection speed.
Optimized Unity Project Explorer for larger projects.
Honor the Visual Studio settings to break (or not) on handled and unhandled exceptions.
Honor the Visual Studio setting to call ToString on local variables.
Add new menu Debug -> Attach Unity debugger, which you can use to debug Unity players.
Preserve custom projects added to the UnityVS solution upon solution file generation.
Add new keyboard shortcut CTRL+ALT+M -> CTRL+H to display the Unity documentation for the Unity
function or member at the caret position.
Take compiler response files (rsp) into account when compiling from Visual Studio.
Deconstruct compiler generated types to show variables when debugging generator methods.
Simplify the remote debugging by removing the need to configure a shared folder to Unity. Now you just
need to have access to your Unity project from Windows.
Install a custom Unity profile as a standard .net target profile. This fixes all false positives that ReSharper
could show.
Work around a Unity scripting engine bug, so the debugger won't break on non properly registered threads.
Rework the file opener to avoid a race condition in VS where it claimed to be able to open files, while
crashing on the file open request.
UnityVS is now asking to refresh the build when VS is building the project, and not on file save anymore.
Bug fixes
Fixed our custom .net profile
Fixed the theming integration, this fixes our issues with the VS 2012 dark theme.
Fixed quick behavior shortcut in VS 2012.
Fixed a stepping issue that could happen when debugging and a non-main thread would hit a breakpoint.
Fixed UnityScript and Boo completion of type aliases, such as int.
Fixed exception when writing a new UnityScript or Boo string.
Fixed exceptions in Unity menus when a solution was not loaded.
Fixed bug UVS -48: typing double quote sometimes produce error and break all function (code completion,
syntax highlight etc).
Fixed bug UVS -46: Duplicated opened script file (UnityScript) when clicking on the Error List of Visual
Studio.
Fixed bug UVS -42: Unity connectivity logo in the status bar doesn't handle mouse events in VS 2012.
Fixed bug UVS -44: CTRL+SHIFT+Q is not available in VS 2012 for Quick MonoBehaviours.
Fixed bug UVS -40: Selected items in the Unity Project Explorer are unreadable when the window is inactive
in VS2012 "dark" theme.
Fixed bug UVS -39: Issue tokenizing escaped strings.
Fixed bug UVS -35: Invoke ToString on objects when inspecting variables.
Fixed bug UVS -27: Goto Symbol window inconsistency with "dark" theme in VS2012.
Fixed bug UVS -11: Locals in coroutines.
1.1.0.0 - Beta release

Released March, 9, 2013
1.0.13.0
Bug fixes
Fixed a Visual Studio lockup that could happen if the target debuggee is sending invalid thread events. That
would typically happen when debugging a remote Unity on OSX.
Fixed a Visual Studio lockup that could happen if an exception shuts down the debugger.
Fixed our MonoBehavior helpers when a C# MonoBehavior is in a namespace.
Fixed debugger tooltips for UnityScript in Visual Studio 2012.
Fixed project generation when only debug constants are changed from Unity.
Fixed keyboard navigation in the Unity Project Explorer.
Fixed UnityScript colorization for escaped strings.
Fixed our file opener to guess better the project name when used outside of Unity. That's necessary when
the user uses a third part file opener in Unity that delegates to UnityVS.
Fixed handling of long messages sent from Unity to UnityVS. Before that, long messages could crash our
messaging part of UnityVS. As a consequence, sometimes UnityVS wouldn't open a file from Unity.
1.0.12.0
Bug fixes
Fixed Visual Studio lockup that could happen when Visual Studio was deleting a breakpoint.
Fixed a bug where some breakpoints would not be hit after Unity recompiled game scripts.
Fixed the debugger to properly notify Visual Studio when breakpoints were unbound.
Fixed a registration issue that could prevent the Visual Studio debugger to debug native programs.
Fixed an exception that could happen when evaluating UnityScript and Boo expressions.
Fixed a regression where changing the .net API level in Unity would not trigger an update of the project files.
Fixed an API glitch where user code could not participate in the log callback handler.
1.0.11.0
New features
Official support of Unity 4.
Manipulation of scripts from the Unity Project Explorer.
Integration in Visual Studio's Navigate To window.
Parsing of Info console message, so that clicking in the Error List take you to the first stackframe with
symbols.
Add an API to let user participate in the project generation.
Add an API to let user participate in the LogCallback.
Bug fixes
Fixed regression in the background of the Unity Project Explorer in Visual Studio 2012.
Fixed project generation for users of the full .net profile.
Fixed project generation for users of the Web target.
Fixed project generation to include DEBUG and TRACE compilation symbols as Unity does.
Fixed crash when using special characters in our Goto Symbol window.
Fixed crash if we can't inject our icon in Visual Studio's status bar.
1.0.10.0
Bug Fixes
Fixed the background of the Unity Project Explorer in Visual Studio 2010.
Fixed a Visual Studio freeze that could happen if UnityVS tried to attach the debugger to a Unity whose
debugger interface previously crashed.
Fixed a Visual Studio freeze that could happen when a breakpoint was set and a AppDomain reload would
occur.
Fixed how assemblies are retrieved from Unity to avoid locking files and confuse the Unity build process.
1.0.9.0
Bug fixes
Fixed project generation when the Unity project includes actual JavaScript assets.
Fixed error handling in expression evaluation.
Fixed setting new values to fields of value types.
Fixed possible side effects when hovering over expressions from the code editor.
Fixed how types are searched in loaded assemblies for expression evaluation.
Fixed bug UVS -21: Evaluation of assignment on Unity objects has no effect.
Fixed bug UVS -21: Invalid pointer when evaluating a method invocation to Unity Math API.
1.0.8.0
Bug fixes
Fixed the way our script opener acquired the path to the project to be sure that it is able to open both Visual
Studio and the scripts.
Fixed a bug with breakpoints created while the debugging session was running that could cause Visual
Studio to lock up.
Fixed how UnityVS is registered on Visual Studio 2010.
1.0.7.0
New features
Visual Studio 2012 support.
Bug fixes
Fixed generation of Editor and Plugins project files to match Unity's behavior.
Fixed the translation of .pdb symbols on Unity 4.
IMPORTANT
Because of the Visual Studio 2012 support, we had to rename a few files and move some other around. The UnityVS package
to import Unity is now named either UnityVS 2010 or UnityVS 2012, for respectively Visual Studio 2010 and Visual Studio
2012. This version also requires that the UnityVS project files are regenerated.
1.0.6.0 - Internal build

1.0.5.0
Bug fixes
Fixed generation of project files when scripts or shaders had an invalid xml character.
Fixed detection of Unity instances when Unity was connected to the Asset server. This triggered failures to
open files from Unity and the automatic connection of the Visual Studio debugger.
1.0.4.0
New features
Automatic conversion of debug symbols in Unity.
If you have a .NET .dll assembly with its associated .pdb in your Asset folder, simply re-import the assembly
and UnityVS will convert the .pdb into a debug symbols file that Unity's scripting engine understands, and
you'll be able to step into your .NET assemblies from UnityVS.
Bug fixes
Fixed UnityVS crash while debugging caused by exceptions thrown by methods or properties inside Unity.
1.0.3.0
New features
New configuration option to disable the usage of UnityVS to open files from Unity.
Bug fixes
Fixed generation of references to UnityEditor for non editor projects.
Fixed definition of UNITY_EDITOR symbol for non editor projects.
Fixed random VS crash caused by our custom status bar.
1.0.2.0
Bug fixes
Fixed conflict with the PythonTools debugger.
Fixed references to Mono.Cecil.
Fixed bug in how scripting assemblies were retrieved from Unity with Unity 4 b7.
1.0.1.0
New features
Preview support for Unity 4.0 Beta.
Bug fixes
Fixed the inspection of properties throwing exceptions.
Fixed descending into base objects when inspecting objects.
Fixed blank dropdown list for the insertion point in the MonoBehavior wizard.
Fixed completion for dll inside the Asset folder for UnityScript and Boo.
1.0.0.0 - Initial release

Change Log (Visual Studio Tools for Unity, Mac)
Visual Studio Tools for Unity change log.
1.7.0.0
New Features
Debugger:
Added more client information (IP, machine name) on the attach dialog.
Bug fixes
Debugger:
Fixed a deadlock in the library used to communicate with Unity’s debugger engine, making Visual Studio
or Unity freeze, especially when hitting ‘Attach to Unity’ or restarting game.
Integration:
Fixed Unity plugin activation when another default editor was selected.
Fixed Unity file template creation.
1.6.0.2
Bug fixes
Integration:
Rolled back the workaround for a Unity performance bug that has been fixed by Unity.
1.6.0.1
Bug fixes
Integration:
Fixed Shader code coloration support.
1.6.0.0
Released June 26, 2018
Bug fixes
Wizards:
Fixed typo with OnApplicationFocus message.
Project Generation:
Transient workaround for a Unity performance bug: cache MonoIslands when generating projects.
Do not convert portable pdb to mdb anymore when using the new Unity runtime.
1.5.0.2
New Features
Integration:
Added support for basic Shader code completion.
Added support for toggling comments in Shader files.
1.5.0.1
New Features
Integration:
Added support for extra templates in the Unity Project Explorer.
1.5.0.0
New Features
Integration:
Added support for detecting and attaching to Android players connected through USB.
1.4.0.3
New Features
Project Generation:
Added support for the new project generator in Unity 2018.1.
Integration:
Added option panel for dedicated settings.
1.4.0.2
Bug fixes
Project Generation:
Fixed Mono version detection.
Integration:
Fixed timing issues with 2018.1 and plugin activation.
Fixed notifications when detecting a new player.
1.4.0.1
Bug fixes
Integration:
Fixed Expand/Collapse folders on double-click
1.4.0.0
New Features
Project Generation:
Added support for .NET Standard.
Bug fixes
Integration:
1.3.0.1
Bug fixes
Integration:
Fixed indirect call to EditorPrefs.GetBool impacting the inspector while trying to change array size.
Wizards:
Refresh roslyn context before inserting method.
1.3.0.0
New Features
Wizards:
Added "Implement Unity message" wizard.
Added support for the new completion API in VS for Mac 7.4.
1.2.0.0
New Features
Debugger:
Added support for portable debug symbol files.
Bug fixes
Project Generation:
Fixed extra .dll extension wrongly added to the assembly filename.
Do not force the AllowAttachedDebuggingOfEditor Unity flag as the default is now 'true'.
1.1.0.3
New Features
Project Generation:
Added support for .NET 4.6 profile.
1.1.0.2
New Features
Debugger:
Start the attach to process dialog if not sure which Unity to attach to.
Project Generation:
Always enable unsafe compilation switch when Unity 5.6 is used.
1.1.0.1
New Features
Integration:
Added support for localized resources.
1.1.0.0
New Features
Integration:
Added support for attaching to players and editors through the Attach to process window.
Project Generation:
Fixed assembly name references with mcs.rsp files.
Added support for assembly.json compilation units.
Fixed defines with API levels.
Bug fixes
Integration:
Fixed shader error message when compiling.
1.0.0.1
Bug fixes
Integration:
Fixed active document tracking with hybrid and regular projects.
1.0.0.0
DevOps with Unity apps
Developing apps for modern platforms involves many more activities than just writing code. These activities,
referred to as DevOps (development + operations), span the app's complete life cycle and include planning and
tracking work, designing and implementing code, managing a source code repository, running builds, managing
continuous integrations and deployments, testing (including unit tests and UI tests), running various forms of
diagnostics in both development and production environments, and monitoring app performance and user
behaviors in real time through telemetry and analytics.
Visual Studio, together with Azure DevOps Services and Team Foundation Server, provides a variety of DevOps
capabilities. Many of these are applicable to cross-platform projects, including games and immersive graphical
apps created with Unity—especially when using C# as a scripting language. However, because Unity has its own
development environment and runtime engine, a number of DevOps features don't apply as they would to other
kinds of projects built in Visual Studio.
The following tables identify how DevOps features in Visual Studio apply or don't apply when working with Unity.
Refer to the linked documentation for details on the features themselves.
Agile tools
Reference link: About Agile tools and Agile project management (using Azure Boards or TFS, including Team
Explorer Everywhere)
General Comment: all planning and tracking features are independent of project type and coding languages.
FEATURE SUPPORTED WITH UNITY ADDITIONAL COMMENTS
Manage backlogs and sprints Yes
Work tracking Yes
Team room collaboration Yes
Kanban boards Yes
Report and visualize progress Yes
Modeling
Reference link: Analyze and model architecture
General Comment: Although these design features are either independent of coding language, or work with .NET
languages like C#, they operate on a traditional application paradigm with object hierarchies and class
relationships. Designing a game within Unity involves a different paradigm altogether, namely the relationships of
graphical objects, sounds, shaders, scripts, and so forth. For this reason, the Visual Studio modeling diagram tools
are not particularly relevant to the whole of a Unity project. They could possibly be used to manage relationships
within C# scripts, but that is only one part of the whole.
Sequence diagrams No
Dependency graphs No
Call hierarchy No
Class designer No
Architecture explorer No
UML diagrams (use case, activity, class, No

component, sequence, and DSL)
Layer diagrams No
Layer validation No
Code
Use Team Foundation Version Control Yes Unity projects are simply a collection of
(TFVC) or Azure Repos files that can be placed into version
control systems like any other project,
but there are a few special
considerations described after this table.
Getting started with Git in Azure Repos Yes See notes after the table.
Improve Code Quality Yes
Find code changes and other history Yes
Use code maps to debug your Yes

applications
Special considerations for version control with Unity:

1. Unity tracks metadata about game assets in a single, opaque library that is hidden by default. To keep files
and metadata in sync, it is necessary to make the metadata visible and to store it in more-manageable
chunks. For details, refer to Using External Version Control Systems with Unity (Unity documentation).
2. Not all files and folders in a Unity project are appropriate for source control, as is also described in the link
above. The Assets and ProjectSettings folders should be added, but the Library and Temp folders should not.
For an additional list of generated files that would not go into source control, see the discussion How to use
Git for Unity3D source control? on StackOverflow. Many developers have also blogged on this subject
independently.
3. Binary assets in a Unity project—such as textures or audio files—can take up a large amount of storage.
Various source control systems like Git store a unique copy of a file for every change that is made, even if
the change affects only a small portion of the file. This can cause the Git repository to become bloated. To
address this, Unity developers often elect to add only final assets to their repository, and use a different
means of keeping a working history of their assets, such as OneDrive, DropBox, or git-annex. This approach
works because such assets typically don't need to be versioned along with source code changes. Developers
also typically set the project editor's Asset Serialization Mode to Force Text to store scene files in text rather
than binary format, which allows for merges in source control. For details, see Editor Settings (Unity
documentation).
Build
Reference link: Azure Pipelines
On-premises Team Foundation Server Possible Unity projects are built through the
(TFS) Unity environment and not through the
Visual Studio build system (building
within the Visual Studio Tools for Unity
will compile the scripts but not produce
an executable). It is possible to build
Unity projects from the command line
(Unity documentation), so it possible to
configure an MSBuild process on a TFS
server to execute the appropriate Unity
commands, provided that Unity itself is
installed on that computer.
Unity also offers Unity Cloud Build,

which monitors a Git or SVN repository
and runs periodic builds. At present it
does not work with TFVC or Azure
DevOps Services.
On-premises build server linked to Possible Given the same conditions as above, it
Azure DevOps Services is further possible to direct builds
triggered through Azure DevOps
Services to use an on-premises TFS
computer. See Build and release agents
for instructions.
Hosted controller service of Azure No Unity builds are not presently

DevOps Services supported.
Build definitions with pre- and post- Yes A custom build definition that uses the
scripts Unity command line to run a build can
also be configured for pre- and post-
build scripts.
Continuous integration including gated Yes Gated check-ins for TFVC only as Git
check-ins works on a pull-request model rather
than check-ins.
Test
Planning tests, creating test cases and Yes

organizing test suites
Manual testing Yes
Test Manager (record and playback Windows devices and Android

tests) emulators only
Code coverage n/a Not applicable as unit testing happens

within Unity and not Visual Studio, see
below.
Unit test your code Within Unity, but not Visual Studio Unity provides its own unit test
framework as part of Unity test tools
(Unity Asset Store). Unit test results are
reported within Unity and will not be
surfaced within Visual Studio.
Use UI automation to test your code No Coded UI tests rely on readable controls
in the app's UI; Unity apps are graphical
in nature and so content isn't readable
by the Coded UI test tools.
Improve code quality

Reference link: Improve code quality
Analyze managed code quality Yes Can analyze the C# script code within
Visual Studio.
Find duplicate code by using code clone Yes Can analyze the C# script code within
detection Visual Studio.
Measure complexity and maintainability Yes Can analyze the C# script code within
of managed code Visual Studio.
Performance Explorer No Use the Unity Profiler (Unity website).
Analyze .NET Framework memory issues No Visual Studio tools do not have hooks
into the Mono framework (as used by
Unity) for profiling. Use the Unity
Profiler (Unity documentation).
Release management
Reference link: Build and release in Azure Pipelines and TFS
Manage release processes Yes
Deployment to servers for side-loading Yes

via scripts
Upload to app store Partial Extensions are available that can

automate this process for some app
stores. See Extensions for Azure DevOps
Services; for example, the extension for
Google Play.
Monitor with HockeyApp

Reference link: Monitor with HockeyApp
Crash analytics, telemetry, and beta Yes HockeyApp is primarily useful for
distribution handling beta distribution and
obtaining crash reports.
For telemetry from C# scripts, it is

possible to use any analytics framework
provided that it runs on the version of
.NET that is used by Unity. However,
this allows for analytics only within
game scripts and not more deeply
inside the Unity engine. At present
there is no plugin for Application
Insights, but plugins are available for
other analytics solutions such as Unity
Analytics and Google Analytics. Services
like Unity Analytics that understand the
nature of a Unity project will, of course,
provide much more meaningful analysis
than generic frameworks.
Visual C++ for cross-platform mobile development
You can build native C++ apps for iOS, Android and Windows devices, and share common code in libraries built
for iOS, Android, and Windows, by using Visual C++ for Cross-Platform Mobile Development. This is an option
available in Visual Studio 2015 that installs the SDKs and tools you need for cross-platform development of shared
libraries and native apps. When it's installed, you can use Visual C++ to create code that runs on iOS and Android
devices and platforms, in addition to Windows, Windows Phone, and Xbox.
Writing code for multiple platforms can be frustrating. The primary development languages and tools for iOS,
Android, and Windows are different on each platform. However, all platforms support writing code in C++. This is
the common denominator that you can use to enable reuse of core code across platforms. Native code written in
C++ can be both more performant and resistant to reverse engineering. Code reuse can save both time and effort
when creating apps for multiple platforms.
Development using Visual C++ for Cross-Platform Mobile Development has several advantages:
1. Easy installation. The Visual Studio installer acquires and installs the required third-party tools and SDKs
you need to build apps or libraries for Android and iOS. Configuration and setup is simple and mostly
automatic.
2. A powerful and familiar build environment. Create sharable cross-platform solutions and projects
easily with Visual Studio templates. Manage properties for all projects using one common interface. Edit all
your code in the Visual Studio editor, and take advantage of the built-in cross-platform IntelliSense for code
completion and error highlighting.
3. A unified debugging experience. Use the world-class debugging tools in Visual Studio to watch and step
through C++ code on all platforms, including Android devices and emulators, iOS simulators and devices,
and Windows or Windows Phone devices and emulators.
Get the tools

Visual C++ for Cross-Platform Mobile Development is an installable option that comes with Visual Studio 2015.
For prerequisites and installation instructions, see Install Visual C++ for cross-platform mobile development. To
build code for iOS, you also need a Mac computer and an Apple iOS Developer Account. For more information,
see Install and configure tools to build using iOS.
Come up to speed
If you're coming from Android or iOS development, we have some great material on how to get started. Visual
Studio is an expressive and capable development environment. To learn how to use it, try Get started for Android
developers or Get started for iOS developers. These topics will introduce you to Visual Studio and the concepts
you'll need to develop cross-platform apps for Windows and Windows Phone. To get started writing your first
cross-platform app for iOS and Android, see Build an OpenGL ES Application on Android and iOS.
Visual C++ for Cross-Platform Mobile Development includes several templates to help you get started on your
apps:
OpenGLES 2 Application (Android, iOS, Windows Universal)
Creates a solution that includes a set of projects to build an Android Native Activity app, an iOS app, and a
Universal Windows app, together with a shared C++ code library. These apps use platform-specific libraries
created by using common C++ OpenGL ES code to draw the same spinning cube in each app. You must
include the Universal Windows App Development Tools option when you install Visual Studio to use this
template.
Native-Activity Application (Android)
Creates a complete C++ OpenGL app as an Android Native Activity project.
OpenGLES Application (Android, iOS )
Creates a solution with a set of projects to build both an Android Native Activity app and an iOS app. These
apps use platform-specific libraries created by using common C++ OpenGL ES code to draw the same
spinning cube in each app.
Shared Library (Android, iOS )
Creates a solution with projects to create an Android dynamic library (.so) file and an iOS static library (.a)
file by using common C++ code in a shared project.
Basic Application (Android, Ant)
Creates an Android "Hello, World" app project that uses only Java source code and the Ant build system.
Basic Application (Android, Gradle)
Creates an Android "Hello, World" app project that uses only Java source code and the Gradle build system.
Basic Library (Android, Ant)
Creates an Android "Hello, World" library project that uses only Java source code and the Ant build system.
Basic Library (Android, Gradle)
Creates an Android "Hello, World" library project that uses only Java source code and the Gradle build
system.
Dynamic Shared Library (Android)
Creates an Android dynamic library (.so) file by using C++ code.
OpenGLES 2 Application (iOS )
Creates a solution with a set of projects to build an OpenGL ES 2 iOS app. The app uses a library of C++
OpenGL ES code to draw the spinning cube in an iOS app. This app can be a good starting point for seeing
how to import C++ libraries into your iOS app.
Static Library (Android)
Creates a project to build a static library for Android. You can only link one dynamic library in an Android
app, but you can link any number of static libraries.
Static Library (iOS )
Creates a project to build a static library for iOS.
Makefile Project (Android)
Creates a project wrapper for your own Android makefile projects.
Try out sample code

Download samples that show how to create shared code libraries you can use in Windows, Android, and iOS apps,
and how to create complete Native Activity apps for Android. To get started, see Cross-platform mobile
development examples.
In this section
1. Install Visual C++ for cross-platform mobile development
2. Install and configure tools to build using iOS
3. Create an Android native activity app
4. Build an OpenGL ES application on Android and iOS
5. Cross-platform mobile development examples
Install cross-platform Mobile development with C++
You can use C++ in Visual Studio to build Windows Desktop apps, Universal Windows Platform (UWP ) apps,
Linux apps, and now, apps for Android and iOS. The Mobile development with C++ workload is an installable
set of components in Visual Studio that includes cross-platform iOS, Android, and UWP Visual Studio templates.
It installs the cross-platform tools and SDKs you need to get started quickly, without having to locate, download,
and configure them yourself. You can use these tools in Visual Studio to easily create, edit, debug, and test your
cross-platform projects. This topic describes how to install the tools and third-party software required to develop
cross-platform apps in C++ using Visual Studio. For an overview, see Visual C++ cross-platform mobile
Requirements
For installation requirements, see Visual Studio product family system requirements.
IMPORTANT
If you are using Windows 7 or Windows Server 2008 R2, you can develop code for Windows Desktop applications,
Android Native Activity apps and libraries, and apps and code libraries for iOS, but not Windows Phone or UWP
apps.
To build apps for specific device platforms, there are some additional requirements:
Windows Phone emulators and the Microsoft Visual Studio Emulator for Android require a computer that
can run Hyper-V. The Hyper-V feature in Windows must be enabled before you can install and run the
emulators. For more information, see the emulator's system requirements.
The x86 Android emulators that come with the Android SDK work best on computers that can run the Intel
HAXM driver. This driver requires an Intel x64 processor with VT-x and Execute Disable Bit support. For
more information, see Intel® Hardware Accelerated Execution Manager (Intel® HAXM ).
Building code for iOS requires an Apple ID, an iOS Developer Program account, and a Mac computer that
can run Xcode version 6 or later on OS X Mavericks (version 10.9) or later versions. For a link to installation
steps, see Install tools for iOS.
Get the tools

Mobile development with C++ is available in Visual Studio Community, Professional, and Enterprise editions. To
get Visual Studio, go to the Visual Studio downloads page. The cross-platform mobile development tools are
available starting in Visual Studio 2015 Update 2 or later.
Install the tools

The Visual Studio Installer for Visual Studio 2017 includes a Mobile development with C++ workload that
installs the C++ language tools, templates, and components required for Android and iOS development in Visual
Studio. It installs the GCC and Clang toolsets needed for Android builds and debugging, and components to
communicate with a Mac for iOS development. It also installs all the third-party tools and software development
kits that are required to support iOS and Android app development. Most of these third-party tools are open-
source software required for Android platform support.
Android Native Development Kit (NDK) is required to build C++ code that targets the Android platform.
Android SDK, Apache Ant, and Java SE Development Kit are required for the Android build process.
The Google Android Emulator and Intel Hardware Accelerated Execution Manager are optional, but
recommended, components. You can develop and debug directly on an Android device, but it's often easier
to use an emulator on your desktop for debugging. Microsoft also provides a Visual Studio Emulator for
Android that can be installed separately.
To install the Mobile development with C++ workload in Visual Studio 2017
1. Run the Visual Studio Installer from the Start menu.
2. If you've already installed Visual Studio, choose the Modify button for the installed version of Visual
Studio you'd like to modify. Otherwise, choose Install to install Visual Studio.
3. With the Workloads tab selected, scroll down and select the Mobile development with C++ workload in
the Visual Studio Installer. When this workload is selected, other required components for C++
development are also selected. You can also choose other workloads and individual components to install at
the same time. To build cross-platform code that also targets UWP, select the Universal Windows
Platform development workload.
4. In the Installation details pane, expand Mobile development with C++. In the Optional section, you
can choose additional versions of the NDK, the Google Android Emulator, the Intel Hardware Accelerated
Execution Manager, and the IncrediBuild build acceleration tool.
5. By default, one or more Android SDK setup components are included by the workload. Additional versions
of the Android SDK are available. To add one to your installation, choose the Individual components tab,
then scroll down to the SDKs, libraries, and frameworks section to make your selection.
6. Choose the Modify or Install button to install the Mobile development with C++ workload and your
other selected workloads and optional components.
When installation is complete, close the installer and then restart your computer. Some setup actions for
the third-party components do not take effect until the computer is restarted.
IMPORTANT
You must restart to make sure everything is installed correctly.
7. Open Visual Studio. If this is the first time that you have run Visual Studio, it may take some time to
configure and sign in. When Visual Studio is ready, check for any updates and install them.
To install the Mobile Development component and third-party tools in Visual Studio 2015
If you are using Visual Studio 2015, its installer includes an option to install Visual C++ for Cross-Platform
Mobile Development, which installs the required C++ language tools, templates, and components in Visual Studio
2015.
1. Run the Visual Studio 2015 installer. To install optional components, choose Custom as the type of
installation. Choose Next to select the optional components to install.
2. In Select features, expand Cross Platform Mobile Development and check Visual C++ Mobile
Development.
By default, when you select Visual C++ Mobile Development, the Programming Languages option is
set to install Visual C++, and the Common Tools and Software Development Kits options are set to
install required third-party components. You can choose additional components if you need them. By
default, the Microsoft Visual Studio Emulator for Android is also selected. Components that are
already installed appear inactive in the list.
To build Universal Windows apps and share code between them and your Android and iOS projects, in
Select features, expand Windows and Web Development and check Universal Windows App
Development Tools. If you don't plan to build Universal Windows apps, you can skip this option.
Choose Next to continue.
3. The third-party components have their own license terms. You can view the license terms by choosing the
License Terms link next to each component. Choose Install to add the components and install Visual
Studio and Visual C++ for Cross-Platform Mobile Development.
4. When installation is complete, close the installer and then restart your computer. Some setup actions for
the third-party components do not take effect until the computer is restarted.
IMPORTANT
You must restart to make sure everything is installed correctly.
If the Microsoft Visual Studio Emulator for Android component failed to install, your computer may not
have Hyper-V enabled. Use the Turn Windows features on or off Control Panel app to enable Hyper-V,
and then run the Visual Studio installer again.
NOTE
If your computer or your version of Windows does not support Hyper-V, you can't use the Microsoft Visual Studio
Emulator for Android component. The Home Edition of Windows does not include Hyper-V support.
5. Open Visual Studio. If this is the first time that you have run Visual Studio, it may take some time to
configure and sign in. When Visual Studio is ready, on the Tools menu, select Extensions and Updates,
Updates. If there are Visual Studio updates available for Visual C++ for Cross-Platform Mobile
Development or for Microsoft Visual Studio Emulator for Android, install them.
Install tools for iOS

You can use Visual C++ for Cross-Platform Mobile Development to edit, debug, and deploy iOS code to the iOS
Simulator or to an iOS device, but because of licensing restrictions, the code must be built remotely on a Mac. To
build and run iOS apps using Visual Studio, you must set up and configure the remote agent on your Mac. For
detailed installation instructions, prerequisites and configuration options, see Install and configure tools to build
using iOS. If you're not building for iOS, you can skip this step.
Install or update dependencies manually

If you decide not to install one or more third-party dependencies using the Visual Studio installer when you install
the Mobile development with C++ workload (or in Visual Studio 2015, the Visual C++ Mobile Development
option), you can install them later by using the steps in Install the tools. The Visual Studio Installer is updated
regularly to install the latest third-party components. You can use it to install updated SDKs and NDKs. You can
also install or update them independently of Visual Studio.
Cau t i on
You can install the dependencies in any order, except for Java. You must install and configure the JDK before you
install the Android SDK.
Read the following information and use these links to install dependencies manually.
Java SE Development Kit
By default, the installer puts the Java tools in C:\Program Files (x86 )\Java.
Android SDK
During the installation, update the APIs as recommended. Make sure that at least the SDK for Android 5.0
Lollipop (API level 21) is installed. By default, the installer puts the Android SDK in C:\Program Files
(x86 )\Android\android -sdk.
You can run the SDK Manager app in the Android SDK directory again to update the SDK and install
optional tools and additional API levels. Updates may fail to install unless you use Run as administrator
to run the SDK Manager app. If you have problems building an Android app, check the SDK Manager for
updates to your installed SDKs.
To use some of the Android emulators that come with the Android SDK, you must install the optional Intel
HAXM drivers. You may have to remove the Hyper-V feature from Windows to install the Intel HAXM
drivers successfully. You must restore the Hyper-V feature to use the Windows Phone emulators and the
Microsoft Visual Studio Emulator for Android. For more information, see Android Emulator hardware
acceleration.
Android NDK
By default, the installer puts the Android NDK in C:\ProgramData\Microsoft\AndroidNDK. You can
download and install the Android NDK again to update the NDK installation.
Apache Ant
By default, the installer puts Apache Ant in C:\Program Files (x86 )\Microsoft Visual Studio 14.0\Apps.
Microsoft Visual Studio Emulator for Android
Microsoft Visual Studio Emulator for Android is an optional emulator useful for testing and debugging
your code. After the release of Visual Studio Emulator for Android, Google updated their Android emulator
to use hardware acceleration through Intel’s HAXM. We recommend you use Google’s accelerated
emulator when you can, as it offers access to the latest Android OS images and Google Play services.
In most cases, Visual Studio can detect the configurations for the third-party software you've installed, and
maintains the installation paths in internal environment variables. You can override the default paths of these
cross-platform development tools in the Visual Studio IDE.
To set the paths for third-party tools
1. On the Visual Studio menu bar, select Tools > Options.
2. In the Options dialog box, select Cross Platform > C++ > Android.
3. To change the path used by a tool, check the checkbox next to the path, and edit the folder path in the
textbox. You can also use the browse button (...) to open a Select location dialog to choose the folder.
4. Choose OK to save the custom tool folder locations.
See also
Install and configure tools to build using iOS
Visual C++ cross-platform mobile
Install and configure tools to build using iOS
You can use Visual C++ for Cross-Platform Mobile Development to edit, debug and deploy iOS code to the iOS
Simulator or to an iOS device, but because of licensing restrictions, the code must be built and run remotely on a
Mac. To build and run iOS apps using Visual Studio, you need to set up and configure the remote agent,
vcremote, on your Mac. The remote agent handles build requests from Visual Studio and runs the app on an iOS
device connected to the Mac, or in the iOS Simulator on the Mac.
NOTE
For information on using cloud-hosted Mac services instead of a Mac, see Configure Visual Studio to connect to your cloud
hosted Mac. The instructions are for building using Visual Studio Tools for Apache Cordova. To use the instructions to build
using C++, substitute vcremote for remotebuild.
Once you have installed the tools to build using iOS, refer to this topic for ways to quickly configure and update
the remote agent for iOS development in Visual Studio and on your Mac.
Prerequisites
To install and use the remote agent to develop code for iOS, you must first have these prerequisites:
A Mac computer running OS X Mavericks (version 10.9) or later
An Apple ID
An active iOS Developer Program account with Apple
Xcode version 6 or later.
Xcode can be downloaded from the App Store.
Xcode command line tools
To install the Xcode command line tools, open the Terminal app on your Mac and enter the following
command:
xcode-select --install
An iOS signing identity configured in Xcode

For detailed information on obtaining an iOS Signing Identity, see Maintain your signing identities and
certificates in the iOS Developer Library. To see or set your signing identity in Xcode, open the Xcode
menu and choose Preferences. Select Accounts and choose your Apple ID, and then choose the View
Details button.
If you are using an iOS device for development, a Provisioning Profile configured in Xcode for your device
For detailed information on creating provisioning Profiles, see Create provisioning profiles using Member
Center in the iOS Developer Library.
Node.js
Install the latest Long Term Support (LTS ) version 8.x of Node.js on your Mac. Note that other latest
release versions may not support some modules used in vcremote and can cause vcremote installation to
fail.
An updated version of npm
The version of npm that comes with Node.js may not be recent enough to install vcremote. To update npm,
open the Terminal app on your Mac and enter the following command:
sudo npm install -g npm@latest
Install the remote agent for iOS

When you install Visual C++ for Cross-Platform Mobile Development, Visual Studio can communicate with
vcremote, a remote agent running on your Mac to transfer files, build and run your iOS app, and send debugging
commands.
Before you install the remote agent, make sure you have satisfied the Prerequisites and installed Visual C++ for
cross-platform mobile development.
To download and install the remote agent
From the Terminal app on your Mac, enter:
sudo npm install -g --unsafe-perm vcremote
The global installation (-g) switch is recommended but not required.

During the installation, vcremote is installed and developer mode is activated on your Mac. Homebrew
and two npm packages, vcremote-lib and vcremote-utils, are also installed. When installation completes,
it's safe to ignore any warnings about skipped optional dependencies.
NOTE
To install Homebrew, you must have sudo (administrator) access. If you need to install vcremote without sudo, you
can install Homebrew manually in a usr/local location and add its bin folder to your path. For more information, see
the Homebrew documentation. To manually enable developer mode, enter this command in the Terminal app:
DevToolsSecurity -enable
If you update to a new version of Visual Studio, you must update to the current version of the remote agent as
well. To update the remote agent, repeat the steps to download and install the remote agent.
Start the remote agent

The remote agent must be running for Visual Studio to build and run your iOS code. Visual Studio must be
paired with the remote agent before it can communicate. By default, the remote agent runs in secured connection
mode, which requires a PIN to pair with Visual Studio.
To start the remote agent
From the Terminal app on your Mac, enter:
vcremote
This starts the remote agent with a default build directory of ~/vcremote. For additional configuration
options, see Configure the remote agent on the Mac.
The first time you start the agent, and any time you create a new client certificate, you are provided with the
required information to configure the agent in Visual Studio, including the host name, the port, and the PIN.
If you intend to configure the remote agent in Visual Studio using the host name, ping the Mac from Windows
using the host name to verify that it is reachable. Otherwise, you may need to use the IP address instead.
The generated PIN is for one time use, and is only valid for a limited time. If you do not pair Visual Studio with
the remote agent before the time expires, you will need to generate a new PIN. For more information, see
Generate a new security PIN.
You can use the remote agent in unsecured mode. In unsecured mode, the remote agent can be paired to Visual
Studio without a PIN.
To disable secured connection mode
To disable secured connection mode in vcremote, enter this command in the Terminal app on your Mac:
vcremote --secure false
To enable secured connection mode

To enable secured connection mode, enter this command:
vcremote --secure true
Once you have started the remote agent, you can use it from Visual Studio until you stop it.
To stop the remote agent
In the Terminal window vcremote is running in, enter Control+C.
Configure the remote agent in Visual Studio

To connect to the remote agent from Visual Studio, you must specify the remote configuration in the Visual
Studio options.
To configure the remote agent from Visual Studio
1. If the agent is not already running on your Mac, follow the steps in Start the remote agent. Your Mac must
be running vcremote for Visual Studio to successfully pair, connect and build your project.
2. On your Mac, get the host name or IP address of your Mac.
You can get the IP address by using the ifconfig command in a Terminal window. Use the inet address
listed under the active network interface.
3. On the Visual Studio menu bar, choose Tools, Options.
4. In the Options dialog box, expand Cross Platform, C++, iOS.
5. In the Host Name and Port fields, enter the values specified by the remote agent when you started it. The
host name can be the DNS name or IP address of your Mac. The default port is 3030.
NOTE
If you cannot ping the Mac using the host name, you may need to use the IP address.
6. If you use the remote agent in the default secured connection mode, check the Secure checkbox, then
enter the PIN value specified by the remote agent in the Pin field. If you use the remote agent in
unsecured connection mode, clear the Secure checkbox and leave the Pin field blank.
7. Choose Pair to enable the pairing.
The pairing persists until you change the host name or port. If you change the host name or port in the
Options dialog box, to undo the change, choose the Revert button to revert to the previous pairing.
If the pairing does not succeed, verify that the remote agent is running by following the steps in Start the
remote agent. If too much time has passed since the remote agent PIN was generated, follow the steps in
Generate a new security PIN on the Mac and then try again. If you are using the host name of your Mac,
try using the IP address in the Host Name field instead.
8. Update the folder name in the Remote Root field to specify the folder used by the remote agent in your
home (~) directory on the Mac. By default, the remote agent uses /Users/ username /vcremote as the
remote root.
9. Choose OK to save the remote pairing connection settings.
Visual Studio uses the same information to connect to the remote agent on your Mac each time you use it. You
do not need to pair Visual Studio with the remote agent again unless you generate a new security certificate on
your Mac, or its hostname or IP address changes.
Generate a new security PIN

When you start the remote agent the first time, the generated PIN is valid for a limited amount of time—by
default, 10 minutes. If you don't pair Visual Studio to the remote agent before the time expires, you will need to
generate a new PIN.
To generate a new PIN
1. Stop the agent, or open a second Terminal app window on your Mac and use that to enter the command.
2. Enter this command in the Terminal app:
vcremote generateClientCert
The remote agent generates a new temporary PIN. To pair Visual Studio by using the new PIN, repeat the
steps in Configure the remote agent in Visual Studio.
Generate a new server certificate

For security purposes, the server certificates that pair Visual Studio with the remote agent are tied to the IP
address or host name of your Mac. If these values change, you must generate a new server certificate, and then
reconfigure Visual Studio with the new values.
To generate a new server certificate
1. Stop the vcremote agent.
vcremote resetServerCert
3. When prompted for confirmation, enter Y .

vcremote generateClientCert
This generates a new temporary PIN.

5. To pair Visual Studio by using the new PIN, repeat the steps in Configure the remote agent in Visual
Studio.
Configure the remote agent on the Mac

You can configure the remote agent using various command line options. For example, you can specify the port
to listen for build requests and specify the maximum number of builds to maintain on the file system. By default,
the limit is 10 builds. The remote agent will remove builds that exceed the maximum on shutdown.
To configure the remote agent
To see a complete list of remote agent commands, in the Terminal app, enter:
vcremote --help
To disable secure mode and enable simple HTTP based connections, enter:
vcremote --secure false
When you use this option, clear the Secure checkbox and leave the Pin field blank when configuring the
agent in Visual Studio.
To specify a location for remote agent files, enter:
vcremote --serverDir directory_path
where directory_path is the location on your Mac to place log files, builds, and server certificates. By
default, this location is /Users/<username>/vcremote. Builds are organized by build number in this
location.
To use a background process to capture stdout and stderr to a file named server.log, enter:
vcremote > server.log 2>&1 &
The server.log file can assist in troubleshooting build issues.

To run the agent by using a configuration file instead of command-line parameters, enter:
vcremote --config config_file_path
where config_file_path is the path to a configuration file in JSON format. The startup options and their
values must not include dashes.
See also
Install Visual C++ for cross-platform mobile development
Create an Android Native Activity App
When you install the Visual C++ for Cross-Platform Mobile Development option, Visual Studio 2015 can be used
to create fully functional Android Native Activity apps. The Android Native Development Kit (NDK) is a toolset that
allows you to implement the majority of your Android app using pure C/C++ code. Some Java JNI code acts as
glue to allow your C/C++ code to interact with Android. The Android NDK introduced the ability to create Native
Activity apps with Android API Level 9. Native Activity code is popular for creating gaming and graphic intensive
apps that use Unreal Engine or OpenGL. This topic will guide you through creation of a simple Native Activity app
that uses OpenGL. Additional topics walk through the developer lifecycle of editing, building, debugging and
deploying Native Activity code.
Requirements
Before you can create an Android Native Activity app, you must make sure you've met all system requirements,
and installed the Visual C++ Mobile Development option in Visual Studio 2015. For more information, see Install
Visual C++ for Cross-Platform Mobile Development. Make sure that the required third-party tools and SDKs are
included in the installation, and that the Microsoft Visual Studio Emulator for Android is installed.
Create a new Native Activity project

In this tutorial, you'll first create a new Android Native Activity project and then build and run the default app in the
Visual Studio Emulator for Android.
To create a new project
1. Open Visual Studio. On the menu bar, choose File > New > Project.
2. In the New Project dialog box, under Templates, choose Visual C++ > Cross Platform, and then choose
the Native-Activity Application (Android) template.
3. Give the app a name like MyAndroidApp , and then choose OK.
Visual Studio creates the new solution and opens Solution Explorer.
The new Android Native Activity app solution includes two projects:
MyAndroidApp.NativeActivity contains the references and glue code for your app to run as a Native Activity
on Android. The implementation of the entry points from the glue code are in main.cpp. Precompiled
headers are in pch.h. This Native Activity app project is compiled into a shared library .so file which is picked
up by the Packaging project.
MyAndroidApp.Packaging creates the .apk file for deployment on an Android device or emulator. This contains
the resources and AndroidManifest.xml file where you set manifest properties. It also contains the build.xml
file that controls the Ant build process. It's set as the startup project by default, so that it can be deployed
and run directly from Visual Studio.
Build and run the default Android Native Activity app
Build and run the app generated by the template to verify your installation and setup. For this initial test, run the
app on one of the device profiles installed by the Visual Studio Emulator for Android. If you prefer to test your app
on another target, you can load the target emulator or connect the device to your computer.
To build and run the default Native Activity app

1. If it is not already selected, choose x86 from the Solution Platforms dropdown list.
If the Solution Platforms list isn't showing, choose Solution Platforms from the Add/Remove Buttons
list, and then choose your platform.
2. On the menu bar, choose Build > Build Solution.
The Output window displays the output of the build process for the two projects in the solution.
3. Choose one of the VS Emulator Android Phone (x86) profiles as your deployment target.
If you have installed other emulators or connected an Android device, you can choose them in the
deployment target dropdown list.
4. Press F5 to start debugging, or Shift+F5 to start without debugging.
Here's what the default app looks like in the Visual Studio emulator for Android.
Visual Studio starts the emulator, which takes a few seconds to load and deploy your code. Once your app
has started, you can set breakpoints and use the debugger to step through code, examine locals, and watch
values.
5. Press Shift+F5 to stop debugging.
The emulator is a separate process that continues to run. You can edit, compile, and deploy your code
multiple times to the same emulator.
Build an OpenGL ES application on Android and iOS
When you install the Visual C++ for Cross-Platform Mobile Development option, you can create Visual Studio
solutions and projects for iOS apps and Android apps that share common code. This topic guides you through a
solution template that creates both a simple iOS app and an Android Native Activity app. The apps have C++ code
in common that uses OpenGL ES to display the same animated rotating cube on each platform. OpenGL ES
(OpenGL for Embedded Systems or GLES ) is a 2D and 3D graphics API that is supported on many mobile
devices.
Requirements
Before you can create an OpenGL ES app for iOS and Android, you must make sure you've met all system
requirements. You must install the Visual C++ for Cross-Platform Mobile Development option in Visual Studio
2015. Make sure that the required third-party tools and SDKs are included in the installation, and that the Visual
Studio Emulator for Android is installed. For more information and detailed instructions, see Install Visual C++ for
cross-platform mobile development. To build and test the iOS app, you'll need a Mac computer, set up according to
the installation instructions. For more information about how to set up for iOS development, see Install and
configure tools to build using iOS
Create a new OpenGLES Application project

In this tutorial, you first create a new OpenGL ES Application project and then build and run the default app in the
Visual Studio Emulator for Android. Next you build the app for iOS and run the app in the iOS Simulator.
To create a new project
1. Open Visual Studio. On the menu bar, choose File, New, Project.
2. In the New Project dialog box, under Templates, choose Visual C++, Cross Platform, and then choose
the OpenGLES Application (Android, iOS ) template.
3. Give the app a name like MyOpenGLESApp , and then choose OK.
Visual Studio creates the new solution and opens Solution Explorer.
The new OpenGL ES Application solution includes three library projects and two application projects. The
Libraries folder includes a shared code project and two platform-specific projects that reference the shared
code:
MyOpenGLESApp.Android.NativeActivity contains the references and glue code that implements your app as a
Native Activity on Android. The implementation of the entry points from the glue code are in main.cpp,
which includes the common shared code in MyOpenGLESApp.Shared . Precompiled headers are in pch.h. This
Native Activity app project is compiled into a shared library (.so) file which is picked up by the
MyOpenGLESApp.Android.Packaging project.
MyOpenGLESApp.iOS.StaticLibrary creates an iOS static library ( .a) file that contains the shared code in
MyOpenGLESApp.Shared . It is linked to the app created by the MyOpenGLESApp.iOS.Application project.
MyOpenGLESApp.Shared contains the shared code that works across platforms. It uses preprocessor macros
for conditional compilation of platform-specific code. The shared code is picked up by project reference in
both MyOpenGLESApp.Android.NativeActivity and MyOpenGLESApp.iOS.StaticLibrary .
The solution has two projects to build the apps for the Android and iOS platforms:
MyOpenGLESApp.Android.Packaging creates the .apk file for deployment on an Android device or emulator.
This contains the resources and AndroidManifest.xml file where you set manifest properties. It also contains
the build.xml file that controls the Ant build process. It's set as the startup project by default, so that it can
be deployed and run directly from Visual Studio.
MyOpenGLESApp.iOS.Application contains the resources and Objective-C glue code to create an iOS
app that links to the C++ static library code in MyOpenGLESApp.iOS.StaticLibrary . This project creates a build
package that is transferred to your Mac by Visual Studio and the remote agent. When you build this project,
Visual Studio sends the files and commands to build and deploy your app on the Mac.
Build and run the Android app

The solution created by the template sets the Android app as the default project. You can build and run this app to
verify your installation and setup. For an initial test, run the app on one of the device profiles installed by the Visual
Studio Emulator for Android. If you prefer to test your app on another target, you can load the target emulator or
connect the device to your computer.
To build and run the Android Native Activity app
1. If it is not already selected, choose x86 from the Solution Platforms drop-down list.
Use x86 to target the Android Emulator for Windows. If you are targeting a device, choose the solution
platform based on the device processor. If the Solution Platforms list isn't displayed, choose Solution
Platforms from the Add/Remove Buttons list, and then choose your platform.
2. In Solution Explorer, open the shortcut menu for MyOpenGLESApp.Android.Packaging project and then
choose Build.
The Output window displays the output of the build process for the Android shared library and the Android
app.
3. Choose one of the VS Emulator Android Phone (x86) profiles as your deployment target.
If you have installed other emulators or connected an Android device, you can choose them in the
deployment target drop-down list. To run the app, the built Solution Platform must match the platform of
the target device.
4. Press F5 to start debugging, or Shift+F5 to start without debugging.
Visual Studio starts the emulator, which takes several seconds to load and deploy your code. Here's how the
app appears in the Visual Studio emulator for Android.
Once your app has started, you can set breakpoints and use the debugger to step through code, examine
locals, and watch values.
The emulator is a separate process that continues to run. You can edit, compile, and deploy your code
multiple times to the same emulator. Your app appears in the app collection on the emulator, and it can be
started from there directly.
The generated Android Native Activity app and library projects put the C++ shared code in a dynamic
library that includes "glue" code to interface with the Android platform. This means most of the app code is
in the library, and the manifest, resources, and build instructions are in the packaging project. The shared
code is called from main.cpp in the NativeActivity project. For more information about how to program an
Android Native Activity, see the Android Developer NDK Concepts page.
Visual Studio builds Android Native Activity projects by using the Android NDK, which uses Clang as the
platform toolset. Visual Studio maps the properties in the NativeActivity project to the command-line
switches and options that are used to compile, link, and debug on the target platform. For details, open the
Property Pages dialog for the MyOpenGLESApp.Android.NativeActivity project. For more information
about the command line switches, see the Clang Compiler User's Manual.
Build and run the iOS app

The iOS app project is created and edited in Visual Studio, but because of licensing restrictions, it must be built
and deployed from a Mac. Visual Studio communicates with a remote agent running on the Mac to transfer
project files and execute build, deployment, and debugging commands. You must set up and configure your Mac
and Visual Studio to communicate before you can build the iOS app. For detailed instructions, see Install and
configure tools to build using iOS. Once the remote agent is running and Visual Studio is paired with your Mac,
you can build and run the iOS app to verify your installation and setup.
To build and run the iOS app
1. Verify that the remote agent is running on your Mac, and that Visual Studio is paired to the remote agent.
To start the remote agent, open a Terminal app window and enter vcremote . For more information, see
Configure the remote agent in Visual Studio.
2. If it is not already selected, choose x86 from the Solution Platforms drop-down list.
Use x86 to target the iOS Simulator. If you are targeting an iOS device, choose the solution platform based
on the device processor (usually an ARM processor). If the Solution Platforms list isn't displayed, choose
Solution Platforms from the Add/Remove Buttons list, and then choose your platform.
3. In Solution Explorer, open the shortcut menu for the MyOpenGLESApp.iOS.Application project and choose
Build.
The Output window displays the output of the build process for the iOS static library and the iOS app. On
the Mac, the Terminal window running the remote agent shows the command and file transfer activity.
On your Mac computer, you may be prompted at accept a code signing request. Choose Allow to continue.
4. Choose iOS Simulator on the toolbar to run the app in the iOS Simulator on your Mac. It may take a
moment to start the simulator. You may have to bring the simulator to the foreground on your Mac to see
its output.
Once your app has started, you can set breakpoints and use the Visual Studio debugger to examine locals,
see the call stack, and watch values.

The iOS Simulator is a separate process that continues to run on your Mac. You can edit, compile, and
deploy your code multiple times to the same iOS Simulator instance. You can also run your code directly in
the simulator after it has been deployed.
The generated iOS app and library projects put the C++ code in a static library that implements only the
shared code. Most of the application code is in the Application project. The calls to the shared library code
in this template project are made in the GameViewController.m file. To build your iOS app, Visual Studio
uses the Xcode platform toolset, which requires communication with a remote client that is running on a
Mac.
Visual Studio transfers the project files and sends commands to the remote client to build the app using
Xcode. The remote client sends build status information back to Visual Studio. When the app has built
successfully, you can use Visual Studio to send commands to run and debug the app. The debugger in
Visual Studio controls the app running in the iOS Simulator running on your Mac, or on an attached iOS
device. Visual Studio maps the properties in the StaticLibrary project to the command-line switches and
options that are used to build, link, and debug on the target iOS platform. For compiler command-line
option details, open the Property Pages dialog for the MyOpenGLESApp.iOS.StaticLibrary project.
Customize your apps

You can modify the shared C++ code to add or change common functionality. You must change the calls to the
shared code in the MyOpenGLESApp.Android.NativeActivity and MyOpenGLESApp.iOS.Application projects to match.
You can use preprocessor macros to specify platform-specific sections in your common code. The preprocessor
macro __ANDROID__ is predefined when you build for Android. The preprocessor macro __APPLE__ is predefined
when you build for iOS.
To see the IntelliSense for a particular project platform, choose the project in the context switcher dropdown in the
Navigation bar at the top of the editor window.
IntelliSense issues in the current project are marked with a red wavy line. Issues in other projects are marked with
a purple wavy line. By default, Visual Studio does not support code colorization or IntelliSense for Java or
Objective-C files. However, you can still modify the source files and change the resources to set your application
name, icon, and other implementation details.
Import an XCode Project
Microsoft Visual C++ for Cross-Platform Mobile Development includes support for moving your XCode projects
into Visual Studio, where you can create cross-platform libraries and share code with other projects. The Import
from XCode wizard simplifies the process of importing projects and splitting out the C++ code in your XCode
targets for use as a static library or shared code project. You can manage your iOS -specific code in Visual Studio
and still use XCode to do storyboards and builds. For information on how to easily move code back and forth
between Visual Studio and XCode, see Move Changes Between XCode and Visual Studio.
Use the Import From XCode wizard

This topic shows you how to move an XCode project into Visual Studio to take advantage of code sharing and
cross-platform solutions. As a prerequisite, you must pair your Mac to Visual Studio to be able to import, export,
and build your project. For instructions on how to set up pairing, see Install and configure tools to build using iOS.
You must also share your XCode project over the network or move it to your Visual Studio computer to use the
Import from XCode wizard.
Import from XCode
1. On the File menu, choose New, Import, Import from XCode. This starts the Import from XCode wizard
dialog.
2. In the Choose a project pane, choose the Browse button to select an XCode .pbxproj file. Navigate to the
project file in the Select XCode project file dialog, and then choose Open.
In the Import from XCode wizard, choose Next.
3. In the Destination targets pane, choose the targets from the XCode project to import into Visual Studio
projects. XCode targets are similar to Visual Studio projects; most are a collection of code and resources that
produce a binary. The Import from XCode wizard only allows import of targets that produce a binary, but
not a static library, as destination targets. XCode static library targets are the subject of the next step.
For each target selected in Targets to import, the wizard automatically detects C++ code files that can be
split into a separate static library project, and puts them in the C++ project items section. Other code and
resources are left in the XCode project items section. These become separate static library and application
projects in Visual Studio when the wizard completes the import process. By default, unit test and framework
targets are not split into separate projects by the wizard.
To change which files are in each project, use the up and down buttons. When you are satisfied with the files
in each project, choose Next to continue.
4. In the Library targets pane, choose which static library targets from the XCode project to import into
Visual Studio projects. In this pane, you can choose which files are placed in a Shared Code project, and
which are placed in a static library project. In each of targets in the Targets to import list, you can control
which files are placed in the Shared Code project items and the Static Library project items by using
the up and down buttons.
A Shared Code project is a way of sharing a set of source code files between projects in Visual Studio. The
code is built as part of the project that includes it, not as a project of its own. Because the projects that
include the shared code may have different architectures and configurations, this is the best way to provide a
single project that contains code that may be built for many kinds of platforms.
When you are satisfied with the files in each project, choose Next to continue.
5. The Global Properties pane can be used to set a framework search path and an include header search path
for all iOS projects in Visual Studio. Visual Studio uses these paths for source code browsing and for
IntelliSense. These global paths are useful when you create iOS projects that use a common set of headers
and frameworks.
These global paths can also be set in Visual Studio in the Options dialog. To find them, on the Tools menu,
select Options. In the Options dialog, expand Cross Platform, C++, iOS, Global Properties.
6. The Frameworks pane is used to configure the paths used by Visual Studio for browsing and IntelliSense
for your project. The paths must be accessible to Visual Studio for each framework referenced by your
XCode project. The wizard checks the framework references in the XCode projects and displays whether
Visual Studio can find the framework. Any path you have already set up in the Global Properties should be
discovered by Visual Studio. The exceptions are listed in the Frameworks list. For each framework listed with
an X, provide a PC accessible path for Visual Studio to find the framework. You can use the browse button ...
to use a Select Folder dialog to find the path. The framework path can be either to a local copy, or to a
network-accessible share on your Mac.
7. The Project Settings pane allows you to change the framework and include header search path settings for
each project the wizard creates. Use this pane to set project-specific paths that differ from the global
settings.
To set a path for a specific project, In the Destination project drop-down, select the project file, then set the
values in the Framework Search Path and Include Header Search Path controls. You can use the browse
button ... next to each control to use a Select Folder dialog to find the path.
If no remote Mac has been paired with this PC in Visual Studio, the Configure a Remote Machine link is
shown. For instructions on how to set up pairing, see Install and configure tools to build using iOS.
To import the XCode project by using the wizard settings, choose Import.
The Import from XCode wizard creates projects in Visual Studio that correspond to the selected XCode
project targets. The code that can be shared with other C++ projects is split into separate Shared Code and
static library projects. The remaining code is placed in iOS library and application projects that can be built
remotely by Visual Studio. For more information about moving code between Visual Studio and XCode, see
Sync changes between XCode and Visual Studio.
Sync changes between XCode and Visual Studio
The Microsoft Visual C++ for Mobile Development component includes remote capabilities for syncing your work
between your PC and your Mac. When your Visual Studio and Mac machines are paired, new options are available
for iOS Application projects in Visual Studio that you can use to open your project in XCode, move your code
between XCode and Visual Studio, and clean the temporary XCode project directory.
To use the Remote Machine options, your project must be an iOS Application project, and Visual Studio must be
paired with your Mac. For prerequisites and instructions on how to pair a Mac, see Install and configure tools to
build using iOS.
The Remote Machine menu

In Solution Explorer, right-click on an iOS Application project to show the context menu. Select the Remote
Machine item to show the remote options available.
These commands let you open your project in XCode, move local changes or the entire project between Visual
Studio and XCode, and clean the temporary files on the remote machine.
Open in XCode
To open the project in XCode from Visual Studio, on the Remote Machine submenu, choose Open in XCode to
open the selected project on the paired remote machine. The vcremote server is used to open XCode on your Mac
and navigate to a temporary directory created on your Mac that contains a copy of the project. Visual Studio pops
up a dialog that shows the temporary directory used for the project. The actions taken on the remote machine are
also shown in the Output window in Visual Studio. To see them, you may need to select Visual C++ Remote
Machine in the Show output from dropdown at the top of the Output window.
On your Mac, you can use all the XCode tools to edit your code and resources, storyboards and actions. In Visual
Studio, your iOS Application project is annotated with "Opened in XCode" to indicate that changes may be made
on the remote machine. Once your edits are complete, you can use the Pull from Remote or Incremental Pull from
Remote commands to copy the changes back into your Visual Studio project.
Push to Remote and Incremental Push to Remote
If you have made changes to your iOS Application project in Visual Studio, the Push to Remote and Incremental
Push to Remote commands can be used to move the changed project files to the paired remote machine. The Push
to Remote command copies all project files to the remote machine. The Incremental Push to Remote command
only copies changed files to the remote machine. For large projects with small changes, the incremental command
can save time and bandwidth.
To copy the project files to your Mac, in Visual Studio in Solution Explorer, right-click the iOS Application project
to open the context menu. Select Remote Machine and choose either Push to Remote or Incremental Push to
Remote to copy project files from Visual Studio to your Mac.
Pull from Remote and Incremental Pull from Remote
After you make any changes to your project in XCode, move the changes back to Visual Studio to keep the projects
in sync.
To copy the project files from your Mac, in Visual Studio in Solution Explorer, right-click the iOS Application
project to open the context menu. Select Remote Machine and choose either Pull from Remote or Incremental
Pull from Remote to copy project files from your Mac to Visual Studio.
Clean Remote
You can use the Clean Remote command to delete the files in the temporary project directory on the remote
machine. The contents of the directory, including any source files or build products, are removed on your Mac. Be
sure you have synced any changes you want to keep back to Visual Studio by using Pull from Remote or
Incremental Pull from Remote before you use the Clean Remote command.
To clean the temporary project directory on the remote machine, in Visual Studio in Solution Explorer, right-click
the iOS Application project to open the context menu. Select Remote Machine and choose Clean Remote to
remove the project directory files from your Mac.
Cross-platform mobile development examples
Several of the templates installed by Visual C++ for Cross-Platform Mobile Development generate complete
examples that you can use to learn from. Additionally, the Windows Dev Center has several example applications
that you can download and try out in Visual Studio.
hello-jni Android Application Sample
This sample is a port of the Android NDK hello-jni application. The sample demonstrates an end-to-end
Java Native Interface "Hello World" app. It loads a string from a native method implemented in a shared
library, and then displays it in the app.
hello-gl2 Android Application Sample
This sample is a port of the Android NDK hello-gl2 application. The sample demonstrates an end-to-end
Java Native Interface Android OpenGL app. It renders a triangle using the OpenGL ES 2.0 shader APIs.
Bitmap Plasma Android Application Sample
This sample is a port of the Android NDK Bitmap Plasma application. The sample demonstrates an end-to-
end Java Native Interface Android OpenGL ES 2.0 application. It demonstrates direct manipulation of
Android bitmap pixel buffers to generate a plasma effect.
TwoLibs Android Library Sample
This sample is a port of the Android NDK TwoLibs sample. It uses both a dynamically loaded shared library,
and a static C++ Android native library, that implements a method called from a Java Native Interface app.
This sample is a good starting point for developers to understand how to use static/dynamic shared
libraries to build an end-to-end JNI Android application with Visual Studio 2015.
Tea Pot Android Application Sample
This sample is a port of the Android NDK TeaPot application. The sample demonstrates an end-to-end Java
Native Interface Android OpenGL ES 2.0 application.
MoreTeaPots Android Application Sample
This sample is a port of the Android NDK MoreTeaPots application. The sample demonstrates an end-to-
end Java Native Interface Android OpenGL application.
test-libstdcpp Android Library Sample
This sample is a port of the Android NDK test-libstdc++ sample, specifically for use with Visual Studio
2015. This sample is a good starting point for developers to understand how to use the Standard Library.
To open one of the examples in Visual Studio, download the zip file and open the Properties page of the
downloaded file in Explorer. Choose the Unblock button then choose OK. Extract the contents of the zip
file to a convenient location, then open the C++ folder in the extracted sample and open the solution file.
To build the sample, press F7, or on the menu bar, choose Build, Build Solution.
C++ cross-platform property page reference
This section contains information about project properties in C++ cross-platform projects.
General project properties (Android C++)
Android debugger properties
Clang project properties (Android C++)
General project properties (Android C++ Makefile)
Clang linker properties (Android C++)
NMake properties (Android C++)
General Project Properties (Android C++)
PROPERTY DESCRIPTION CHOICES
Output Directory Specifies a relative path to the output

file directory; can include environment
variables.
Intermediate Directory Specifies a relative path to the

intermediate file directory; can include
environment variables.
Target Name Specifies a file name that this project will

generate.
Target Extension Specifies a file extension that this

project will generate. (Example: .exe or
.dll)
Extensions to Delete on Clean Semi-colon delimited wildcard

specification for which files in the
intermediate directory to delete on
clean or rebuild.
Build Log File Specifies the build log file to write to

when build logging is enabled.
Platform Toolset Specifies the toolset used for building

the current configuration; If not set, the
default toolset is used
Configuration Type Specifies the type of output this Dynamic Library (.so) - Dynamic
configuration generates. Library (.so)
Static library (.a) - Static Library (.a)
Utility - Utility
Makefile - Makefile
Target API Level Android NDK API Level targeted by this

configuration.
Use of STL Specifies which C++ Standard Library to Minimal C++ runtime library
use for this configuration. (system)
C++ runtime static library
(gabi++_static)
C++ runtime shared library
(gabi++_shared)
STLport runtime static library
(stlport_static)
STLport runtime shared library
(stlport_shared)
GNU STL static library (gnustl_static)
GNU STL shared library
(gnustl_shared)
LLVM libc++ static library
(c++_static)
LLVM libc++ shared library
(c++_shared)
Thumb Mode Generate code that executes for thumb Thumb

microarchitecture. This is applicable for Arm
arm architecture only. Disabled
Android debugger properties
Debugger Type Specifies which code type to debug. Native Only

Java Only
Debug Target Specifies the emulator or device to use

for debugging. If no emulators are
running, then please use 'Android
Virtual Device (AVD) Manager' to start
a device.
Package to Launch Specifies the location of the .apk that

will be debugged. Choose this option to
specify that a specific Package (APK)
should be started when the application
is debugged.
Launch Activity The Android activity to use to launch

the application, has to match the one
used in manifest. Press Apply to retrieve
the list from AndroidManifest.xml and
populate it dynamically.
Additional Symbol Search Paths Additional search path for debug

symbols.
Additional Java Source Search Paths Additional search paths for Java source
files. (Applies only when Debugger Type
is Java Only.)
Clang project properties (Android C++)
Additional Include Directories Specifies one or more directories to add

to the include path; separate with semi-
colons if more than one. (- I[path]).
Debug Information Format Specifies the type of debugging None - Produces no debugging
information generated by the compiler. information, so compilation may be
faster.
Full Debug Information (DWARF2) -
Generate DWARF2 debug information.
Line Number Information - Generate
Line Number information only.
Object File Name Specifies a name to override the default

object file name; can be file or directory
name. (/Fo[name]).
Warning Level Select how strict you want the compiler Turn Off All Warnings - Disables all
to be about code errors. Other flags compiler warnings.
should be added directly to Additional EnableAllWarnings - Enables all
Options. (/w, /Weverything). warnings, including those disabled by
default.
Treat Warnings As Errors Treats all compiler warnings as errors.

For a new project, it may be best to use
/WX in all compilations; resolving all
warnings will ensure the fewest possible
hard-to-find code defects.
Enable Verbose mode Show commands to run and use

verbose output.
Optimization Specifies the optimization level for the Custom - Custom optimization.
application. Disabled - Disable optimization.
Minimize Size - Optimize for size.
Maximize Speed - Optimize for speed.
Full Optimization - Expensive
optimizations.
Strict Aliasing Assume the strictest aliasing rules. An

object of one type will never be
assumed to reside at the same address
as an object of a different type.
Omit Frame Pointer Suppresses creation of frame pointers

on the call stack.
Enable C++ Exceptions Specifies the model of exception No - Disable exception handling.
handling to be used by the compiler. Yes - Enable exception handling.
Unwind Tables - Generates any
needed static data, but does not affect
the code generated.
Enable Function-Level Linking Allows the compiler to package

individual functions in the form of
packaged functions (COMDATs).
Required for edit and continue to work.
(ffunction-sections).
Enable Data-Level Linking Enables linker optimizations to remove

unused data by emitting each data item
in a separate section.
Enable Advanced SIMD(Neon) Enables code generation for NEON

floating point hardware. This is
applicable for arm architecture only.
Floating-point ABI Selection option to choose the floating Soft - 'Soft' causes compiler to generate
point ABI. output containing library calls for
floating-point operations.
SoftFP - 'SoftFP' allows the generation
of code using hardware floating-point
instructions, but still uses the soft-float
calling conventions.
Hard - 'Hard' allows generation of
floating-point instructions and uses
FPU-specific calling conventions.
Security Check The Security Check helps detect stack- Disable Security Check - Disable
buffer over-runs, a common attempted Security Check.
attack upon a program's security. Enable Security Check - Enable
(fstack-protector). Security Check. (fstack-protector)
Position Independent Code Generate Position Independent Code

(PIC) for use in a shared library.
Use Short Enums Enum type uses only as many bytes

required by input set of possible values.
Enable Run-Time Type Information Adds code for checking C++ object
types at run time (runtime type
information). (frtti, fno-rtti)
C Language Standard Determines the C language standard. Default

C89 - C89 Language Standard.
C99 (GNU Dialect) - C99 (GNU Dialect)
Language Standard.
C11 (GNU Dialect) - C11 (GNU Dialect)
Language Standard.
C++ Language Standard Determines the C++ language Default

standard. C++03 - C++03 Language Standard.
C++11 - C++11 Language Standard.
C++14 - C++14 Language Standard.
C++03 (GNU Dialect) - C++03 (GNU
Dialect) Language Standard.
Preprocessor Definitions Defines a preprocessing symbols for

your source file. (- D)
Undefine Preprocessor Definitions Specifies one or more preprocessor

undefines. (- U [macro])
Undefine All Preprocessor Definitions Undefine all previously defined

preprocessor values. (-undef)
Show Includes Generates a list of include files with

compiler output. (- H)
Precompiled Header Create/Use Precompiled Header:Enables Use - Use a Precompiled Header.

creation or use of a precompiled header Not using Precompiled Headers -
during the build. Not using a Precompiled Header.
Precompiled Header File Specifies header file name to use for

precompiled header file. This file will be
also added to 'Forced Include Files'
during build
Precompiled Header Output File Specifies the directory for the generated
Directory precompiled header. This directory will
be also added to 'Additional Include
Directories' during build
Compile Precompiled Header As Select compile language option for Compile as C Code - Compile as C
precompiled header file (-x c-header, -x Code.
c++-header). Compile as C++ Code - Compile as
C++ Code.
Compile As Select compile language option for .c Default - Default.

and .cpp files. 'Default' will detect based Compile as C Code - Compile as C
on .c or .cpp extention. (-x c, -x c++) Code.
Compile as C++ Code - Compile as
C++ Code.
Forced Include Files one or more forced include files. (-

include [name])
Multi-processor Compilation Multi-processor Compilation.
Additional Options Additional Options.

General project properties (Android C++ Makefile)
Output Directory Specifies a relative path to the output

file directory; can include environment
variables.
Intermediate Directory Specifies a relative path to the

intermediate file directory; can include
environment variables.
Build Log File Specifies the build log file to write to

when build logging is enabled.
Configuration Type Specifies the type of output this Dynamic Library (.so) - Dynamic
configuration generates. Library (.so)
Static library (.a) - Static Library (.a)
Utility - Utility
Makefile - Makefile
Clang Linker properties (Android C++)
Output File The option overrides the default name

and location of the program that the
linker creates. (-o)
Show Progress Prints Linker Progress Messages.
Version The -version option tells the linker to

put a version number in the header of
the executable.
Enable Verbose Output The -verbose option tells the linker to

output verbose messages for
debugging.
Enable Incremental Linking The option tells the linker to enable

incremental linking.
Shared Library Search Path Allows the user to populate the shared
library search path.
Additional Library Directories Allows the user to override the

environmental library path. (- L folder).
Report Unresolved Symbol References This option when enabled will report
unresolved symbol references.
Optimize For Memory Usage Optimize for memory usage, by

rereading the symbol tables as
necessary.
Ignore Specific Default Libraries Specifies one or more names of default

libraries to ignore.
Force Symbol References Force symbol to be entered in the

output file as an undefined symbol.
Debugger Symbol Information Debugger symbol information from the Include All
output file. Omit Unneeded Symbols for
Relocation Processing
Omit Debugger Symbol Information
Only
Omit All Symbol Information
Package Debugger Symbol Information Strip the Debugger Symbols

Information before Packaging. A copy
of the original binary will be used for
debugging.
Map File Name The Map option tells the linker to create
a map file with the user specified name.
Mark Variables ReadOnly After This option marks variables read-only

Relocation after relocation.
Enable Immediate Function Binding This option marks object for immediate
function binding.
Require Executable Stack This option marks output as not

requiring executable stack.
Whole Archive Whole Archive uses all code from

Sources and Additional Dependencies.
Additional Options Additional Options.
Additional Dependencies Specifies additional items to add to the

link command line.
Library Dependencies This option allows specifying additional

libraries to be added to the linker
command line. The additional libraries
will be added to the end of the linker
command line start with lib and end
with .a or .so extension. (-lFILE)
NMake properties (Android C++)
PROPERTY DESCRIPTION
Build Command Line Specifies the command line to run for the 'Build' command.
Rebuild All Command Line Specifies the command line to run for the 'Rebuild All'
command.
Clean Command Line Specifies the command line to run for the 'Clean' command.
Output Specifies the output file to generate.
Preprocessor Definitions Specifies the preprocessor defines used by the source files.
Include Search Path Specifies the include search path for resolving included files.
Forced Includes Specifies the files that are forced included.
Additional Options Specifies additional compiler switches to be used by

IntelliSense when parsing C++ files
Develop apps for the Universal Windows Platform
(UWP)
With the Universal Windows Platform and our one Windows core, you can run the same app on any Windows 10
device, from phones to desktops. Create these Universal Windows apps with Visual Studio and the Universal
Windows App development tools.
Run your app on a Windows 10 phone, a Windows 10 desktop, or an Xbox. It's the same app package! With the
introduction of the Windows 10 single, unified core, one app package can run across all platforms. Several
platforms have extension SDKs that you can add to your app to take advantage of platform-specific behaviors. For
example, an extension SDK for mobile handles the back button being pressed on a Windows phone. If you
reference an extension SDK in your project, then just add runtime checks to test if that SDK is available on that
platform. That's how you can have the same app package for each platform!
What is the Windows core?
For the first time, Windows has been refactored to have a common core across all Windows 10 platforms. There is
one common source, one common Windows kernel, one file I/O stack, and one app model. For the UI, there is just
one XAML UI framework and one HTML UI framework. You can concentrate on creating a great app, because
we've made it easy to have your app run on different Windows 10 devices.
What exactly is the Universal Windows Platform?
The Universal Windows Platform is simply a collection of contracts and versions. These allow you to target where
your app can run. You no longer target an operating system; now you target one or more device families. Learn
more details by reading Intro to the Universal Windows Platform.
Requirements
The Universal Windows App development tools come with emulators that you can use to see how your app looks
on different devices. If you want to use these emulators, you need to install this software on a physical machine.
The physical machine must run Windows 8.1 (x64) Professional edition or higher, and have a processor that
supports Client Hyper-V and Second Level Address Translation (SLAT). The emulators cannot be used when Visual
Studio is installed on a virtual machine.
Here is the list of software that you need:
Windows 10. Visual Studio 2017 supports UWP development only on Windows 10. For more details, see
Visual Studio Platform targeting and System requirements.
Visual Studio. You will also need the optional Universal Windows Platform development workload.
After installing this software, you need to enable your Windows 10 device for development. See Enable your device
for development. You no longer need a developer license for each Windows 10 device.
Universal Windows apps

Choose your preferred development language from C#, Visual Basic, C++ or JavaScript to create a Universal
Windows Platform app for Windows 10 devices. Read Create your first app or watch the Tools for Windows 10
Overview video.
If you have existing Windows Store 8.1 apps, Windows Phone 8.1 apps, or Universal Windows apps that were
created with Visual Studio 2015, you'll need to port these apps to use the latest Universal Windows Platform. See
Move from Windows Runtime 8.x to UWP.
After you create your Universal Windows app, you must package your app to install it on a Windows 10 device or
submit it to the Windows Store. See Packaging apps.
See also
Cross-platform mobile development in Visual Studio
Visual Studio Emulator for Android
The Visual Studio Emulator for Android is a desktop application that emulates an Android device. It provides a
virtualized environment in which you can debug and test Android apps without a physical device. It also provides
an isolated environment for your application prototypes.
IMPORTANT
In most scenarios, the Google Android emulator is recommended for use instead of the Visual Studio Emulator for Android:
Visual Studio Emulator for Android is not supported after Visual Studio 2015.
Emulator images later than Android version 6.0 are not available for Visual Studio Emulator for Android.
The Google Android Emulator now supports Hyper-V.
Visual Studio Tools for Apache Cordova works with the Google Android Emulator. For more information, see Run your
Apache Cordova app on Android (note that you no longer have to disable Hyper-V as explained in this article).
For more information about configuring and using the Google Android Emulator, see Android Emulator setup.
The Visual Studio Emulator for Android is designed to provide comparable performance to an actual device. Before
you publish your app, however, we recommend that you test your app on a physical device.
You can test your app on a unique device profile for each of the Android platforms, screen resolutions, and other
hardware properties supported by Visual Studio Emulator for Android.
Installing and uninstalling

Installing
Visual Studio Emulator for Android is a component of the cross-platform tools available in Visual Studio and will
be installed during a custom Visual Studio setup when you select Cross-Platform Mobile Development, then
Common Tools and Software Development Kits, and then Visual Studio Emulator for Android.
Uninstalling
You can uninstall the Visual Studio Emulator for Android using Add/Remove Programs in the Control Panel.
NOTE
Uninstalling Visual Studio will not uninstall the emulator. You must uninstall the emulator separately.
When you uninstall the Visual Studio Emulator for Android, the Hyper-V Virtual Ethernet Adapters that were
created for the emulator to use are not automatically removed. You can manually remove these virtual adapters (if
not in use) by opening Hyper-V Manager, selecting one of the emulator VHD images, choosing the Networking
tab, and choosing Remove for each of the switches that appears in this tab.
System Requirements and backward compatibility

For important info about the hardware, software, and configuration requirements for Visual Studio Emulator for
Android, see the following topic.
System requirements for the Visual Studio Emulator for Android
Visual Studio Emulator for Android requires Visual Studio 2015; it is not backward compatible with earlier
versions of Visual Studio.
New versions of the emulator are installed on top of old versions (and may, in some cases, replace the old
images, discarding the settings, apps, and files installed on those images).
Networking in the Visual Studio Emulator for Android

The networking connection of the Visual Studio Emulator for Android behaves like the connection of a desktop
computer with these characteristics:
The emulator appears on the network as a separate device with its own IP address.
It does not require any additional networking software that is not already installed with the emulator.
It is not joined to a Windows domain.
To understand the capabilities of the emulator's network connection, think of it as similar to a Wi-Fi
connection from your Android phone to the same network. If an app running on your phone can access a
network resource over its Wi-Fi connection, then an app running on the emulator can also access the same
network resource.
For more info on network requirements, see System requirements for the Visual Studio Emulator for
Android
For info on troubleshooting networking issues, see Troubleshooting the Visual Studio Emulator for Android.
Configure the Visual Studio Emulator for Android

Testing your Android app for compatibility across the staggering variety of Android hardware can be a challenge.
Android phones and tablets in the market span a wide range of versions and screen sizes and come in many
different hardware configurations (RAM, CPUs, architecture, etc.). The Visual Studio Emulator for Android
simplifies this using device profiles. Our set of device profiles represent the most popular hardware in the market,
including devices from Samsung, Motorola, Sony, LG, and more.
In Visual Studio 2015, you can install, uninstall, and start device profiles using the Emulator Manager. Access the
Emulator Manager by choosing Tools, then Visual Studio Emulator for Android.
By default, there are four pre-installed device profiles (KitKat and Lollipop phone/5" and tablet/7" configurations),
as indicated by the white text and icons. Other profiles in the list will appear grayed out until you choose the Install
Profile button and the installation completes. You can filter the list by API Level and click the details arrow on the
bottom right-hand side of a profile to view its full configuration details.
Once you've installed the set of profiles that you'd like to target, you can start these new profiles directly from the
manager by pressing the green Play button. They will also appear in the debug target dropdown menu in any
Visual Studio cross-platform mobile project type.
Features that you can test in the emulator

For detailed information on features you can test in the emulator, see this blog post.
Features that you can't test in the emulator

The following list describes features of the Android platform that you cannot test in the emulator. You have to test
these features on a physical device.
Compass
Gyroscope
Vibration controller
Brightness. Changing the brightness level of the emulator will not visually impact the way the device
appears on your screen.
Support resources
If your host computer meets the system requirements and you encounter an issue not covered in this
troubleshooting guide:
Ask a question on StackOverflow using the android-emulator and the visual-studio tag.
Report an issue using the Send a Smile tool in Visual Studio or in the Emulator Manager.
See also
System requirements for the Visual Studio Emulator for Android Troubleshooting the Visual Studio Emulator for
Android
System requirements for the Visual Studio Emulator
for Android
Visual Studio Emulator for Android runs as a virtual machine on Hyper-V, the virtualization technology for
Windows 8 and later versions. To run the emulator, your computer must meet the requirements to run Hyper-V
as described in this topic.
The setup program tries to configure these prerequisites for you silently when you install the emulator. When
setup successfully configures the prerequisites, the emulator simply works as expected. Otherwise you may have
to enable these prerequisites manually. If you have to configure the prerequisites manually, the steps and tools
are the same steps described here for the Windows Phone Emulator.
IMPORTANT
The setup program for the emulator checks the prerequisites for running Visual Studio Emulator for Android. It displays
warnings if the prerequisites are not present, but it does not require them.
Quick checklist
Here is a quick checklist of the requirements for running the Visual Studio Emulator for Android. For more
detailed info, see the subsequent sections in this topic.
System requirements
Hyper-V support (see Hyper-V requirements below )
6 GB or more of RAM.
64-bit version of the Pro edition of Windows 8, Windows 8.1, Windows10 or higher
A processor that supports SSSE3 or later.
Network requirements
DHCP
Automatically configured DNS and gateway settings
Hyper-V requirements
In the BIOS, the following features must be supported:
Hardware-assisted virtualization
Second Level Address Translation (SLAT)
Hardware-based Data Execution Prevention (DEP )
In Windows, Hyper-V must be enabled and running.
You have to be a member of the local Hyper-V Administrators group.
System requirements
Your computer must meet the following requirements:
Hyper-V support (see Hyper-V requirements)
6 GB or more of RAM.
64-bit version of the Pro edition of Windows 8, Windows 8.1, Windows10 or higher.
To check requirements for RAM and Windows, in Control Panel, choose System and Security, and then choose
System.
Network requirements
Your network must meet the following requirements:
DHCP
The emulator requires DHCP because it configures itself as a separate device on the network with its own
IP address.
Automatically configured DNS and gateway settings
It's not possible to configure DNS and gateway settings manually for the emulator.
To troubleshoot networking issues in the emulator, see the following topics:
Troubleshooting the Visual Studio Emulator for Android
Hyper-V requirements
Hyper-V requirements in the BIOS
Your computer's BIOS must support the following requirements, and they must be enabled:
Hardware-assisted virtualization
Second Level Address Translation (SLAT)
Hardware-based Data Execution Prevention (DEP )
Hyper-V requirements in Windows
When your computer and BIOS settings are already configured to support Hyper-V, the setup program enables
and starts Hyper-V. Otherwise you may have to enable these requirements manually.
REQUIREMENT HOW TO CHECK AND ENABLE THIS REQUIREMENT
Hyper-V must be installed Follow the same instructions used to enable Hyper-V for the
Windows Phone emulator.
Check the status of the Hyper-V Virtual Machine

Management service in the Services snap-in.
Hyper-V must be running. For more info about managing services, see the following
topics:
- Start, stop, pause, resume, or restart a service

- Configure how a service is started
You have to be a member of the local Hyper-V Administrators group.

To run the Visual Studio Emulator for Android without a recurring prompt to elevate your rights, you have to be a
member of the local Hyper-V Administrators group. If you are already a local administrator on the computer
when you install the SDK, the setup program for the SDK adds you to the Hyper-V Administrators group.
Otherwise you may have to enable this requirement manually.
When you run the emulator, if you are not already a member of the Hyper-V Administrators group, you are
prompted to join the group (the dialog box refers to the Windows Phone emulator). Joining the group requires
administrator rights.
IMPORTANT
After you join the group, log off or reboot to make the change take effect.
To add yourself to a group manually, open the Local Users and Groups snap-in.
Running the emulator from a bootable VHD is not supported

If you try to run an app on the Visual Studio Emulator for Android while you are running Windows from a
bootable VHD, the emulator typically takes several minutes to start or fails to start. When the emulator fails to
start, you see the following message: App deployment failed. Please try again.
This configuration is not supported. For information about related issues, see Troubleshoot the Visual Studio
Emulator for Android.
Hyper-V requires uncompressed and unencrypted files

On a hard drive configured with the NTFS file system, the virtual hard disk files used by Hyper-V must be
uncompressed and unencrypted. Make sure that the following directories are not compressed or encrypted:
%localappdata%\Microsoft\XDE
C:\Program Files (x86)\Microsoft Emulator Manager
C:\Program Files (x86)\Microsoft Visual Studio Emulator for Android
%localappdata%\Microsoft\VisualStudioEmulator
On the ReFS file system, the virtual hard disk files must not have the integrity bit set.
Hardware graphics forwarding (OpenGL ES support) requirements

In order for the emulator to emulate calls to the GPU, such as those used by OpenGL ES, your machine must
have a DirectX compatible GPU with appropriate DirectX drivers installed.
See also
This topic contains information to help you resolve issues that you may experience when you're using the Visual
Studio Emulator for Android.
WARNING
When the emulator is installed, the setup program checks the prerequisites for running the software. It displays warnings if
the prerequisites are not present, but it does not require them for installation.
This topic contains the following sections.

Before you start
Emulator fails to install
Cannot connect to network destinations on a domain or corporate network
Cannot connect to network destinations when network settings require manual configuration
Emulator starts slowly, fails to start due to a timeout, or app deployment fails
Emulator fails to start
Emulator fails to start (first use)
Computer fails to boot after installing the Emulator
Visual Studio gets stuck trying to deploy the app to the emulator or the emulator does not appear as a
debug target in other IDEs
Emulator hangs because it couldn't set up the UDP port
Cannot attach debugger to a Xamarin project
Emulator fails to run app that uses Google Play Services
Drag and Drop of a file, APK, or flashable zip file does not work
Resolution of screenshot is incorrect
Emulator fails to render OpenGL content
Emulator does not respond to multi-touch gestures
Support resources
Before you start

Before you begin troubleshooting, it may be useful to review the following topics:
System requirements for the Visual Studio Emulator for Android
Emulator fails to install

If you don't have Hyper-V installed, you will see the following message when you try to install the emulator. You
must have a machine that supports HyperV and it must be enabled.
NOTE
This message applies both to the Visual Studio Emulator for Android and the Windows Phone Emulator. Windows 8.1 and
Windows 10 support the emulator.
If you see this message, check the System requirements for the Visual Studio Emulator for Android to see
whether you can run the emulator.
Cannot connect to network destinations on a domain or corporate

network
The Visual Studio Emulator for Android appears on the network as a separate device with its own IP address. It is
not joined to a Windows domain and it does not share domain or workgroup credentials with the host computer.
If your network requires domain or workgroup authorization for basic network and Internet connectivity, contact
your IT administrator for an exception. This exception allows your development computer to serve as a boundary
machine and to accept connections from non-domain-joined network devices like the emulator.
The Visual Studio Emulator for Android also uses its own set of MAC addresses. If you can't access network or
Internet resources from the emulator, check with your IT administrator to make sure that the emulator's MAC
addresses have been authorized on your network.
To view the emulator's MAC addresses
1. Launch the emulator.
2. On the emulator toolbar, click the chevron button (>>) to open the Additional Tools window.
3. In the Additional Tools window, click the Network tab.
4. On the Network page, locate the Physical address entries.
Cannot connect to network destinations when network settings

require manual configuration
To connect to network destinations from the emulator, your network must meet the following requirements:
DHCP. The emulator requires DHCP because it configures itself as a separate device on the network with
its own IP address.
Automatically configured DNS and gateway settings. It's not possible to configure DNS and gateway
settings manually for the emulator.
If your network requires manually configured settings, check with your IT administrator to determine how
you can enable network connectivity for the emulator.
Emulator starts slowly, fails to start due to a timeout, or app

deployment fails
Under certain conditions, the emulator takes several minutes to start or fails to start due to a timeout. When the
emulator fails to start, you see the following message: App deployment failed. Please try again . The following
conditions can result in this error.
Running the Visual Studio Emulator for Android from a bootable VHD. This configuration is not
supported.
A faulty hard drive. Consider running the chkdsk program.
A hard drive that needs to be defragmented. Consider defragmenting the drive.
A hard drive that is almost full. Check the space available on the drive.
Not enough memory is available because of other running applications. Reduce the number of applications
that are consuming memory or increase the amount of memory.
Generally, any factor that is contributing to poor performance on the system. Begin troubleshooting with
the component that has the lowest subscore in the Windows Experience Index, which you can find on the
Performance Information and Tools page of Control Panel.
Emulator fails to start

If the emulator was working previously, but does not work now, go through the following tasks. If you are using
the emulator for the first time, see Emulator fails to start (first use) before you try these steps.
Remove any other Hyper-V instances of the emulator.
1. Close Visual Studio.
2. Open Hyper-V Manager and stop any Hyper-V instances of the Emulator (Virtual Machines) that
are already running and possibly in a corrupt state.
3. In Hyper-V Manager, delete any other emulator VMs.
4. Reboot your machine.
Make sure you have at least 4GB system memory and that it is not being consumed by other resource-
intensive programs and processes (for example, try closing any browser windows).
In Hyper-V Manager, open the Virtual Switch Manager and check to see that you have two network
switches; verify that the first one is the internal switch and the second is external.
If the setup is incorrect and you are using Windows 10, you might try to Reinstall network devices using
netcfg -d command (section 6).
If these steps do not resolve the issue, see Emulator fails to start (first use) for information on 3rd party
software that may be interfering with the emulator.
Emulator fails to start (first use)

If the emulator does not start, go through the following tasks to identify and fix the issue.
Make sure that minimum hardware requirements are fulfilled and that BIOS settings are correct.
The Emulator and Windows 8 Hyper-V require a 64-bit processor with Second Level Address Translation
(SLAT). For Intel, you essentially need a Core i3, i5 or i7 processor (or one of many Xeons). A list of AMD
chips is available here.
1. Make sure your computer meets the system requirements.
2. Verify that the SLAT tool reports that your computer is SLAT capable.
3. Within the BIOS settings of your computer, make sure that all virtualization technology is enabled.
The exact BIOS descriptions may vary for each hardware manufacturer. In general, enable features
related to:
SLAT (Second Level Address Translation)
EPT (Extended Page Tables) (Intel)
NPT (Nested Page Tables) (AMD )
RVI (Rapid Virtualization Indexing) (AMD )
VMX (an Intel acronym indicating hardware assisted virtualization support)
SVM (an AMD acronym indicating hardware assisted virtualization support)
XD (Execute Disable) (Intel); this must be enabled
NX (No Execute)(AMD ); this must be enabled.
4. If the following options are present in the BIOS, disable them.
Disable Intel VT-d
Disable Trusted Execution
For more information, see this article: Technet: Hyper-V: How to Fix BIOS Errors Enabling
Hyper-V
5. Make sure you have at least 4GB system memory and that it is not being consumed by other
resource-intensive programs and processes.
6. Make sure you are running Windows 8 Professional or better (Windows Server 2008 is not
supported). Windows Server 2012 is supported, but you must enable Desktop Experience.
You can inspect the Event Viewer to see if there are any Hypervisor errors. To do this, open Event
Viewer (Start key+R, then type eventvwr ) and then select Windows Logs, System. Then filter the
log by event source, setting the source to Hyper-V -Hypervisor. Check for errors to help identify
root cause.
If your processor meets the minimum requirements but hypervisor is still failing, consider finding
out if there is a BIOS upgrade available for your computer. If there is one, and you choose to
upgrade, be sure to observe all precautions from the manufacturer when upgrading the BIOS (such
as making sure the BIOS firmware upgrade is not interrupted by a power loss, which may
permanently corrupt the BIOS ).
Make sure you have at least 4GB system memory and that it is not being consumed by other resource-
intensive programs and processes.
Remove/Disable third party drivers or software that may be interfering with virtual networking.
There are some known issues with some 3rd party products installed under Windows 8 such as
networking drivers/protocols that are not fully compatible with the Hyper-V networking stack.
In general, it will be up to the developers of those products to update their software to be compatible with
Windows 8 and Hyper-V.
The following products may require upgrading for Windows 8 compliance: VirtualBox, Virtual PC 7,
VMWare, some VPN clients, software firewalls, some versions of the Cisco VPN clients, and other
virtualization systems. Work with the developer of the questionable virtualization software to encourage
them to upgrade the software to make it compatible with Windows 8 and Hyper-V.
As a workaround, you can disable all third party drivers and applications which may be interfering with the
virtual network used by the Emulator to communicate with Visual Studio. These applications may include:
Antivirus applications (which hook into the network stack)
Network monitoring tools
Network logging tools
Other system monitoring software
Another possible workaround, short of uninstalling the product(s) in question (and requesting the
product developer to release an updated version), is to take the following steps.
1. Start the Network Connections manager (from the Start screen, type View Network Connections and
select this option to view the network connections.)
2. For the vEthernet (Internal Ethernet Port Windows Phone Emulator Internal Switch) adapter, choose
Properties from the context menu.
The adapter properties are shown here.
3. For this adapter, the only items that should be selected under This connection uses the following
items should be the following:
Client for Microsoft Networks
QoS Packet Scheduler
File and Printer Sharing for Microsoft Networks
Microsoft LLDP Protocol Driver
Link-Layer Topology Discovery Mapper I/O Driver
Link-Layer Topology Discovery Responder
Internet Protocol Version 6 (TCP/IPv6)
Internet Protocol Version 4 (TCP/IPv4)
4. Deselect any other items.
The downside to using this technique is that any time a new 3rd party product installs unsupported
drivers, or any time the emulator is installed, these steps will need to be repeated.
After uninstalling third party products you may need to restore the Windows Phone Emulator
Internal Switch. To do that:
Open Hyper V and go into the Virtual Switch Manager. Create a virtual switch named "Windows
Phone Emulator Internal Switch" and set its connection type to Internal network.
Now launch the emulator. It should work.
Computer fails to boot after installing the Emulator

This problem can occur when the following conditions are true:
Your computer has a Gigabyte motherboard.
USB3 is enabled on the motherboard.
To solve this problem, disable USB3 in the BIOS settings of the motherboard and reboot the computer.
Then check whether Gigabyte has released an update for your motherboard's BIOS.
For more info, see the following Knowledge Base article: Boot failure after installation of Hyper-V role on
Gigabyte systems.
Visual Studio gets stuck trying to deploy the app to the emulator or
the emulator does not appear as a debug target in other IDEs
If the emulator is running, but it does not appear to be connected to ADB (Android Debug Bridge) or it does not
appear in Android tools that make use of ADB (for example, Android Studio or Eclipse), you may need to adjust
where the emulator looks for ADB. The emulator uses a registry key to identify the base location of your Android
SDK, and looks for the \platform-tools\adb.exe file under that directory. To modify the Android SDK path used by
the emulator:
Open Registry Editor by selecting Run from the Start buttons context menu, typing regedit in the dialog
box, and choosing OK.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Android SDK Tools in the folder tree
on the left.
Modify the Path registry variable to match the path to your Android SDK.
Restart the emulator and you should now be able to see the emulator connected to ADB and associated
Android tools.
Emulator hangs because it couldn't set up the UDP port

You may experience this issue due to incompatibility with Xamarin Player. If the emulator appears to hang or if
you see this error message, "The emulator is unable to connect to the device operating system: Couldn't set up
the UDP port. Some functionality might be disabled", you may be experiencing this issue. Take the following
steps.
1. Uninstall Xamarin Player.
2. Verify that virtual box has been removed (Xamarin Player runs on top of virtual box).
3. Go to device manager, select the option to show hidden devices, and then delete everything except the
physical network cards.
4. You can try uninstalling/reinstalling Hyper-V after removing any non-physical network adapters.
Cannot attach debugger to a Xamarin project

If you are running Windows 10 with Intel Skylake processors, Xamarin apps might fail to run in the emulator or
the Visual Studio debugger might not attach to them. This is due to an issue with Hyper-V and Skylake
processors. Take the following steps as a workaround.
1. Open Hyper-V Manager and select the VM for the emulator profile that your are using.
2. Select Delete Saved State (lower right).
3. Choose Settings...
4. Expand the processor node and choose Compatibility.
5. Enable Migrate to a physical computer with a different processor version.
6. Restart the service (under Actions) and try again.
Emulator fails to run app that uses Google Play Services

The emulator does not ship with the libraries for Google Play Services. However, the emulator does support
drag-and-drop installation of flashable zip files.
Drag and Drop of a file, APK, or flashable zip file does not work
The emulator uses ADB.exe to facilitate file transfer when you drag and drop a file onto the screen. If you
encounter an error when you try to drag and drop a file, this probably indicates that the emulator is not connected
to ADB.exe. To resolve, follow steps in Visual Studio gets stuck trying to deploy the app to the emulator or the
emulator does not appear as a debug target in other IDEs.
Resolution of screenshot is incorrect

If you take a screenshot using the Screenshot tab in the Additional Tools window and the resulting image is of
an unexpected size, you may need to adjust the zoom level of the screen before choosing Capture. The emulator
takes screenshots at the resolution of the screen on your host PC monitor.
Emulator fails to render OpenGL content

The emulator renders OpenGL content using your host machine's GPU and uses the ANGLE project to convert
these calls to and from DirectX. If your application renders correctly on a device but incorrectly on the emulator, it
is likely that the device is mitigating an incorrect OpenGL call (for example, using shader variables that do not
match).
Emulator does not respond to multi-touch gestures

In some cases, the emulator will start and not respond to multi-touch either through direct interaction from your
touch-enabled display or using the Multi-Touch Tool on the emulator toolbar. If this is the case, choose the Rotate
button on the emulator toolbar and attempt to use multi-touch again. If the issue persists, read the Emulator fails
to render OpenGL content issue.
Support resources
If your host computer meets the system requirements and you encounter an issue not covered in this
troubleshooting guide:
Ask a question on StackOverflow using the android-emulator and visual-studio tags.
Report an issue using the Send a Smile tool in Visual Studio or in the Emulator Manager.

Idontthinkso

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Idontthinkso

Cargado por

Copyright:

Formatos disponibles

Contents

Cross-Platform Mobile Development in Visual Studio

Build an app for Android, iOS, and Windows (.NET Framework)

Install Visual Studio (VisualStudio.com)

Learn about Xamarin in Visual Studio (VisualStudio.com)

Xamarin mobile app development documentation

DevOps with Xamarin apps

Learn about Universal Windows apps in Visual Studio (VisualStudio.com)

Learn about the similarities between Swift and C# (download.microsoft.com)

Target Android, iOS, and Windows from a single code base

Sharing Code Options (Xamarin)

Code sharing options with .NET

Target Windows 10 devices

Intro to the Universal Windows Platform

Create your first app

Develop apps for the Universal Windows Platform (UWP)

Migrate apps to the Universal Windows Platform (UWP)

Build an app for Android, iOS, and Windows (HTML/JavaScript)

Install Visual Studio (VisualStudio.com)

Get started with Visual Studio Tools for Apache Cordova

Learn about the Visual Studio Emulator for Android (VisualStudio.com)

Build an app for Android and Windows (C++)

Download Visual Studio. (VisualStudio.com)

Learn more about using C++ to target multiple platforms. (VisualStudio.com)

Cross-platform mobile development examples for C++ (MSDN Library)

Additional cross-platform mobile development examples for C++ (code.msdn)

Build a cross-platform game for Android, iOS, and Windows by using

Learn more about building Unity games with Visual Studio

Read more about Visual Studio Tools for Unity

Start using Visual Studio Tools for Unity

Learn about Unity (Unity website)

Install Visual Studio

Unity Download Assistant

Configure Unity for use with Visual Studio

Support for older versions

Open Unity scripts in Visual Studio

Unity documentation access

Intellisense for Unity API Messages

4. The selection on the list can be changed in three ways:

Select a Unity instance to attach the debugger to

Debug a DLL in your Unity project

COMMAND SHORTCUT SHORTCUT COMMAND NAME

Open the MonoBehavior Wizard Ctrl+Shift+M EditorContextMenus.CodeWindow.I

Open the Unity Project Explorer Alt+Shift+E View.UnityProjectExplorer

Access Unity documentation Ctrl+Alt+M, Ctrl+H Help.UnityAPIReference

Attach to Unity debugger (player or no default Debug.AttachUnityDebugger

Enabling the .NET 4.x scripting runtime in Unity

Choosing between .NET 4.x and .NET Standard 2.0 profiles

Taking advantage of .NET compatibility

public class JSONTest : MonoBehaviour

var enemy = JsonConvert.DeserializeObject<Enemy>(json);

Debug.Log($"{enemy.Name} deals {enemy.AttackDamage} damage.");

New syntax and language features

You can also use expression-bodied members in read-only properties:

Task-based Asynchronous Pattern (TAP)

// Get the string name of an enum:

Caller info attributes

private void Start ()

.NET 4.x Sample Unity Project

// save the changes using the Utf8StringWriter

Experimental Azure SDKs

Azure SDK sample

Troubleshooting the connection between Unity and Visual Studio

Visual Studio crashes