| Panel |
|---|
Update: We added support for VS2013 in the March 2014 Release of gmStudio. |
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.
...
- Prepare to do the work.
- Analyze the significant differences between VS2012 and other VS versions
- Implement the changes
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
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.
| Panel | ||
|---|---|---|
| ||
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
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
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.
...
| Panel | ||
|---|---|---|
| ||
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 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
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.
...
| Tip | ||
|---|---|---|
| ||
Build and run control files, like csproj/vbproj, AssemblyInfo, and web.config, can direct some very powerful .NET features. When gmStudio upgrades your source code, it generates build and run control files for you. These generated files are simple, generic versions of these files. Their content is based on the templates and rules in AuthorText.gmsl. If you want to take advantage of the advanced features you can simply use author/fix commands to modify the generated files. If you need to do something more sophisticated or something specific to your organizations standard build procedures , you can activate a project-specific AuthorText.gmsl file and change it for your purposes. |
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.
...