The official source of product insight from the Visual Studio Engineering Team
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:
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:
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.
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:
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:
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.
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.
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.
1. I open VS2008 Solution with SQL 2012 SSDT, then click on Build. I can deploy the SQL reports to ReportServer.
2. Since SQL 2012 has no option to connect to TFS, I now open same VS2008 Solution in VS 2012 RC, but get this error:
This version of Visual Studio does not have the following project types installed or does not support them. You can still open these projects in the version of Visual Studio in which they were originally created.
- CRMReports, "C:\TFSTEST\CRMReports.rptproj"
Can you assist ?
Let me know if any videos or document to run the Coded UI tests as a part of TFS auto build in VS 2012?
Thanks and Regards,
All I can say is, *FAIL* on the ISLE choice. See just some of the issues:
Stack Overflow: stackoverflow.com/.../304683
Something that "simple" was never an issue pre ISLE/post deprecation of Setup and Deployment Projects. Sigh....wasting time right now fixing things that never needed fixing....sigh again.
The Flexera KB (number of issues) alone should give pause....at least they have a KB....now dig in fellow devs! Sigh...
What is a mystery is why deprecate instead of giving a CHOICE??? You're actually pushing a 3rd party product, and now have to deal with issues created by such 3rd party product! Even from a biz standpoint, that's strange....
can a project developed in 2.0 or 3.5 be targeted in 4.5 or not ?