VS Versions Support Added to gmStudio
Update: We added support for VS2013 in the March 2014 Release of gmStudio.
Update: We added support for VS2015 in the June 2016 Release of gmStudio.
Update: We added support for VS2017 in the February 2018 Release of gmStudio.
and VS2019 and VS2022
Ever onward!
Section titled “Ever onward!”That seems to be the name of the game in software development. Our customers need new features in their apps and we developers want new tools, and new techniques to build them. We are all just trying to keep up, stay current, keep that edge.
Microsoft is happy to keep moving the target too. .NET is arguably the fastest moving platform in the software tools market at the moment. The major milestones of .NET development evolution are the major releases of Visual Studio tabulated below (source):
| Product name | Codename | Internal version | Supported .NET Framework versions | Release date |
|---|---|---|---|---|
| Visual Studio | N/A | 4.0 | N/A | April 1995 |
| Visual Studio 97 | Boston | 5.0 | N/A | February 1997 |
| Visual Studio 6.0 | Aspen | 6.0 | N/A | June 1998 |
| Visual Studio .NET (2002) | Rainier | 7.0 | 1.0 | February 13, 2002 |
| Visual Studio .NET 2003 | Everett | 7.1 | 1.1 | April 24, 2003 |
| Visual Studio 2005 | Whidbey | 8.0 | 2.0, 3.0 | November 7, 2005 |
| Visual Studio 2008 | Orcas | 9.0 | 2.0, 3.0, 3.5 | November 19, 2007 |
| Visual Studio 2010 | Dev10/Rosario | 10.0 | 2.0, 3.0, 3.5, 4.0 | April 12, 2010 |
| Visual Studio 2012 | Dev11 | 11.0 | 2.0, 3.0, 3.5, 4.0, 4.5, 4.5.1, 4.5.2 | September 12, 2012 |
| Visual Studio 2013 | Dev12 | 12.0 | 2.0, 3.0, 3.5, 4.0, 4.5, 4.5.1, 4.5.2 | October 17, 2013 |
So … onward we go!
We started work on gmStudio in 2004 with VS2003 and .NET 1.1. Now we support rewriting VB6/ASP/COM code for VS2005, VS2008, and VS2010 although it has been a while since anyone showed interest in anything older than VS2008 and VS2010 is the default. With the release of a major service pack for VS2012, and VS2013 already in beta, its well past time to add support for VS2012. I want to use this blog post to walk through the addition of VS2012 support to gmStudio. I will describe some of the conventions and configuration features that allow gmStudio to target and integrate with different VS versions. The tasks in this small maintenance effort are as follows:
- Prepare to do the work.
- Analyze the significant differences between VS2012 and other VS versions
- Implement the changes
Preparation
Section titled “Preparation”Preparation is downloading and installing VS2012 and checking it out. I downloaded the 1.5GB ISO for VS2012 Premium ran the install. All of that took a couple hours, but other than a couple restarts, it was smooth sailing. Looking at the VS2012 UI and… hmm … I think its called Metro right? Functionally everything seems to be there, and more, but it reminds me of the character-based IDE turbo-Pascal that I first did PC programming on back in 1984… very plain but now in high resolution. (Hey at least I didn’t compare it to DOS Basic). No problem, it works; and I bet it will grow on me.
I was able to rebuild the gmStudio projects (C#) in VS2012 with no issues. Our gmStudio-as-a-VS-Extension project did not load or upgrade - no surprise there; it is VS2010-specific. Also our plug-in will not load in VS2012; no surprise there either. Maybe I will do a separate blog post on bringing VSIX extension up to date.
Analysis
Section titled “Analysis”The first thing I notice is that VS2012 is backward compatible with the VS2010 project files (i.e. csproj, vbproj) we generate for DLLs and EXEs. They open and work without asking to upgrade. Web Application projects on the other hand, automatically upgrade to VS2012 format. We will have to account for this minor matter when we translate web application projects.
I installed VS2012 on a machine that also has VS2010 on it. I think this is typical for most people, but it does muddy the waters somewhat. In multi-version VS installations, opening a .NET project file (i.e., csproj, vbproj) can result in opening one of several VS versions. Microsoft decides which version by some means that involves looking for version specific solution file (.sln) in various locations and also looking at the application associated with .NET projects. Windows user’s can also associate project files with a small utility called the Visual Studio Version Selector.
The question is: what version of VS will be used to open the generated projects when we do a “shell open” operation from inside gmStudio? The short story seems to be: if you have Visual Studio Version Selector associated with .NET project files and If there is a VS2010 sln file in the same folder as your csproj, then VS2010 is used, otherwise it’s VS2012.
Updating gmStudio UI and Docs
Section titled “Updating gmStudio UI and Docs”Updating gmStudio to support VS2012 is a matter of changing the UI on the migration project setup form and the user default form.
Updating the docs is also pretty mundane. We use a Wiki for the gmStudio User Guide, so the update is quick and easy. Gotta love a wiki…
Changing Build Tools
Section titled “Changing Build Tools”gmStudio has a .NET build operation that tries to compile the generated csproj/vbproj file. This operation runs MSBuild as a shelled process. Before we can run MSBuild executable, we execute SetEnv.cmd. This is a command script distributed with gmStudio to setup the environment based on the desired VS version. SetEnv.cmd updated to support VS2012 is listed below.
@echo off:: default to VS2010 if not specified.if [%1]==[] set vssetup="%VS100COMNTOOLS%vsvars32.bat"if [%1]==[VS2003] set vssetup="%VS71COMNTOOLS%vsvars32.bat"if [%1]==[VS2005] set vssetup="%VS80COMNTOOLS%vsvars32.bat"if [%1]==[VS2008] set vssetup="%VS90COMNTOOLS%vsvars32.bat"if [%1]==[VS2010] set vssetup="%VS100COMNTOOLS%vsvars32.bat"if [%1]==[VS2012] set vssetup="%VS110COMNTOOLS%vsvars32.bat"
:: If you do not have VisualStudio installed, and only the SDK, you will:: need to use something like the following command depending on the target:: framework SDK installation.:: if [%1]==[VS2008] set vssetup="C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\sdkvars.bat"if not exist %vssetup% goto errCALL %vssetup%goto end
:errecho %vssetup% NOT FOUNDecho Unable to setup .NET Framework SDK command line tools.echo See %0.exit /b 1:endIf you need interop
Section titled “If you need interop”We rarely use interop for migrations, opting instead to configure the tool to replace COM dependencies with .NET classes. However, if you decide to use interop in your upgraded project, gmStudio can help you produce interop assemblies. The feature works as follows: First gmStudio generates a csproj file that uses MSBuild tlbimport conventions to references the COM binaries referenced in your VB6/ASP code. Then gmStudio runs a batch build of this csproj. The .NET SDK tools do the actual interop assembly generation. The csproj file is tool version and .NET framework version dependent and these should be consistent with the interop assemblies.
VS2005: tool\framework Version = "2.0, v2.0"VS2008: tool\framework Version = "2.0, v3.5"VS2010: tool\framework Version = "4.0, v4.0"VS2012: tool\framework Version = "4.0, v4.5"...At present these defaults are hard coded in gmStudio. This logic was modified to support VS2012.
Changing Generated Project Files
Section titled “Changing Generated Project Files”For standard DLL and Exe projects, there are no required changes: you can open and build VS2010 files in VS2012 as-is. However, when the user selects VS2012, I want to default to Framework 4.5. This requires a small change to the a system configuration script called AuthorText.gmsl. The change is made in a function called Project_Preamble. A similar change is needed in function called StartNewcProject which is used when generating stub projects.
void Project_Preamble(string first){... if(Select.DevEnv == "VS2008") {... } else if(Select.DevEnv == "VS2010") {... } else if(Select.DevEnv == "VS2012") { #TextStart <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0"> <PropertyGroup> <ProjectType>Local</ProjectType> <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> #TextEnd }...As mentioned above, web application projects are different in VS2010 and VS2012.
Opening a VS2010 web application project file in VS2012 will invoke a conversion process and display a conversion log:
Opening a VS2012 web project in VS2010 and will get you nothing but an error message about incompatibility.
I created new empty ASP.NET web application projects with both versions and compared them side-by-side. Most of the differences are MSBuild tool and targets. In any event, I made all differences conditional on DevEnv in AuthorText.gmsl. I am doing all this on a Win7 64 machine. There is chance it will not work on Windows versions.
Looking at Results
Section titled “Looking at Results”There are two changes that result from setting DevEnv=“VS2012” in your migration project. First, the TargetFrameworkVersion=4.5. Second, there are some changes in the CSC command line string used by MSBiuld. Recall we modified SetEnv.cmd to call “%VS110COMNTOOLS%vsvars32.bat” which sets the environment to use the .NET build configuration installed with VS2012. There were a few changes in the build configuration. Most of the changes were Framework v4.0 to v4.5 related as expected. The other two changes relate to the highentropy flag and the subsystem flag.
- highentropyrelates to the randomizing the layout of memory and relates to security. Security is good.
- subsystem:6.00 means the application requires Windows Vista or higher. That is probably a valid assumption since we are also requiring Framework v4.5
These compiler settings are defaults chosen by Microsoft.
