インタビューVisual Studio .NET は 2002 年 2 月 13 日にリリースされ、Microsoft の Java 代替品がビジネスに対応可能になったと宣言された瞬間となりました。
2000 年の Professional Developers Conference での Microsoft .NET 発表のスクリーンショット。スコアは?
日付を特定するのは難しい。.NET Framework 1.0とVisual Studio .NET 2000は、2002年1月15日に開発者向けに初めて提供されたが、対象はMicrosoftの開発者ネットワーク（MSDN）の加入者のみだった。公式発表はサンフランシスコで開催されたVSLive! 2002カンファレンスで行われ、当時のCEOビル・ゲイツはこれを「XML Webサービスと次世代インターネットアプリケーションを構築するための、初の完全統合開発環境」と表現した。
Visual Studio .NET 2002: 20年前にリリース
.NET Framework が初めてプレビューされたのは、その18ヶ月前の2000年7月でした。当時を振り返ってみると、Windows 2000 がその年の2月にリリースされました。当時の Microsoft の開発プラットフォームは、Visual Studio 6.0 で構成されており、これは Visual C++、Visual Basic (VB)、FoxPro、Visual InterDev、Visual J++ といった個別の IDE をバンドルしたもので、Visual C++ は別として、これらの言語はすべて問題を抱えていました。
VBは広く普及していましたが、オブジェクト指向ではなく、COMやWindows APIを使った高度な用途には複雑で難解であり、ほぼすべての点でBorlandのDelphiに圧倒されていました。FoxProは独自の優れた点がありましたが、DBFデータベース形式はそうではありませんでした。一方、Access（Visual StudioではなくOfficeの一部）の方が人気が高く、SQLやSQL Serverとの互換性も優れていました。Visual InterDevは、MicrosoftがActive Server Pages（ASP）を用いたWeb開発に初めて挑戦した言語です。ASPはPHPのVB版のようなものでしたが、PHPのようなシンプルさとクロスプラットフォーム機能は備えていませんでした。
1996 年に Microsoft に移った Delphi の設計者 Anders Hejlsberg によって設計された Visual J++ は、Sun の Java の Microsoft バージョンであり、Windows 開発には非常に適していましたが、Java 仕様に準拠していなかったため、Sun から正当な訴訟の対象となりました。
当時、.NET Framework は新たな戦略における構成要素の一つに過ぎませんでした。「マイクロソフトの新世代テクノロジーをご紹介することが私たちの使命です」と、当時プラットフォーム戦略担当グループ副社長だったポール・マリッツ氏は、2000年7月に開催された同社のプロフェッショナル開発者会議（PDC）で述べました。
マリッツ氏は、その重要性を8年前にWindows NTで導入されたWin32 APIに例えました。開発中はNGWS（Next Generation Windows Services）と呼ばれていましたが、「最終的に.NETという名前に落ち着きました。これは、インターネットを真の分散コンピューティングプラットフォームにすることに貢献するために設計された一連の技術を象徴しているからです」とマリッツ氏は語りました。
マイクロソフトの構想は、インターネット上でデータを交換するためのXML標準であるSOAP（Simple Object Access Protocol）を用いたXML Webサービスによって駆動される、プログラム可能なWebでした。「私たちはこれをWebサービス・アーキテクチャと呼んでいます。私たちの.NETプラットフォームは、こうした種類のアプリケーションをより簡単に構築できるように設計されています」とマリッツ氏は述べています。
この戦略は、Passport ディレクトリと、翌年に発表された Hailstorm (コード名) という一連のファーストパーティ XML サービスによって同社をインターネットの中心に据えることを目的としていたが、反競争的懸念からすぐに断念された。
これが.NET Frameworkの導入の大きな流れでした。「Visual Basic、Visual C++、そして他の言語を共通の基盤に統合することは、長年の私たちの目標でした。…今日、私たちは真の汎用性を備えた、多言語対応の最新オブジェクト指向ランタイム環境を初めて実現しました」とMaritz氏は述べています。
彼の言葉遣いは、.NET FrameworkとJavaを区別しようとする試みでした。Javaと.NET Frameworkは多くの共通点があるように見えました。彼の主張は、Javaは単なる一つの言語であるのに対し、.NET Frameworkはあらゆる言語を実行できる「共通言語ランタイム」（CLR）を備えているというものでした。JVM言語の概念が一般的になり、.NET開発のほとんどがC#で行われている今日では、この区別は奇妙に思えますが、当時は重要な意味を持っていました。
マイクロソフトはオープンソースという切り札も切りました。「この共通言語ランタイムとクラスライブラリの知的財産権をすべて取得し、標準化団体に提供することで、真にオープンな標準規格となることを目指しています」とマリッツ氏は述べています。
実際のところ、同社はオープンソースの .NET にそれほど熱心ではありませんでした。共通言語インフラストラクチャ (CLI) の ECMA-335 は 2001 年 12 月に公開されましたが、これは .NET Framework の完全な仕様とは程遠いものでした。
マイクロソフトがオープンソースの.NETを真に支援し、クロスプラットフォーム化したのは、2014年に.NETが.NET Coreへとフォークした時でした。そして昨年でさえ、オープンソースリリースにダメージを与えかねない決定が下され、撤回されました。
マリッツ氏はまた、当時ASP+と呼ばれていたウェブアプリケーション用の新しいフレームワークについても言及した。「業界がGUI開発で行ってきたことを、ウェブ開発でも行う必要がある」と彼は述べた。
ASP+ Web フォームには、ドラッグ アンド ドロップで動作するビジュアル インターフェイス ビルダーがあり、VB プログラマーが Web サイトを構築できるようにするのに非常に役立ちましたが、後になってアーキテクチャ上の制限が明らかになりました。
Javaと.NET
Javaが.NETに及ぼした影響は複雑です。SunのJavaは、当時のビジネスコンピューティングにおけるMicrosoftの事実上の独占を覆そうとする意図的な試みであり、Visual J++とその後の.NETは、Microsoftの反撃の鍵となりました。
とはいえ、スコット・ガスリーと共にASP.NETを共同発明したマーク・アンダース氏によると、.NETの技術はVisual Basicチームから生まれたとのことです。彼は2007年に筆者に対し、CLRの初期コードネームである「Project Cool」について語り、ASP.NETの初期プロトタイプはJavaで書かれていたことを明かしました。「私はJavaという言語が好きでしたし、スコットもそうでした」と彼は言います。
「VBチームは新しいランタイムの開発に取り組んでいました。それが後に共通言語ランタイム（Common Language Runtime）と呼ばれるようになりました。COMほど複雑ではなく、優れたオブジェクトシステムを備え、ガベージコレクションも実行されました。そこで私たちは、当時XSPと呼ばれていたものをこの新しいランタイムで開発することに決めました。つまり、私たちはこの新しいランタイム上で何かを開発しようと最初にコミットしたチームだったのです」とアンダース氏は語った。
ヘルズバーグは.NETの重要な開発者でもありました。マイクロソフト入社後、Visual J++ 6.0とWindows Foundation Classes（WFC）の設計に携わりました。WFCには、コードの変更に応じてビジュアルデザインが更新され、その逆も可能となるDelphiスタイルの双方向ビジュアルデザインツールが含まれていました。ヘルズバーグは、ボーランドでのObject Pascalの経験を活かして.NET向けのC#言語を設計し、WFCをWindows Formsクラスライブラリへと改良しました。
「WFCからWindows Formsへの移行は、ほぼ機械的なものです。異なる規約を使用し、プロパティとイベントを適切にサポートする言語が現在では存在するため、特定の機能では構文が異なります。これは論理的に次の段階へと進化しましたが、WFCの直系の子孫であるため、コードに関して構造的に変更する必要はほとんどありません」とHejlsberg氏は2001年に述べています。
Hejlsberg 氏は、Delphi や VB と並んで「Java が .NET のインスピレーションとなった」と認めています。
Mono: Linux 向け .NET
.NET に関する興味深い事実は、今日のその地位が、Linux 向け GNOME デスクトップ環境の創始者としても知られる Miguel de Icaza が始めた、社外で開発された Mono と呼ばれるオープン ソース プロジェクトに大きく依存しているということです。
この記念すべき年に、私たちはデ・イカザ氏に話を伺いました。彼が.NETに興味を持ったのは、GNOMEアプリケーション向けのより優れたプログラミングツールを探していたことがきっかけでした。
「GNOMEの開発を始めた頃、当時のUnix界では、高水準言語の力で複雑さを軽減しようとする動きがありました」と彼は語る。「ジョン・オースターハウトという人物がTCLという言語とTKというUIツールキットを開発しました。アプリケーションを作るのは楽しかったのですが、問題はTCLが優れたプログラミング言語ではなかったことです。」
「しかし、彼は抽象度を上げたいという点を指摘しました。様々な取り組みがありました。ある時点ではJavaの使用も検討しましたが、JavaのJIT（ジャストインタイムコンパイラ）はまだ発展途上で、ツールキットも十分ではありませんでした。最終的に、C言語で書かれたGUIアプリケーション構築用のツールキット、GTKにたどり着きました。これは完全にオープンソースで、要件を満たしていましたが、C言語でのプログラミングが必要でした。私たちはこれを複数の言語で利用できるようにしたいと考えていました」とデ・イカザ氏は語る。
これを実現し、GNOMEチームはObjective-C、ADA、Perl、Python、C++、Schemeなどの言語向けのバインディングを作成しました。「プログラミングを高い抽象度に保つことが目的でした」とデ・イカザ氏は言いますが、パフォーマンスの問題がありました。「.NETが登場すると、多くの要件を満たすようになりました。高水準言語であり、コンパイル可能で、当時のスクリプト言語の欠点に悩まされることもありませんでした。」
「もう一つ興味深い点は、バイトコードのJITコンパイルが容易だったことです。Javaよりも作業量が多い部分もありましたが、非常に優れた構造体、デリゲート、インターフェースといった機能がありました。DLLインポートは私たちにとって非常に重要な要素でした。なぜなら、Cライブラリという形で利用可能な大きな資産があったからです。」
de Icaza 氏によると、Mono はもともと .NET の「ECMA サブセットのみ」をベースにしており、独自のスタックが補完されていたが、「ADO.NET や ASP.NET、Windows Forms など、あらゆる要素を取り入れようという貢献が殺到した」という。
Monoは、Microsoftの.NET Frameworkに代わるオープンソースでクロスプラットフォームな選択肢となりました。Microsoft社内には支持する者もいれば、慎重な者もいましたが、Monoは共存していました。そして2016年、MicrosoftはMonoの必要性を認識し、モバイルプラットフォーム向けのC#コーディングを可能にするために、de Icaza氏が共同設立したXamarinを買収しました。その時の感覚はどのようなものでしたか？
デ・イカザ氏はこの質問に直接答えていないが、マイクロソフトとの関係改善は「モバイルから始まり、Unityはモバイルで大きな成功を収めた」と述べている。Unityは、スクリプトにMonoを使用するゲーム開発エンジンである。
「モバイルがこうした力関係を変えた」とデ・イカザ氏は語る。当時すでにマイクロソフトとは「様々なパートナーシップ」を結んでいた。モバイルにおける.NETの必要性から、同社のビジネス部門はMonoに参画し、技術面でも常に良好な関係を築いていたとデ・イカザ氏は語る。
LonghornとSilverlightを思い出す
2003 年の Microsoft の PDC で、同社は Longhorn を発表しました。これは、3 つの「柱」の上に構築された、Windows の根本的に異なる新バージョンです。3 つの柱とは、.NET と DirectX に基づいたシェルの「Avalon」、リレーショナル データに基づいたファイル システムの WinFS、そして、同じく .NET コードに基づいた新しい Web サービス通信サブシステムの「Indigo」です。
2004 年半ば、Longhorn の状態が非常に悪かったため、Microsoft は Windows Server 2003 コードに基づいて開発を再開しなければならなくなり、開発リセットと呼ばれる危機に陥りました。
再設計された Longhorn では .NET への依存が減り、Windows Presentation Foundation となった Avalon は、シェルの不可欠な部分ではなく、単なる別のアプリケーション フレームワークになりました。
このコストのかかるリセットを引き起こす上での .NET の明らかな役割は、Microsoft 内の Windows チームに長期的な影響を及ぼしたようで、数年後の Windows 8 では、.NET ではなく「モダン」アプリケーション用の新しいフレームワークが使用される要因になった可能性があります。
何が間違っていたのでしょうか? 2007 年に Microsoft に入社し、現在は .NET プログラム管理ディレクターを務める Scott Hunter 氏に話を聞きました。
「Longhornには、ファイルシステムをSQL Serverベースにし、デスクトップを.NET上に構築するという、かなり突飛なアイデアがいくつかありました」とハンター氏は語る。「時代を先取りしていました。当時のコンピュータハードウェアは、Longhornのアイデアのほとんどに対応していませんでした。素晴らしいのは、これらのコンセプトの多くが現在にも応用できることです。例えば、スタートメニューは最新のWindows上で.NET上に構築しました。そのため、当時の名残が今も残っているのです。」
.NETにとってもう一つの苦い時期は2010年でした。別のPDCで、Windows Phoneでも使用されていたクロスプラットフォームのブラウザアドオンであるSilverlightが、HTMLとJavaScriptに取って代わられたことが明らかになったのです。当時、Server and Tools部門の社長だったボブ・マグリア氏は、「戦略が転換した」と告白しました。Silverlightは当初、同社の将来のプラットフォームの重要な部分だと思われていたからです。最終的に、SilverlightとWindows Phoneはどちらも廃止されました。
Silverlightについて考えると、Silverlightが今も生きていることがわかります。NET 6.0はSilverlight上に構築されています。
「Silverlightについて考えてみると、Silverlightは今も生きていると実感します」とハンター氏は反論する。「.NET 6.0はSilverlight上に構築されています。2014年に.NET Coreを開発し、.NET Coreの旅の始まりを迎えた時、私たちは既に構築していたクロスプラットフォームの.NETであるSilverlightのランタイムを採用しました。そのため、その技術は今も生きています。こうした歴史は今日では何の意味もありません」と彼は言う。
.NET の次のリリース: MAUI
ハンター氏は、昨年末にリリースされた .NET 6.0 は「統一化によって、突然、デスクトップ、モバイル、Web など、あらゆる種類のアプリを同じ BCL (基本クラス ライブラリ)、同じランタイム、すべて同じコンパイラで構築できるようになった」ため、テクノロジにとって大きな出来事だったと述べています。
- FlutterがWindowsに登場、実稼働環境に適していると発表
- 参考までに: Visual Studioの旧バージョンのサポートは4月に終了します
- Microsoftの万能IDE「Visual Studio 2022」が昨年末にリリースされました。一体どれほど優れているのでしょうか？
- いくつかのエラーが画面に表示されます。また、.NET Framework から発生するエラーもあります。
リリース時に欠けていた部分はクロスプラットフォームのデスクトップ アプリケーションでしたが、Xamarin をベースとした MAUI (マルチプラットフォーム アプリ UI) のリリースですぐに解決される予定です。
「Buildでは、RTM（製造向けリリース）MAUIを実施します。」BuildはMicrosoftの開発者会議で、2022年の日程はまだ発表されていないが、通常は5月に開催される。
ハンター氏はMAUIの背景にある考え方をこう説明する。「私たちがやりたくないことの一つは、新しいUIスタックを構築することです。そのため、MAUIは既存のUIスタックをラッパー化するものです。UIスタックを作ろうとする時代は終わりました。」
WindowsならWinUIを、MacならMacとiOSで動作するアプリを開発できるCatalyst技術を、AndroidならネイティブAndroidをラップします。将来的には、必要に応じてFlutterなどをラップすることも可能です。MAUIは、すべてのUIスタックの上に構築された抽象化です。
Hunter氏のコメントは興味深い。なぜなら、Googleが最近Windowsデスクトップアプリケーション向けにリリースしたクロスプラットフォームのFlutterは、MAUIの競合とみなされているからだ。クロスプラットフォームGUIフレームワークは、Silverlight、Flutter、JavaのSwingやJavaFXといった独自のコントロールを描画すべきか、それともXamarinやJava SWTといったネイティブコントロールをラップすべきかという長年の議論において、どちらかの立場をとる、別の哲学として捉えた方が良いかもしれない。
「ネイティブ UI を使用しない独自の UI コントロール セットを構築することもできますが、現在はネイティブ UI の方向に進んでいます」と Hunter 氏は語ります。
MAUI: Monoランタイムがまだ使用されていることを発見
Slack、Teams、Visual Studio Codeなど、Electronスタイルのアプリケーションの爆発的な増加は誰もが目にしているでしょう。私たちは、この流れに.NETも確実に取り入れたいと考えました。MAUI内にBlazorコントロールを配置することで、Webとネイティブ技術を融合し、すべて.NETで記述されたアプリケーションを実現できるのです。
.NET の将来
ハンター氏は、StackOverflowの調査によると、.NETは「最も愛されている」カテゴリの一つで3年連続トップの座を占めていると指摘した。アクティブユーザー数は増加傾向にあると彼は主張する。「.NETは現在540万人を超えています。Javaは1000万人程度と推定しています。」
「.NET 6.0をリリースしていた当時、私たちは最も高速なオープンソースプロジェクトのトップでした」とハンター氏はCNCF（Cloud Native Foundation）のデータを参照しながら述べています。「コーディングマイルストーン以降は3位か4位にまで落ちましたが、2017年以降は常にトップ30に入っています」
.NETアプリケーションのLinuxへの導入がますます増加していることも注目に値します。「今年中には、.NET 6.0以下のアプリケーションの利用の半分がLinuxになるでしょう」とハンター氏はWebアプリケーションについて述べています。
こうした楽観的な見方にもかかわらず、.NETには暗い影が差している。.NETは依然として主に1つの企業に依存しており、.NET Foundation独自の調査では、開発者がWindows、Microsoftのプラットフォーム、そして経験豊富な開発者に偏っていることが示されており、新人プログラマーにとっての魅力は限られていることが示唆されている。
.NET の歴史を振り返ると、多言語対応は部分的にしか成功しておらず、.NET 開発のほとんどで C# が使用され、VB は衰退し、F# は小さいながらも重要なニッチとなっていることも明らかです。
しかし、2014 年に公式のクロスプラットフォーム .NET を導入することは、技術的にも、プラットフォームの将来にとっても正しい選択であったことも明らかです。
20 年以上前に Maritz が期待した通りには物事は進んでいませんが、C# と .NET プラットフォームは目覚ましい成功を収めています。®
