Compiling .NET 1.1 Projects In Visual Studio 2008

After having put my .NET 1.1 application running on the .NET 2.0 runtime (^), I’m planning on migrating it to .NET 2.0, but not all at once.

Because I don’t want to have 2 solutions (one on Visual Studio 2003 for the .NET 1.1 assemblies and another on Visual Studio 2008 for the .NET 2.0 assemblies) I decide to try using MSBee and have only one Visual Studio 2008 solution.

MSBee has a CodePlex project. You can download it from there or from Microsoft Downloads. Because the build on Microsoft Downloads seemed to be the most stable one, that was the one I downloaded and installed. The package comes with a Word document that explains all that needs to be done.

Before you can install and use MSBee you’ll need to install the .NET 1.1 SDK.

Having everything installed, I just opened the Visual Studio 2003 solution in Visual Studio 2008 and let it convert the solution and projects (near 30).

After the conversion, for building the projects with the .NET 1.1 C# compiler, the project files need to be edited to add the override the default targets with the MSBee ones by adding the MSBee imports after the default imports for the language:

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\MSBee\MSBuildExtras.FX1_1.CSharp.targets" />

Another change needed (for Visual Studio 2008 - I don't know if it was needed for Visual Studio 2005) is the tools version. MSBee needs version 2.0. To change that you'll have to change the ToolsVersion attribute of the project’s root element:

<Project DefaultTargets="Build" ToolsVersion="2.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

MSBee likes has own idea about output paths and I had set up custom output paths on my project. There’s information about this on the documentation but I decided to simply comment that out of the $(MSBuildExtensionsPath)\MSBee\MSBuildExtras.FX1_1.Common.targets file:

<!-- Paulo
  <When Condition=" '$(BaseFX1_1OutputPath)' == '' ">
      <OutputPath Condition=" !HasTrailingSlash('$(OutputPath)') ">$(OutputPath)\</OutputPath>

<!-- Paulo
  <IntermediateOutputPath Condition=" '$(PlatformName)' == 'AnyCPU' ">$(BaseIntermediateOutputPath)$(Configuration)\</IntermediateOutputPath>
  <IntermediateOutputPath Condition=" '$(PlatformName)' != 'AnyCPU' ">$(BaseIntermediateOutputPath)$(PlatformName)\$(Configuration)\</IntermediateOutputPath>

  <OutputPath Condition=" '$(PlatformName)' == 'AnyCPU' ">$(OutputPath)$(Configuration)\</OutputPath>
  <OutputPath Condition=" '$(PlatformName)' != 'AnyCPU' ">$(OutputPath)$(PlatformName)\$(Configuration)\</OutputPath>
  <- Once OutputPath is determined, set OutDir to its value. ->

This all seemed to work fine on my old Windows XP machine without any third party Visual Studio plug-ins, but when I tried it on my Windows Vista X64 machine, I came across some problems:

  • License Compiler

    Because I'm using Infragistics' controls, there's a licences.licx file and the build will compile it. And that proved to be a problem.

    MSBee copies all the files it needs to the build process to a temporary folder, builds it in there and then copies the result to the output path.

    LC.exe seemed to never be able to find all the assemblies it needed. Searching seemed to me to be an old issue (even from the .NET 1.1 times) and the solution always pointed to not compile the license file. So, I commented that part out of the $(MSBuildExtensionsPath)\MSBee\MSBuildExtras.FX1_1.Common.targets file:

        <Output TaskParameter="OutputLicense" ItemName="CompiledLicenseFile"/>
        <Output TaskParameter="OutputLicense" ItemName="FileWrites"/>

  • Resource Generator

    Although this worked fine on the command line, inside Visual Studio ResGen.exe would throw some error and needed to be closed.

    Looking at the Windows Application Log I found out this:

    Faulting application Resgen.exe, version 1.1.4322.573, time stamp 0x3e559b5f, faulting module MockWeaver.dll, version, time stamp 0x4adb072e, exception code 0xc0000005, fault offset 0x00018fac, process id 0x4a50, application start time 0x01ca53c14488a2fb.

    MockWeaver.dll belongs to Isolator and I just disable it when building inside Visual Studio. I was hoping to start using Isolator on this project, but, for now, I can't.

I hope this can be of some help and, if you need more, you’ll probably find it at the MSBee’s CodePlex forum.

The bottom line is: You don’t need Visual Studio 2003!

Running .NET 1.1 Applications On .NET 2.0

One of the applications I develop is a .NET 1.1 Windows Forms application used by more than 5000 users and critical for the business.

Being a complex and critical application, porting it to the 2.0 runtime just because it was not an option because it would mean installing the new runtime and framework on the stable environment of the workstations (Windows XP) and test fully the application. That was not an option.

As time went by, a developer received a brand new laptop with Windows Vista. Since he only needed ,NET 2.0 for his developments, he never installed .NET 1.1.

Another developer on my team had already tried to port the application to .NET 2.0 and run into some issues:

  • The main component of this application is the Web Browser Control. This control derives from AxHost, which changed going from 1.1 to 2.0 and needed major changes to compile for the 2.0 framework.
  • Another change was that mixing synchronous and asynchronous calls is not allowed in the 2.0 framework and we had, at least, one of those in our use of HttpWebRequest/HttpWebResponse.

The .NET 2.0 runtime and frameworks were developed to be highly compatible with applications written and compiled to the 1.1 runtime and frameworks. In fact, some of the changes were just applying the ObsoleteAttribute set to throw a compiler error when used, which doesn’t prevent its use by already compiled assemblies. This was the case of the WebBrowserControl/AxHost and just using the assembly compiled for .NET 1.1 would probably run fine. And it did.

The synchronous/asynchronous was also very easy to fix. All it took was changing this:


into this:

request.EndGetRequestStream(response.BeginGetRequestStream(null, null))

And it all worked as if it was running on .NET 1.1.

But that’s not the end of it. Latter came a requirement to use, in one of the web pages that ran in the web browser control, an ActiveX component developed in .NET 2.0.

But that time, the 2.0 runtime and framework were already installed on the workstations.

But how would we force the application to run in the 2.0 runtime if the 1.1 runtime was still there?

As simple as adding this to the configuration file (App.config):

    <requiredRuntime version="v2.0.50727" safemode="true"/>