Leaving .NET 1.0 Behind

I’ve been exploring .NET 2.0 for quite some time, and am quite happy with the improvements over 1.0. But I was clinging to the older version for one of my bigger projects. No more. As of this last weekend, I converted the project to .NET 2.0.

I have other projects that were in 2.0 from the start and another that I already converted because it was smaller and less trouble to do so. But this one project is of some size and I was reluctant to make the move.

Thinking about it recently, I decided that by keeping the project in 1.0, I was falling behind on the newer versions of .NET – 2.0, 3.0, and 3.5 – and all they have to offer. Additionally, I believe .NET 1.0 and 1.1 have been end-of-lifed. All the more reason to update. I just needed to knuckle down and get it done.

I have the project in source control, so I created a 2.0 branch to work on the conversion, with the intent to merge back to trunk once conversion is complete. Opening the solution file in Visual Studio 2005 brought up the wizard that converted the project files for me. This was handy, but I had to do a lot of manual adjustments to get things where I wanted them.

After that, almost all of my web forms in the ASP.NET project had to be updated to make use of master pages and newer controls – and the updated label control. Throughout the code base (4 projects, including the ASP.NET one) I have been making other changes to include generics and updated documentation. For some reason, in .NET 1.0, C# got the auto-generated comment documentation, but VB didn’t get that until .NET 2.0. As the projects concerned here are all in VB, I need to update the documentation for those.

When Microsoft were working on Visual Studio 2005, they chose to make the project file format a build file for their build tool, MSBuild. This is great, because I can simplify my NAnt build file. In the target where I compile my project, I used to have to do it one assembly at a time. But now, I can import a task from NAntContrib and get the MSBuild tool to do the work. I only have to tell the tool what solution to build, and all the details are contained within the solution and project files.

I won’t show my whole compile task, just the relevant lines (there are some other things happening in the task that should probably be moved if they aren’t compiling code). First is the task as it used to be:

<!-- compile the DataAccess assembly -->
<vbc target="library" output="${dir.build.bin}\Wadmt.DataAccess.dll" debug="${debug}">
    <sources>
        <include name="${dir.src}\Wadmt.DataAccess\***.vb" />
        <include name="${file.commonAssemblyInfo}" />
    </sources>
    <references>
        <include name="System.dll" />
        <include name="System.Data.dll" />
        <include name="System.Xml.dll" />
        <include name="${dir.libs}\Oracle.DataAccess.dll" />
        <include name="${dir.libs}\MySql.Data.dll" />
    </references>
</vbc>

<!-- compile the Core assembly -->
<vbc target="library" output="${dir.build.bin}\Wadmt.Core.dll" debug="${debug}">
    <sources>
        <include name="${dir.src}\Wadmt.Core\***.vb" />
        <include name="${file.commonAssemblyInfo}" />
    </sources>
    <references>
        <include name="System.dll" />
        <include name="System.Data.dll" />
        <include name="System.Web.dll" />
        <include name="System.Xml.dll" />
        <include name="${dir.build.bin}\Wadmt.DataAccess.dll" />
        <include name="${dir.libs}\Microsoft.Office.Interop.Owc.dll" />
    </references>
</vbc>

<!-- compile the Web assembly -->
<vbc target="library" output="${dir.build.bin}\Wadmt.Web.dll" debug="${debug}">
    <sources>
        <include name="${dir.src}\Wadmt.Web\***.vb" />
        <include name="${file.commonAssemblyInfo}" />
    </sources>
    <references>
        <include name="System.dll" />
        <include name="System.Data.dll" />
        <include name="System.Web.dll" />
        <include name="System.Xml.dll" />
        <include name="${dir.build.bin}\Wadmt.DataAccess.dll" />
        <include name="${dir.build.bin}\Wadmt.Core.dll" />
        <include name="${dir.libs}\WilsonMasterPages.dll" />
    </references>
</vbc>

<!-- compile the Tests assembly -->
<vbc target="library" output="${dir.build.bin}\Wadmt.Tests.dll" debug="${debug}" if="${debug}">
    <sources>
        <include name="${dir.src}\Wadmt.Tests\***.vb" />
        <include name="${file.commonAssemblyInfo}" />
    </sources>
    <references>
        <include name="System.dll" />
        <include name="System.Data.dll" />
        <include name="${dir.build.bin}\Wadmt.DataAccess.dll" />
        <include name="${dir.build.bin}\Wadmt.Core.dll" />
        <include name="${dir.tools}\nunit\bin\nunit.framework.dll" />
    </references>
</vbc>

And the task as it is now. Much simpler – 62 lines down to 5.

<loadtasks assembly="${dir.tools}\nantcontrib\bin\NAnt.Contrib.Tasks.dll" />

<msbuild project="${dir.src}\Wadmt.sln" verbosity="Minimal" failonerror="true" verbose="false">
    <property name="Configuration" value="${configuration}" />
</msbuild>

That’s just one example of things that have changed for the better in this project.

I’ve also been doing some refactoring and code cleanup. I’m doing a little bit of dependency injection already, the manual way, and am thinking there are some other places that can use the same treatment. I may wind up adding a DI container to the project. Sounds like a topic for another .NET programming post!

I’ve also been using the ReSharper productivity tool for the first time. I don’t know why I have not tried it before, but I am impressed at all the functionality it provides on top of VS. I’m still on the one-month trial, and am contemplating the possibility of buying a license once the trial is up. At this point, it already seems worthwhile.

Overall, this was some work, and took some reading, editing, and testing, but I’m happy with progress so far.

So long 1.0. It was good while it lasted. I’m moving forward.