As you are probably aware, Visual Studio 11 is currently available in beta (find it here). The release is at a point where Microsoft is confident enough it is solid they are providing a “Go Live” license, meaning there will be a supported update path from the beta to the RTM version and your code today will be supported so it works once the.NET 4.5 Framework is released as RTM. Over the next few weeks, I am going to dig into Visual Studio 11 and the .NET 4.5 Framework. Today, I want to talk about project compatibility.
Solution and Project Compatibility
If you have been in .NET for a while, you probably remember moving from one version of Visual Studio to another and having both your solution and project files converted. In cases where the project file was updated via a wizard, it was a one way street. For the solution file, there were some instances where simply changing the number in the solution file solved the problem.
I remember this most vividly moving from VS 2005 to VS 2008, as the core framework team migrated, but the UI team was unable to migrate due to a time crunch. Hindsight being 20-20, we should have delayed the entire organization updating. The solution was to have two sets of project and solution files.
I don’t remember the same pain for solutions in VS 2010. While the solution file number did increment, I don’t remember the solution breaking things (perhaps a slip in memory?). I do, however, remember the project files requiring update.
Visual Studio 11 to the Rescue
The problem is solved in Visual Studio 11, as both the solution file and the project files are compatible. You still cannot introduce .NET 4.5 features into a project and expect users of Visual Studio 2010 to be able to compile. But, if you keep the framework version set to 4.0 or earlier, you can use VS 11 while the rest of your team uses VS 2010, with no issues.
Project backward compatibility (VS 11 to VS 2010) is a highly touted featured for VS 11. This makes it easier for larger IT organizations/departments to upgrade to VS 11 in groups.
But there is a Gotcha
There is one issue with the upgrade: Database projects still require updates. For many of you, this is probably a non-issue, as you have no .dbproj files to contend with. If you use database projects, however, this is a big issue. Here is a shot of Visual Studio asking if you would like to upgrade; If you choose yes, you will end up with a .sqlproj file (more in a bit).
Fortunately, there is a workaround to the problem, and you can do something about it today, months before your teams start upgrading. The new database project uses a .sqlproj file for the project. This may not fire off any recogniztion, but the current tooling that uses this project type is SSDT, aka the Microsoft SQL Server Data Tools. You can see information on the project here.
If your database projects can be converted to use SSDT, the .sqlproj project file will roundtrip between the VS 11 beta and VS 2010 SP1 (SP1 is a necessity for SSDT). The download is through the web platform installer, found here, but you should read the brief release notes here prior to installation, especially if you have VS 2010 Pro or Ultimate and have not installed SP1 yet.
NOTE: If you attempt to open a data project in VS 11, it will prompt you to upgrade the project. You will have the option of ignoring, but this will exclude it from the solution. If you install SSDT prior to the attempted opening, you will be prompted to convert in VS 2010, as shown in the following screenshot (i.e. Same Result):
This request is to ensure you consider moving to the newer format so you can take advantage of the latest tooling surrounding data projects.
The good news is VS 11 is backward compatible to standard project types. The bad news is database projects are not compatible. But you should download the SSDT and upgrade your database projects anyway, so doing that now will help you avoid this snafu.
Peace and Grace,