Project System Extensibility プレビューの紹介


本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Introducing the Project System Extensibility SDK Preview  2015/06/02 9:00 AM

[6/4 更新情報: 本記事の内容を一部更新しました。Project System Extensibility がプレビュー段階を終えて Visual Studio SDK の一部となるまでのロードマップをさらにわかりやすくしています。]

マイクロソフトはこのたび、Project System Extensibility プレビュー (英語) の提供開始を発表しました。Project System Extensibility プレビューを使用すると、新しいプロジェクト タイプを定義し、わずか数分で拡張機能の作成を始めて、ユーザー エクスペリエンスのカスタマイズや機能の追加をできるだけでなく、全体のコード量をごく少量に抑えることが可能になります。コードが 10 万行を超えるようなプロジェクト システム (通常、MPFProj をベースとする派生コード) の全体を作成したり管理する必要はもうありません。Project System Extensibility プレビューを使用すれば、今後は Visual Studio に組み込まれた、C++、JavaScript、ASP.NET 5 で既に利用されている共通プロジェクト システム (Common Project System。以下、CPS) をベースに開発を行えます。以下に Project System Extensibility に関するショート ビデオを用意しましたのでご覧ください。

マイクロソフトが CPS を構築したのは、お客様が近年求めている拡張性、パフォーマンス、応答性、再ホスト可能性といった面に対処すると共に、開発期間を短縮するためです。

CPS MPFProj の違い

Visual Studio のプロジェクト システムを作成したことがある方は、MPFProj に馴染みがあることと思います。馴染みがあるどころか、独自のプロジェクトシステムのベースとして利用していた方もいるかもしれません。MPFProj が採用しているソース コードの配布モデルでは、ソース ツリー全体をフォークし、カスタマイズして、提供するバイナリに組み込む必要があります。

この手法における問題は、バグ修正や機能追加のために MPFProj のコードベースが更新された場合、その変更を自分のコード ベースに手動でマージして、プロジェクト システムを再度提供しなければならない点です。MPFProj 自体が巨大なコードベースであり、妥当な量を超えるバグが含まれているうえ、C# や VB と共通の機能は比較的少量です。MPFProj ベースで独自のプロジェクト システムを作成するのは非常に手間がかかり、提供できる状態に持っていくまでに何人月もの工数がかかる可能性があります。

一方、Project System Extensibility プレビューの場合は、Visual Studio に組み込まれているプロジェクト システムの拡張機能を作成することになります。つまり、プロジェクト システム全体を開発する必要がありません。代わりに、マイクロソフトの参照アセンブリを使用してプロジェクトシステムの拡張機能をコンパイルしてから、その拡張機能を提供するだけで済みます。

Visual Studio がプロジェクトを読み込む際、そのプロジェクトに適用される拡張機能もすべて読み込まれるので、ユーザーは追加された機能や細かく調整された動作をすべて確認することができます。また、後日マイクロソフトが Visual Studio プロジェクト システムのバグを修正した場合、それらの修正は、ユーザーが Visual Studio Update を適用したか、より新しいバージョンの Visual Studio にアップグレードしたときにプロジェクト タイプに自動的に適用されます。

MPFProj をはじめとする多くのプロジェクト システムが抱えるもう 1 つの欠点は、プロジェクト システムが実行時にブラック ボックス化することです。そのため、プロジェクトシステムの再利用や変更を行う場合は、COM 集成に頼らなければなりません。この場合、プロジェクトシステム全体を使用しているように見えるものの、そのごく一部を実装しているにすぎず、その他の機能要求をすべて「内側の」プロジェクト システムに転送する必要があります。この手法は複雑であり、外側の「フレーバー」の動作が変化したときに内側のプロジェクトシステムの内部状態を損なうような軽微なバグにつながりやすいのです。

Project System Extensibility プレビューでは、既存のプロジェクト タイプのフレーバーを作成するうえで COM 集成を使用 (またはサポート) する必要はなくなります。代わりに、MEF 拡張機能を作成し、適用対象のプロジェクトを記述した属性を使用してその拡張機能にタグ付けを行います。詳細については、オープン ソースのドキュメント (英語) を参照してください。

既存のプロジェクト システムがあるのですが、CPS に移行したらどのようなメリットがありますか?

Visual Studio プロジェクト システムは一貫して MPFProj よりもはるかに優れたパフォーマンス、拡張性、応答性を備えた設計になっています。開発者独自のプロジェクトシステムと、マイクロソフトが提供するその他のプロジェクト システムとの差が解消されるように、手間をかけずに最初の移行とその後の機能の有効化を行えるようになっています。開発者独自のプロジェクトシステムで機能を再実装して管理する必要はありません。Visual Studio プロジェクト システムに新機能が追加されたときに、必要に応じてそれらの機能を有効化することができます。

また、スリム化という点では、移行後のコード サイズは移行前と比べてはるかに小さくなると考えられます。たとえば、Windows 8 JavaScript プロジェクト タイプ向け拡張機能の一連のコードは約 15,000 行であり、コーディングの開始時に 40,000 行もある MPFProj よりも 62% も行数が少なくなります。そして、それほどカスタマイズを行わなければ、開発者独自のプロジェクト拡張機能は間違いなく 15,000 行よりもずっと少なくなります。

ただし、移行する場合は、既存の MPFProj コード ベースを CPS 向けに急いで変換しないようにしてください。まず Project System Extensibility プレビューを使用して新しいプロジェクト タイプまたはフレーバーを用意してから、MPFProj ベースのプロジェクトシステムで提供していた独自の動作を再現するための拡張機能を追加し、必要に応じてその部分のコードのみを移行するようにします。コードを書き換えなければ直接動作を移行できない場合もありますが、書き換えを行うと、多くの場合これまでよりもはるかに行数が少なく管理しやすいコードになります。

私にとって CPS の使用は適切なのでしょうか? また、なぜまだプレビュー段階なのですか?

ここまでご説明してきたとおり、CPS の使用によってさまざまな面が簡素化されることを踏まえると、CPS の使用が適切なのかと尋ねれられれば、多くの場合「はい」と答えることになると思います (ほとんどの方にはそうお答えすると思います)。しかしながら、一部の開発者の方には適していない場合もあります。たとえば、Visual Studio 2013 以降が必須になると困る場合や、ご自身のプロジェクト タイプでプロジェクト システムの動作をカスタマイズすることが必要で、まだ拡張ポイントとして公開していない場合などです。いずれにしましても、皆様が実現したいことや何か移行の障害になっていることがありましたら、こちら (英語) までご意見をお寄せください。

現時点では、Visual Studio 2015 において CPS はプレビューの段階にあります。引き続き Visual Studio 2015 に組み込むべくこの CPS の安定化に努めてまいります (Visual Studio Update を適用しても、プロジェクト システムの拡張機能の作成が妨げられることはありません)。なお、Visual Studio 2015 の次に発表されるメジャー リリースでは、最後にもう一度、大幅な変更が行われる予定ですマイクロソフトは Visual Studio 2015 リリース (RC 以降) を、コミュニティからご意見をお寄せいただく機会と捉えており、既に計画中のいくつかの変更に伴って API の変更を行う可能性があります。これは、次期バージョンで最後に大幅な変更を行わないで済むようにするためです。

新しい Visual Studio プロジェクト システムは、Visual C++ の限定的な利用 (C++ は現在も独自のプロジェクト システムを半分実装) や、JavaScript、ASP.NET vNext について実証済みです。とはいえ、これはマイクロソフトが他のプロジェクト システム全体で提供しているすべてのシナリオには必ずしも当てはまりません。実際のところ、私たちが作業を続けているこうした他のシナリオの一部について、バグがあることを確認しています。皆様が CPS に切り替えるにあたっては、次の 2 点を考慮してください。1 つは、バグに行き当たるリスクがあること、もう 1 つは、そうしたバグやその他の問題点に関するフィードバックを早い段階で私たちに報告していただき、Visual Studio 2015 Update かその次のメジャー リリースで修正されるようにご協力いただくことになるということです。多くの皆様に試験的に移行していただき、フィードバックや (あわよくば) 成功体験をお寄せいただければ幸いです。

CPS に移行する最適なタイミングを判断するには、こちらの概要ドキュメント (英語) を参照してください。

CPS のロードマップ

いずれは、マイクロソフトが提供する新しいプロジェクト タイプの大部分またはすべてが、CPS をベースとしたものになると考えています。Visual Studio の次期バージョンでは、既存のプロジェクト システムの一部を CPS に移行する予定です。Project System Extensibility の API が安定すれば、プレビュー段階を終え、Visual Studio SDK に追加となります。

マイクロソフトでは、新しい機能を提供するにあたって必ず成果を図る指標を定義するようにしています。この新しいプロジェクト システム プラットフォームにおいては、お客様がこのプロジェクトシステムの存在を意識しなくなったときがその成果となります。Visual Studio の単なる一部のように感じられるようになり、拡張や微調整も、エディターや新しい C#/VB 言語サービス (Roslyn)、IDE の最新コンポーネントを拡張するのと同じくらい簡単なものにしなければなりません。そのために私たちは、まったく新しいプロジェクトシステムを作り出すのではなく、新しいプロジェクト タイプや既存のプロジェクトタイプの「フレーバー」を作成する拡張機能を定義しました。皆様には、バグの修正や最新バージョンで C# や C++ に追加された機能の再実装に時間をかけるのではなく、ユーザーにとって有益かつ独創的なプロジェクトタイプやフレーバーを作成するために力を注いでいただきたいと考えています。また、マイクロソフト独自のプロジェクト タイプの中から可能な限り多くの機能を皆様に公開し、ご自身のプロジェクトタイプでご利用いただけるようにすることも目指しています。新しい Project System Extensibility プレビュー (英語) をぜひお試しいただき、Readme (英語) に記載されている方法、またはページ下部のコメント欄までご意見をお寄せください。

最後までお読みいただきありがとうございました。

Andrew

image

Andrew Arnott、Visual Studio IDE 担当プリンシパル ソフトウェア エンジニア
@aarnottMSDN ブログ (英語)個人ブログ (英語)StackExchange (英語)

Andrew Arnott はマイクロソフトに勤務して 9 年になり、Visual Studio プラットフォーム、プロジェクト システムとビルド システム、.NET Compact Framework の開発に力を注いでいます。プライベートでは 3 児の父でもあり、4 人目も生まれる予定です。

Comments (0)

Skip to main content