Posts Visual Studio Higher to Lower Version Converter
Post
Cancel

Visual Studio Higher to Lower Version Converter

Many a times we find it diffucult to switch between various versions of Visual Studios available.

Visual Studio does an excellent job of converting files from older versions to newer versions. For instance, if you open a Visual Studio .NET 2002 solution in Visual Studio .NET 2003, it will first ask if you want to convert the solution. After you say yes, it will convert all of your solution and project files to the new version of Visual Studio .NET. Now what if you accidentally converted those files and didn’t have a backup? Or perhaps you are writing a solution in Visual Studio .NET 2003 and find out that your client has only Visual Studio .NET 2002?

One method would be to create a new solution in the old version, create an identical project structure, and then copy all the files over and add them to their respective projects.

Thankfully, there is a better solution. There are project converter that helps you to convert the project. Here is converter for C# projects and here is for VB projects.  The program can be launched as a normal windows application or it can be installed in order to get a new Explorer “shell extension” that adds ProjectConverter to the “Open With” option when right-clicking on a *.sln file.

The solution file is a text-based file that contains information about one or more projects.  The solution file contains the target version of Visual Studio. You can change this version number to change the target Visual Studio Version, from higher to lower.

Here is how the solution file looks like,

Microsoft Visual Studio Solution File, Format Version 10.00

# Visual Studio 2008

Project(“{F184B08F-C81C-45F6-A57F-5ABD9991F28F}”) = “ProjectConverter”,

“ProjectConverter.vbproj”, “{B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}”

EndProject

Project(“{54435603-DBB4-11D2-8724-00A0C9A8B90C}”) = “Setup”, “SetupSetup.vdproj”,

“{09667F41-0E35-4D40-A0A9-E71BA6740D93}”

EndProject

Global

  GlobalSection(SolutionConfigurationPlatforms) = preSolution

    DebugAny CPU = DebugAny CPU
    ReleaseAny CPU = ReleaseAny CPU

  EndGlobalSection

  GlobalSection(ProjectConfigurationPlatforms) = postSolution

    {B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}.DebugAny CPU.ActiveCfg = DebugAny CPU
    {B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}.DebugAny CPU.Build.0 = DebugAny CPU
    {B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}.ReleaseAny CPU.ActiveCfg = ReleaseAny CPU
    {B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}.ReleaseAny CPU.Build.0 =ReleaseAny CPU
    {09667F41-0E35-4D40-A0A9-E71BA6740D93}.DebugAny CPU.ActiveCfg = Debug
    {09667F41-0E35-4D40-A0A9-E71BA6740D93}.ReleaseAny CPU.ActiveCfg = Release

  EndGlobalSection

  GlobalSection(SolutionProperties) = preSolution

    HideSolutionNode = FALSE

  EndGlobalSection

EndGlobal

 

In Visual Studio .NET 2003 and Visual Studio 2005, project dependencies are also tracked here. These are not the implicit dependences that are created by project references. When Project A references Project B, there is an implicit dependency. Project B must be built before Project A since it references the other project’s output. Since this type of dependency is project-specific information, it is stored in the project file. (In this example, it would be stored in Project A’s project file since it is referencing Project B, rather than the solution file we are looking at here.) Project files and dependencies are described in the next section.

The dependences stored in the ProjectSection tag are configured at the solution level. They define when a project must be built before another project, but they may not directly reference each other. This is stored in the ProjectSection tag of the project that is dependent on the other project. In this example, the HacksWinApp project is dependent on the HacksLib project and thus includes a reference to the GUID of the other project. This dependency is normally configured by right-clicking on the solution file, selecting Properties from the context menu, and navigating to Project Dependencies in the property page that appears.

Visual Studio .NET 2003 includes a ProjectSection tag even if there is no dependency (you can see this in the HacksLib project tag). Visual Studio 2005 completely omits the ProjectSection tag if there are no dependencies for the project. Visual Studio .NET 2002 stores the dependency information in a completely different section of the solution file, which we will cover next.

The next section in the solution file is the Global section, which begins with a Global tag and ends with an EndGlobal tag. Inside these tags are a number of GlobalSection tags that store an array of different pieces of information, including the configuration settings for various projects as well as source control information.

The difference between the product version and the file format are displayed here,

 

Each project creates a number of files to store information about itself. This includes a project file and a user settings file. The extension for the project file is based on the language type; for example, a C# Project is saved with the extension .csproj and a VB.NET Project is stored with the extension .vbproj. Thankfully, the internal formats of these various files are based on the same XML schema. The beginning of each project file includes some basic information about the project, including the version of Visual Studio that it was created for as well as the GUID for this project. the Build section, which includes build settings and configuration settings as well as references information.  The project file will usually contain at least a Debug and Release section.

The References section contains a reference tag for each assembly referenced by the project. Starting with Visual Studio 2005, you can create a reference to either an assembly or an executable, which comes in very handy when you are trying to unit-test a Windows application, since this lets you directly reference your application. To get this same functionality in Visual Studio .NET 2003, you can actually hack the project file to create a reference to an executable—you simply need to manually enter a reference tag in the references element pointing to your executable.

Similarly projects .vbproj or .csproj is XML format file which looks like this,

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.21022</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{B637ACFD-0AFC-4FBB-A8C0-602B5ABA62F0}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <StartupObject>ProjectConverter.My.MyApplication</StartupObject>
    <RootNamespace>ProjectConverter</RootNamespace>
    <AssemblyName>ProjectConverter</AssemblyName>
    <FileAlignment>512</FileAlignment>
    <MyType>WindowsForms</MyType>
    <TargetFrameworkVersion>v2.0</TargetFrameworkVersion>
    <OptionExplicit>On</OptionExplicit>
    <OptionCompare>Binary</OptionCompare>
    <OptionStrict>Off</OptionStrict>
    <OptionInfer>On</OptionInfer>
    <ApplicationIcon>Icon1.ico</ApplicationIcon>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>binDebug</OutputPath>
    <DocumentationFile>
    </DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <DefineDebug>false</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <Optimize>true</Optimize>
    <OutputPath>binRelease</OutputPath>
    <DocumentationFile>
    </DocumentationFile>
    <NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Deployment" />
    <Reference Include="System.Drawing" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  <ItemGroup>
    <Import Include="Microsoft.VisualBasic" />
    <Import Include="System" />
    <Import Include="System.Collections" />
    <Import Include="System.Collections.Generic" />
    <Import Include="System.Data" />
    <Import Include="System.Drawing" />
    <Import Include="System.Diagnostics" />
    <Import Include="System.Windows.Forms" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="fmMain.vb">
      <SubType>Form</SubType>
    </Compile>
    <Compile Include="fmMain.Designer.vb">
      <DependentUpon>fmMain.vb</DependentUpon>
      <SubType>Form</SubType>
    </Compile>
    <Compile Include="My ProjectAssemblyInfo.vb" />
    <Compile Include="My ProjectApplication.Designer.vb">
      <AutoGen>True</AutoGen>
      <DependentUpon>Application.myapp</DependentUpon>
    </Compile>
    <Compile Include="My ProjectResources.Designer.vb">
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Include="My ProjectSettings.Designer.vb">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <EmbeddedResource Include="fmMain.resx">
      <DependentUpon>fmMain.vb</DependentUpon>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <EmbeddedResource Include="My ProjectResources.resx">
      <Generator>VbMyResourcesResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.vb</LastGenOutput>
      <CustomToolNamespace>My.Resources</CustomToolNamespace>
      <SubType>Designer</SubType>
    </EmbeddedResource>
  </ItemGroup>
  <ItemGroup>
    <None Include="app.config" />
    <None Include="My ProjectApplication.myapp">
      <Generator>MyApplicationCodeGenerator</Generator>
      <LastGenOutput>Application.Designer.vb</LastGenOutput>
    </None>
    <None Include="My ProjectSettings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <CustomToolNamespace>My</CustomToolNamespace>
      <LastGenOutput>Settings.Designer.vb</LastGenOutput>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Content Include="Icon1.ico" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)Microsoft.VisualBasic.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

The diffrence in the two file formats are,

The schema of the project file is pretty straightforward in case you need to edit it directly.

Visual Studio also creates a user-specific project file much like the .suo file created for the solution file except with an extension of <projectextension>.user, so if you were using VB.NET, it would be vbproj.user. Similarly, this user-specific file does not contain anything pertinent enough to cover here, and is also hidden by default, so you will need configure Windows Explorer to show hidden files through Tools – Folder Options – View.

Visual Studio 2005 has not been mentioned up until this point because the project files in Visual Studio 2005 are completely different than the project files in Visual Studio .NET 2002 and 2003. The project files in Visual Studio 2005 are MSBuild XML files.

So this shows you can still convert higher VS.Net projects to lower versions.

This post is licensed under CC BY 4.0 by the author.