About two years ago we wrote a blog post entitled Why does Visual Studio 2010 convert my projects? One of the strong pieces of feedback we received was that you wanted to be able to work on your projects using both the current and previous version of VS. We are delighted to announce that Visual Studio 11 will allow you to easily round-trip your projects with Visual Studio 2010 SP1! This means you can leverage the features of Visual Studio 11 while collaborating on the same projects as your team members who may still be using Visual Studio 2010 SP1.

When we embarked upon enabling round-tripping, we realized that implementing the feature boils down to accomplishing three goals:

  • Visual Studio 11 just works with existing Visual Studio 2010 projects
  • It is easy and desirable to upgrade to Visual Studio 11
  • Teams can use both Visual Studio 11 and Visual Studio 2010 at the same time

The key to achieving these goals is to answer one question – whether a project can leverage the same set of tools in Visual Studio 2010 and Visual Studio 11, and exhibit the same design-time and runtime behaviors. In Visual Studio 2010, we enabled full multi-targeting which severed the one-to-one tie between Visual Studio and the .NET runtime. This allowed projects created in Visual Studio 2010 to target older .NET Frameworks, and took us halfway towards enabling round-tripping of projects between Visual Studio versions. In Visual Studio 11, we took the next natural step of correctly handling projects when operating in different environments.

As we iterated through all the assets shipped in Visual Studio, we realized that to provide a seamless round-tripping experience, we would need to service Visual Studio 2010 so that it could offer the appropriate user experiences when handling projects which have been modified, or even upgraded. For instance, Web projects in Visual Studio 2010 specified the path to their build targets with a hard-coded “v10.0”. This would obviously not work if Visual Studio 2010 Web projects were to round-trip with Visual Studio 11 where the “v11.0” build targets are used. The resolution was to replace the hard-coded Visual Studio version string in the build targets path with a $(VisualStudioVersion) property which would dynamically change its value based on the environment in which Web projects are loaded. Visual Studio 2010 had to be serviced so that it could recognize and honor this new property.

With every new Visual Studio release comes a new set of language features which are baked into the compiler that ships with the .NET Framework as well as the compiler that ships within Visual Studio for IntelliSense and other purposes. For instance, Async is a feature which is baked into .NET 4.5 and Visual Studio 11. This means that if a project using Async is opened in Visual Studio 2010, build errors would occur as Visual Studio 2010 would not understand the new language features. This could lead to a confusing user experience where team members on Visual Studio 11 could unintentionally use new language features, check in seemingly successfully running code, but once the projects are run on a Visual Studio 2010 machine, they would fail to run.

While reviewing the experiences with every asset and feature shipped in Visual Studio 2010 and Visual Studio 11, we realized that to provide a seamless round-tripping experience, we needed to place two constraints on the feature:

  1. Round-tripping will only work between Visual Studio 2010 SP1 and Visual Studio 11
  2. All projects targeting .NET 2.0 to 4.0 and Silverlight 4 to 5 can round-trip.

Once the constraints were in place, we determined that there are four categories of projects: (1) those that can round-trip seamlessly, (2) those that require behavioral modifications to round-trip, (3) some that cannot round-trip, and (4) a few that are deprecated in Visual Studio 11. The rest of this blog post will elaborate upon each category and describe the experience we have designed for it.

Category 1: Round-trips seamlessly

The majority of projects fall into this category. These are projects that will just open in Visual Studio 11 and behave exactly the same as they did in Visual Studio 2010 SP1. You can reopen them in Visual Studio 2010 SP1 where you will find that the modifications you made in Visual Studio 11 are persisted, and the project continues to behave as it did in Visual Studio 11.

Within this category are two types of projects:

  1. Require no modifications at all: these projects will not be touched at all when loaded in Visual Studio 11. An example is a Windows Forms project.
  2. Require modifications that won’t change project behavior: these projects have a hard-coded Visual Studio version in their build targets path which needs to be replaced with the $(VisualStudioVersion) property in order to enable round-tripping. Visual Studio 11 will automatically do the modifications upon project load and backup the modified files in the solution directory. If these projects are under source control, they will be automatically checked out and edited. These modifications enable round-tripping while not affecting your project behavior. An example is an MVC 3 project.

Category 2: Requires behavioral modifications to round-trip

In order to load these projects in Visual Studio 11, modifications are required which will change project behavior. However, after the modifications, these projects will seamlessly round-trip with Visual Studio 2010 SP1.

When you load these projects in Visual Studio 11, you will see the Review Projects And Solution Changes dialog. For example, when loading a Silverlight 3 project in Visual Studio 11, the Review Projects And Solution Changes dialog will appear as Visual Studio 11 does not support Silverlight 3, and hence the project needs to be retargeted to Silverlight 5.


The following features of this dialog merit notice:

  • To learn more about the statuses, you can hover over them which will invoke a tooltip explaining what they mean.
  • If you are still unclear about the changes being made to your project, you can click on More Information which will take you to the MSDN help page that lists all the project types in Visual Studio and the changes that will happen to them in order to load them successfully in Visual Studio 11.
  • If you need to consult your team before committing to migration, you can right-click in the middle pane of the dialog and choose Copy Information which copies the content of the dialog onto your clipboard. The content copied onto the clipboard lists all the projects in the solution. The ones that did not appear in the dialog fall into category 1: round-trips seamlessly.
  • Use the checkboxes to specify which projects you want to migrate. The unchecked projects will be left unloaded in the Solution Explorer with a ‘needs conversion’ message. You can reload these projects which will trigger the Review Project And Solution Changes dialog to reappear.
  • After migration, all the modified files will be backed up in the solution directory. A migration report will be created and saved in the solution directory but it will only be launched in the web browser if there were any migration errors or warnings.

Once migration is complete, the project will open back in Visual Studio 2010 SP1 without any issues. In the case of this Silverlight project, it will be retargeted to Silverlight 5 and will continue to round-trip seamlessly with Visual Studio 2010 SP1 as long as the Silverlight 5 tools are installed on the Visual Studio 2010 SP1 machine.

Category 3: Does not round-trip

These projects cannot exhibit the same runtime and design-time behavior when opened in Visual Studio 2010 SP1 and Visual Studio 11. When these projects are opened in Visual Studio 11, the Review Projects And Solution Changes dialog will appear informing you that a one-way upgrade is needed. For example, since VS SDK projects are utilized to create extensions for a particular version of Visual Studio, it follows that the projects themselves need to be run in the targeted Visual Studio version.


After migration, these projects will not round-trip and opening them in Visual Studio 2010 SP1 will result in failure to load and an ‘incompatible’ message.


Category 4: Deprecated projects

These project types are not supported in Visual Studio 11. Opening deprecated projects will launch the migration report in the web browser.


In the example above, each deprecated project is reported as an error. The links will take you to the help page for that project type which will help you migrate your assets in the deprecated projects to Visual Studio 11.


The Visual Studio 11 Compatibility help page lists all project types and file types, and the kind of changes, if any, that are needed for them to successfully load in Visual Studio 11. If you own a project system and want to participate in the round-tripping infrastructure, please refer to the How to: modify a project system so that projects load in multiple versions of Visual Studio help page.

As always, feedback is welcome! You can leave your comments on this blog post and file bugs on Microsoft Connect.



Richa Prasad – Program Manager, Visual Studio Pro team

Short Bio: Richa Prasad joined the Visual Studio team in 2009. She has been working on the Project and Build team since then, where she drives the experiences around project capabilities and MSBuild. Prior to joining Microsoft, she was in graduate school at University of Washington where she worked on sensor networks projects in collaboration with Intel Research.