Microsoft は 64 ビットの Visual Studio を発表しましたが、最新の開発環境への移行を急いでいるため、古い Windows や Azure テクノロジを使用している開発者の中には取り残されていると感じている人もいます。
64ビット版Visual Studio 2022（VS 2022）のリリースは、10年以上も待ち望まれてきた開発者にとって大きなニュースです。しかし、開発者コミュニティ、特に古いMicrosoftテクノロジーを使用している開発者にとって、Visual Studioはまだ解決すべき難題を抱えています。また、フルバージョンのVisual Studioでは、より機敏なクロスプラットフォーム対応の兄弟であるVS Codeに追いつくのが難しい領域もあります。
ここでの背景は、今日のマイクロソフトが最も重視しているのは、Azureプラットフォームの開発者獲得であるということです。VS CodeとGitHubの組み合わせは戦略的なものです。これらのツールはAWSやGoogle Cloudといった競合プラットフォームでも問題なく動作しますが、マイクロソフトはAzureとの緊密な統合を保証できるからです。
さらに、近々登場するリモート開発環境「GitHub Codespaces」などの機能もAzure上で動作します。MicrosoftはAzureとGitHub開発向けにVisual Studioの改良も進めています。製品担当コーポレートバイスプレジデントのAmanda Silver氏は、VS 2022ではGitHubのワークフローとアクション、そしてAzureリソースに基づいて、「プロジェクトを初めて作成する際に、完全なCI/CDソリューションが構築される」と約束しました。
こうしたあらかじめ用意された魔法によって、開発者の時間が節約され、開発者が Microsoft のプラットフォームに魅了され続けるようになります。
マイクロソフトは避けられない事態に屈し、2022年版のVisual Studioを64ビット版に採用した。
続きを読む
とはいえ、現代の開発環境においてVisual Studioにはいくつか問題があります。まず、Visual Studioは主にWindowsで動作することです（Visual Studio Mac版もありますが、これについては後ほど詳しく説明します）。現代の開発環境はWebクライアントとモバイルクライアントが主流であり、WindowsはUnix系ではない唯一の共通プラットフォームとして孤立化が進んでいます。そのため、一部の開発者がWindowsを使い、他の開発者がMacやLinuxを使う場合、行末、ファイルモード設定、Bashスクリプト、Node.jsモジュールなどで軋みが生じる可能性があります。
Microsoft は、Windows での作業をハイブリッドな Windows/Linux エクスペリエンスにするために Windows Subsystem for Linux に投資してきましたが、VS Code はすでに WSL を強力にサポートしており Visual Studio よりも優れています。
2 つ目の問題は、Visual Studio はブラウザー統合を伴う JavaScript および TypeScript のデバッグには適していないことです。
Git統合は3つ目の問題です。VS CodeのGit統合は優れていますが、Visual Studioではサブモジュールのサポートが不足しており、実質的に複数のリポジトリが開かれているなどの問題があります。開発者のJoris Kommeren氏は、今週初めにチームがGitサポートについて投稿した記事に対し、「Gitの基本的なエクスペリエンスを書き換えて使い勝手を良くするのはやめて、開発者にとって本当に障壁となっているものを組み込むべきです！」と述べました。
Microsoft プログラム マネージャーの Pratik Nadagouda 氏は、「これは解決が難しく複雑な問題です。まずはマルチリポジトリのサポートに取り組むことから始めました」と答えました。
私の新しい世界で生きるか、あなたの古い世界で死ぬか
Microsoftにとってもう一つの課題は、Visual Studioを現代の開発環境に適応させるにつれて、依然として古い技術を使用している開発者を取り残してしまうリスクがあることです。例えば、Team Foundation Serverから進化したソフトウェア開発・ライフサイクル管理ツールであるAzure DevOpsと、Microsoft Officeを拡張するための旧来のツールセットであるVisual Studio Tools for Office (VSTO)が挙げられます。
Azure DevOpsユーザーは、MicrosoftがVisual StudioのGitHubサポートを改善するにつれて、ユーザーエクスペリエンスが後退するのではないかと懸念している。Microsoftが「新しいGitエクスペリエンス」を導入したことで、Azure DevOpsの利用が難しくなった。「リポジトリを作成し、『プッシュ』を選択すると、GitHubとGitHub Enterpriseの2つの選択肢が表示されます。ああ、違います」と開発者のハワード・リチャーズ氏は述べた。「GitHubが『流行っている』のは分かっていますが、MicrosoftがGitHubに注力するあまり、DevOpsリポジトリをないがしろにしているようにしか思えません」と別のユーザーは述べた。
VSTOはどうですか?
VSTOを.NET 5（旧称.NET Core）に移植するという長年にわたる機能要望は、未だ解決されていません。ここで問題となっているのは、Microsoftが開発者に対し、OfficeアドインをJavaScriptとWebベースモデル（Office 365とクロスプラットフォームで動作する）に移行するよう働きかけてきたものの、開発者側はこのアプローチは強力ではなく、移植ツールも存在しないと指摘していることです。
「当社は製品の提供にVSTOを利用しています。OfficeJSが将来性を持っていることは理解していますが、OfficeJSベースの後継製品が開発されるまでの数年間は、現在の製品を維持していく必要があります。さらに、VSTOはOfficeJSにはない機能を提供しています。また、VSTOは2010年以降、実質的にアップデートされていないことも付け加えておきます」と開発者のエリック・スミス氏は述べています。
「当社のコアな社内プロセスの多くは、ドメインエキスパートをサポートする社内VSTOアドインによって実現されています。これはC#コードベースに依存しており、主にC#の経験を持つエンジニアによってメンテナンスされています。私が最後に調べたところ、OfficeアドインはVSTOアドインで実行できるすべての機能をサポートしていませんでした。いずれにせよ、これをJavaScriptに移植し、チームを再教育するには多大なコストがかかります」と別のユーザーは述べています。
過去の経験から、Microsoft は古いテクノロジ (VSTO アドインなど) との互換性を長期間維持する一方で、それらに大幅な追加投資を行うことはないと考えられます。
WindowsよりもLinuxが多い
こうした現実のビジネス ニーズは、Microsoft が Windows ベースの最も忠実な開発者からツールの維持と強化を迫られる一方で、Windows よりも Linux に近いクラウド ベースのプラットフォームに移行するという、2 つの方向から圧力を受けていることを示しています。
Visual Studioのクロスプラットフォーム対応はどうでしょうか？VS Codeがクロスプラットフォームツールだと思われがちですが、MicrosoftはVisual Studio for Macも提供しており、Visual Studio for Linuxの要望も高まっています。ネイティブARM64版の要望も上がっています。
Mac版はXamarin経由でMicrosoftに導入され、元々はMonoDevelopという.NET IDEをベースにしていたため、歴史的な偶然と言えるかもしれません。Silver氏は「Visual Studio for MacをネイティブmacOS UIに移行する作業を進めています」と述べていますが、このツールの今後、そして今後C++で記述されるコードが増えるのかどうかなど、多くの疑問が浮かび上がります。
現時点ではWindows版Visual Studioよりも機能が劣っており、主な役割は依然としてXamarin開発であり、これはMAUI（Multi-Platform pp UI）となる予定です。MicrosoftがVisual Studio Windows版とMac版で可能な限りコードを共有することは理にかなっていますし、クロスプラットフォームコードの増加は将来のVisual Studio for Linuxにも役立つでしょう。しかし、Windows専用開発向けの機能をさらに損なうことなくVisual Studioをクロスプラットフォーム化することは難しいかもしれません。®
