移行を実行する

旧バージョンの .NET Framework 上で稼働するアプリケーションを最新の .NET Framework 上で稼働するアプリケーションに移行するために Visual Studio および .NET Framework では様々な仕組みを提要しています。しかし、それらの機能だけではスムーズな移行は実現できません。ここではスムーズな移行を実現するための一般的なプロセスを紹介します。

移行を実行するプロセス

アプリケーションの移行にあたって、問題を最小限にとどめるために考慮すべきポイントを早い段階で検証しておく必要があります。そのため、このプロセスにおいては「事前確認」が最も重要な作業項目となります。「事前確認」が十分にできていれば、残りの「ビルドの実行」と「ランタイムテスト」は容易な作業となります。

事前確認

アーキテクチャの変更点

.NET Framework の移行では .NET Framework 1.1 から .NET Framework 2.0 へのバージョンアップの際に行われたアーキテクチャの変更に注意する必要があります。基本的には、.NET Framework 2.0 以降への移行を行う場合は、Visual Studio の変換機能や .NET Framework の下位互換性を利用することで、対応することは可能です。しかし、今後のメンテナンスを考慮した場合、アーキテクチャを最新の .NET Framework に対応させておくことが望ましいといえます。この段階で、どの状態でアーキテクチャを維持していくかを検討しておく必要があります。

重大な変更点

.NET Framework では各バージョン間で高い下位互換性を維持しています。しかし、潜在的な不具合の修正やより正しい動作を実現するために、一部の機能において互換性を維持せず、使用の変更を行っている部分があります。これを「重大な変更点」として公開しています。これらの変更はコンパイル時に判明する場合や、実行時エラーとなる場合もありますが、エラーとならず結果的にリリース後に予期せぬ動作の原因として残ってしまう場合があります。
そのため、実際にコードの変更を行う前に重大な変更点の対象となるコードが含まれていないか検証し、問題個所を把握し、可能であれば修正しておくことが必要です。これにより、移行の移行作業やテストの負荷を軽減し、運用時に発生しうる予期せぬ問題を減少させることが可能となります。

開発環境の整備

移行作業において主な開発環境としては Visual Studio を活用しますが、旧バージョンのアプリケーションの構築時には Visual Studio 以外のツールも併用している場合があります。例えば、ユニットテストのために NUnit を使用していたり、ビルドのために NAnt、ドキュメント生成のためにNDoc といったオープンソースのツールを使用したりしているケースが想定されます。これらのツールの中には開発が停止していたり、Visual Studio の標準機能として同様の機能が提供されていたりする場合があります。
移行にあたってはこれらのツールをそのまま使い続けるのか、Visual Studio の標準機能を使うのかといった判断が必要となります。
また、アプリケーション内で使用している 3rd パーティー製のコントロールなのに関しても検討が必要です。最新のバージョンの .NET Framework に対応したバージョンのコントロールが提供されているのか、バージョン間の仕様変更がないかなどを確認しておく必要があります。

ビルドの実行

コードの変換

コードの変換は基本的に、Visual Studio の変換ウィザードによって行われます。変換結果はレポートとして出力され、変換エラーとなった部分は手動で変換する必要があります。また、アーキテクチャを変更する場合や外部のライブラリやツールを利用している部分に関しても手動での変換が必要になります。

ビルド

コードの変換が済んだのち、ビルドを行います。変換ウィザードによる変換を行った場合でも、コンパイルエラーが発生する場合があります。その場合は、コンパイルエラーを元に修正を行い、またビルドを行うという作業をコンパイルエラーが発生しなくなるまで繰り返します。

ランタイムテスト

ランタイムエラーの確認

コンパイルエラーなくビルドが完了するようになったら、実際に動作をさせて確認を行います。まずは、実行時にランタイムエラーが発生しないかの確認をします。ランタイムエラーが発生した場合はエラーを解析し、コードの修正を行います。また、場合によっては設定に問題がある場合もあるため、配置時の環境でエラーが発生しなくなるまで確認を行います。