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.
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
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.
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.
Side-Bar: Multi-Version Environment
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.
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.
Terminal window
@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 err
CALL %vssetup%
goto end
:err
echo %vssetup% NOT FOUND
echo Unable to setup .NET Framework SDK command line tools.
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.
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.
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.
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.
Software migration is a complex process. During a transformation one must consider multiple aspects of the output code (Equivalence, Complexity, Readability, Maintainability, etc.) In this blog, I wanted to highlight some of our VB6 to C# (.NET) transformations.
gmBasic 10.06B9<br />[+] Added support for translation subsystems. (select subSystem="id")<br /> A subsystem is a named set of language translation rules that implement a custom migration.<br /> For example producing WPF translations is done by activating the WPF subsystem.<br />[+] VB6 forms to WPF forms feature (supports most VB6 Intrinsic controls)<br />[+] Added ControlData API to gmSL. This also supports custom control migrations such as WPF.<br />[+] Additional migration events added to gmSL (AuthorProperties, CodeReference, AdjustProperties)<br />[+] Added Refactor-HasWeakSetter for accessors that take object<br />[+] Added Refactor-Declare to deal with missing declarations in ASP<br />[+] Added Refactor-RemoveResumeNext to deal with overly complex on error resume next functions<br />[+] Simplify FRX to RESX convention to avoid issues with special characters in resx filenames.<br />[+] Improved support for support for Graphics operations including Circle and Line command B and BF options<br />[+] Improved support for upgrading VB6 FileSystem listbox controls<br />[+] Improved support for source codes and COM components that use international character sets<br />[+] Support for '-' in ASP file names.<br /><br />
gmStudio<br />[+] Improve UI responsiveness when running long processes<br />[+] Improve user control over scrolling session log to screen<br />[+] Update References/Definitions reports to use AuditVBI.gmsl<br />[+] Added Rules Samples management to Settings form<br />[+] Simplify view menu; removed items that are handled on Settings form<br />[!] Correct issue with report selector list not showing up in Trial Mode<br />[!] correct SrcFile path in NET Build Log report for ASP includes<br />[!] correct translation switches being cleared from the task in memory<br />[!] correct report type list being empty in trial mode<br /><br />
Samples<br />[+] Rework Scantool to filesystem listbox migration<br />[+] Rework FileExplorer sample to use new IDFs and gmSL for Common Controls replacements<br /><br />
Installation<br />[R] Retire GMNI DLLs that are now handled using gmSL <br />[+] Retire ReferenceAudit.dll<br />[+] Add ASPGlobalIncludes.dll to standard distribution (preparing for new Web Samples)<br />[+] Added a template GlobalImports script to settings folder (preparing for new Web Samples)<br />[+] Added a template GlobalIncludes script to settings folder (preparing for new Web Samples)<br />[+] Update the contents of extras\RefactorLibrary with more current samples and move to support\rules
gmBasic
[+] V10.05: Improvements for VB6 translation correctness
[+] Improvements for ASPX/ASCX correctness
[+] Ensure gmBasic generates code to properly initialize page reference in ASCX.CS files
[+] Support for rewriting GoSub as function call
[+] Added Refactor/Declare to explicitly add missing variables
[+] Added Select LinearizeFiles=on|off to work around build cycles among ASPX folders
[+] Additional support for reporting variable scope in References reports using AuditVBI.gmsl
gmStudio
[+] Added UI support for VS2012 (beta)
[+] Improved TypeLib resolution from explicit script reference
[ ! ] Fixed TypeLib resolution from ProgID on Win64
[ ! ] Fixed undercounting GUI Lines in ASP by one in Code Structure Report
[ * ] UI Support for COM Replacements (Rules Management - pre-release requires Special license)