はじめに
近年、.NETプラットフォームは大きな進化を遂げ、従来のWindows限定の「.NET Framework」から、クロスプラットフォーム対応を重視した「.NET Core」を経て、.NET Framework と .NET Core を統合した「.NET（.NET 5以降）」が登場しました。この記事では、これまで .NET Framework を使ってきたが、.NET 5以降を使ったことのない方向けに、.NET を用いたマルチプラットフォーム開発の概要と歴史を振り返ります。また、最新の .NET を使ったGUI作成におすすめの開発環境についても解説します。
1. .NET プラットフォームの歴史概観
1.1 .NET Framework の登場と普及
-
2002年：.NET Framework 1.0 のリリース
マイクロソフトがWindows向けに発表した統合開発プラットフォーム。主にC#やVB.NETなどで開発が行われ、ASP.NETやWindows Forms、WPF（.NET Framework 3.0以降）などの技術スタックを通じて、WindowsアプリケーションとWebアプリケーションの開発が容易になりました。 -
2005年：.NET Framework 2.0 → 3.5
ジェネリクスやASP.NET AJAXなどが追加され、Windowsワークステーション／サーバー向けの企業システム開発の基盤として広く採用されました。 -
2010年：.NET Framework 4.x 系列
パフォーマンスと機能の強化が進み、WPFやWCF（Windows Communication Foundation）などが成熟。エンタープライズシステムを中心に多くの大規模プロジェクトで利用されました。
1.2 .NET Core の登場とクロスプラットフォーム化の始まり
-
2016年：.NET Core 1.0 リリース
Windowsだけでなく、LinuxやmacOSでも動作する軽量なランタイムとして登場。オープンソース化されたことで、コミュニティによる改善が加速し始めました。 -
2017年：.NET Core 2.0 / 2.1
.NET Standard 2.0 のサポートを通じて、既存の .NET Framework 向けライブラリを .NET Core 上でも動作させやすくなりました。また、LTS（Long-Term Support）版として 2.1 が提供され、企業導入の安心感が増した時期です。 -
2019年：.NET Core 3.0 / 3.1
WPF や Windows Forms が .NET Core 環境で動作可能になり、従来の Windows デスクトップアプリを段階的に .NET Core に移行できる基盤が整備されました。
1.3 .NET Framework と .NET Core の統合：.NET 5 以降
-
2020年：.NET 5 リリース
「.NET Core」という名称を廃止し、「.NET」として再出発。旧来の .NET Framework 4.x 系列は以降更新が停止され、将来的に .NET 5以降へ移行することが推奨されました。ここで Windows Forms や WPF も含めたフルスタックをサポートし、かつクロスプラットフォーム機能は .NET Core から引き継ぎました。 -
2021年：.NET 6 リリース（LTS）
LTS 版として多くの安定性／機能強化が図られ、マルチプラットフォーム開発の基盤がさらに固まりました。また、C# 10 や新しい SDK スタイル、System.Text.Json などの高速化が実現されています。 -
2022年：.NET 7 リリース
機能強化リリースとして、さらにパフォーマンスが向上。短いリリースサイクルで新機能を取り込む流れを構築。 -
2023年：.NET 8 リリース（LTS）
マルチプラットフォーム対応をより深化させ、特に新しい GUI フレームワークである.NET MAUI（Multi-platform App UI）や Blazor の進化が注目されています。
2. .NET 統合に伴う破壊的変更の歴史
.NET Framework → .NET Core → .NET 5+ の移行には、いくつかの破壊的変更（Breaking Changes）が含まれており、既存アプリケーションを移行する際には考慮が必要です。
2.1 API やライブラリの非推奨・削除
-
System.Web 名前空間の削除（.NET Core/.NET 5 以降）
従来の ASP.NET（WebForms、MVC 5 以前）の基盤となっていた System.Web 名前空間が .NET Core に存在せず、ASP.NET Core では全く別のアーキテクチャになりました。これにより、WebForms や従来型の HttpContext 利用コードは大幅な書き換えが必要です。 -
WCF サーバー機能の未対応
.NET Core/.NET 5 以降では、既存の WCF サービスホスト機能（サーバー側）をサポートしておらず、gRPC や ASP.NET Core Web API などへの移行が必要になりました。 -
System.Drawing の制限
.NET Core 以降ではSystem.Drawing.Commonは Windows 以外のプラットフォームで正式サポートが縮小され、Linux/Mac での画像操作は代替ライブラリ（SkiaSharp、ImageSharp など）への移行が推奨されています。
2.2 プロジェクトファイル形式の変更
-
古い
packages.configから新しいPackageReferenceへ
.NET Framework 時代の NuGet 参照管理方式 (packages.config) は、SDK スタイルプロジェクト（*.csproj）内での<PackageReference>タグ管理に移行しました。既存プロジェクトを移行する際には手動で参照書き換えが必要なケースがあります。 -
ターゲットフレームワーク指定の簡略化
<TargetFramework>net5.0</TargetFramework>のように記述できるようになり、複数ターゲット（<TargetFrameworks>net5.0;netcoreapp3.1;net472</TargetFrameworks>）もサポートされましたが、従来の<TargetFrameworkVersion>指定とは互換性がありません。
2.3 ランタイム仕様とデプロイモデルの違い
-
自己完結型（Self-contained） vs フレームワーク依存型（Framework-dependent）
.NET Core/.NET 5 以降では、必要なランタイムをアプリに同梱できる「自己完結型」デプロイが可能になりました。既存の .NET Framework アプリは Windows OS の GAC（Global Assembly Cache）やフレームワークとの依存関係を前提にしていたため、実行バイナリ周りが大きく変わります。 -
ランタイムバージョンの共存問題の解消
.NET Core 以前では、GAC や Windows Update によりシステム上の .NET Framework バージョンが管理されていましたが、.NET Core/.NET 5+ ではアプリ自身が使うランタイムをバンドルできるため、古いバージョンと新しいバージョンを共存させやすくなりました。
3. 最新の .NET を用いたマルチプラットフォーム開発入門
ここからは、.NET 5以降を使ったマルチプラットフォーム開発を行うにあたっての流れと、GUI 作成のおすすめ環境を解説します。
3.1 環境準備
-
.NET SDK のインストール
- 公式ダウンロードページ（https://dotnet.microsoft.com/download）から最新の LTS 版（例：.NET 8）SDK をダウンロードしてインストールします。
- インストール後、コマンドプロンプトまたはターミナルで
dotnet --versionを実行し、インストールが正常に完了していることを確認しましょう。
-
開発エディタ/IDE の選定
-
Visual Studio 2022（Windows）
- Windows 環境であれば Visual Studio の最新バージョンが充実した開発体験を提供します。.NET 8 対応ワークロードを選んでインストールしてください。
-
Visual Studio Code（Windows/Linux/macOS）
- 軽量かつ拡張性が高いエディタ。C# 拡張（C# for Visual Studio Code）をインストールすると、IntelliSense やデバッグ機能が利用可能です。
-
JetBrains Rider（有償）
- クロスプラットフォーム対応の IDE として、ソリューション形式やプロジェクト管理が便利。特に Windows / macOS / Linux 両方で同じ開発体験を得たい場合におすすめです。
-
3.2 コンソールアプリケーションの作成（サンプル）
まずは、マルチプラットフォーム対応の基本形として、コンソールアプリケーションを作成して実行してみましょう。
# 新規コンソールアプリ作成（.NET 8 例）
dotnet new console -n MultiPlatformSample
cd MultiPlatformSample
# プロジェクトをビルド・実行
dotnet run
Program.cs のデフォルトコードは以下のようになっています。
using System;
Console.WriteLine("Hello, .NET Multi-Platform World!");
上記のコードは、Windows/macOS/Linux のいずれでも同じように動作します。
3.3 クロスプラットフォーム対応ライブラリ
マルチプラットフォームに移行する上で、ファイル入出力やネットワーク、ライブラリ参照などで注意すべき点があります。
-
ファイルパスの違い
Windows：C:\\temp\\data.txt
Linux/macOS：/home/user/data.txt
→Path.CombineやPath.DirectorySeparatorCharを使って環境依存の区切り文字を吸収しましょう。 -
改行コードの違い
Windows：CRLF（\r\n）
Linux/macOS：LF（\n）
→Environment.NewLineを使うことで実行環境に応じた改行コードが利用できます。 -
プラットフォーム固有の機能呼び出し
P/Invoke などを用いて Windows API を直接呼ぶコードがある場合、Linux/macOS では動作しません。共通ライブラリ化が難しければ、#if WINDOWSなどの条件コンパイルで分岐するか、抽象化してプラットフォームごとの実装を切り分ける設計が必要です。
3.4 GUI アプリケーションの開発
従来の Windows Forms や WPF は基本的に Windows 環境に限定されていましたが、現在はクロスプラットフォームで動作する GUI フレームワークがいくつか登場しています。以下で代表的な選択肢を紹介します。
3.4.1 .NET MAUI（Multi-platform App UI）
-
概要
.NET 6 以降で標準サポートされている次世代 GUI フレームワーク。Windows、macOS、iOS、Android など、デバイス横断的に開発が可能。XAML ベースで開発し、共有コード量を最大化できます。 -
メリット
- Microsoft が公式サポートしているため、ドキュメントやサンプルが豊富。
- Visual Studio でのデザイナーサポートやホットリロード機能が使える。
- iOS/Android ネイティブ要素を活用できるため、モバイル向けアプリケーションを同一コードベースで開発可能。
-
注意点
- Windows/macOS/iOS/Android のビルド環境を整える必要がある。特に iOS の場合は macOS 環境と Xcode が必要。
- 現時点では Linux ネイティブ UI はサポート対象外。ただし、Linux 向けは Uno Platform や Avalonia などを検討する。
-
サンプル作成
dotnet new maui -n MauiDemoApp cd MauiDemoApp dotnet build dotnet run -f net6.0-windows # Windows 向けに動作確認
3.4.2 Avalonia
-
概要
オープンソースで開発されているクロスプラットフォームGUIフレームワーク。.NET 5以降をターゲットにし、Windows（Win32/WinUI）、Linux（GTK/X11/Wayland）、macOS（Cocoa）で動作します。XAMLライクな*.axamlを使って宣言的にUIを構築可能。 -
メリット
- 純粋にクロスプラットフォームを重視しており、1つのコードベースで Windows/Mac/Linux に対応可能。
- ライトウェイトでありながら、高度なカスタムコントロールの実装も行いやすい。
- コミュニティが活発で、プラグインやサンプルも充実している。
-
注意点
- デザイナービューはまだ発展途上であり、Visual Studio や Rider での AXAML のホットリロード機能を活用しつつ動作確認する必要があります。
- WPF のような成熟度はまだ完全ではないため、複雑なアニメーションやカスタムレンダリングを行う際は自己検証が必要です。
-
サンプル作成
dotnet new avalonia.app -n AvaloniaDemo cd AvaloniaDemo dotnet run
3.4.3 Uno Platform
-
概要
Windows の UWP／WinUI コードをベースに、iOS、Android、WebAssembly、Linux へと同じコードを展開できるフレームワーク。XAML の互換性を強みにしており、Visual Studio による開発がスムーズ。 -
メリット
- UWP/WinUI の既存資産を活用しやすく、Microsoft 製品と親和性が高い。
- WebAssembly 対応により、ブラウザ上で UI を動作させることが可能。
-
注意点
- .NET MAUI ほど公式ドキュメントが充実しているわけではないため、特定の機能実装時に情報収集が必要。
- ラーニングコストがやや高い場合がある。
-
サンプル作成
dotnet new unoapp -n UnoDemo cd UnoDemo dotnet run -f net6.0-windows
3.5 GUI 開発における推奨環境
拡張性やデザイナーサポート、コミュニティの充実度などを総合的に勘案すると、以下の組み合わせがおすすめです。
-
Windows 環境下での開発
- IDE：Visual Studio 2022 / 2023（.NET 8 ワークロードを含む）
- GUI フレームワーク：Avalonia（Linux/macOS 対応）または .NET MAUI（モバイル開発含む）
- 補助ツール：Avalonia の場合は Avalonia for Visual Studio 拡張 をインストール推奨。
- ビルド環境：Windows 10/11、.NET 8 SDK
-
macOS 環境下での開発
- IDE：Visual Studio for Mac（.NET 8 対応）または Rider
- GUI フレームワーク：Avalonia（Cocoaバイナリをサポート）、または .NET MAUI（Xcode が必要で、iOS／Android 開発時に必須）
- ビルド環境：macOS Monterey 以降、.NET 8 SDK、Xcode（iOS サポート時）
-
Linux 環境下での開発
- IDE：Visual Studio Code + C# 拡張 または Rider
- GUI フレームワーク：Avalonia（GTK/X11/Wayland いずれかを用いたビルド）
- ビルド環境：Ubuntu 20.04 LTS 以降、.NET 8 SDK
4. まとめ
-
.NET の歩み：もともと Windows 専用だった .NET Framework が、.NET Core を経て .NET 5 以降でフルスタックのクロスプラットフォームランタイムへと進化しました。その過程では、多くの API 変更やデプロイモデルの刷新があり、既存資産の移行には一定の学習コストが伴います。
-
破壊的変更への対応：System.Web や WCF サーバー機能の非対応、プロジェクトファイル形式の変更、NuGet パッケージ互換性の見直しなど、移行時に注意が必要です。代替技術への書き換えや条件コンパイルによる分岐実装で対応しましょう。
-
マルチプラットフォーム開発の流れ：.NET SDK のインストールから、プロジェクト作成、クロスプラットフォーム対応ライブラリの使い分けまで、一連の手順を抑えることで、Windows/Linux/macOS の各環境で同一コードによる開発が可能です。
-
GUI フレームワークの選択肢：現時点で最も成熟度が高く、クロスプラットフォーム開発に適しているのは Avalonia です。Rider あるいは Visual Studio との組み合わせで開発効率を向上させましょう。モバイルまで含めた広範囲の対応が必要な場合は .NET MAUI を検討するのが良いでしょう。
これから .NET 5 以降の世界に足を踏み入れる際、本記事が参考になれば幸いです。各フレームワークやライブラリの公式ドキュメントを参照しつつ、ご自身のプロジェクト要件に最適な選択を行ってください。