Quantcast
Channel: Visual Studio 日本チーム Blog
Viewing all 182 articles
Browse latest View live

Visual Studio “15” でのソリューション読み込み時間の短縮

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Shorter Solution Load Time in Visual Studio “15” 2016/10/11

 

今回の記事は、Visual Studio “15” のパフォーマンス強化について 5 回にわたってお伝えするシリーズ記事の第 2 回です。

前回は、Visual Studio “15” の起動の高速化についてお伝えしました。今回は、ライトウェイト ソリューション ロードという Visual Studio “15” の新機能について説明します。この機能を使用するとソリューションの読み込み時間が大幅に短縮され、IDE の高速化と生産性の向上につながります。

ライトウェイト ソリューション ロード

簡単に言うと、ライトウェイト ソリューション ロード機能が有効化されている場合、実際に作業を開始するまでプロジェクトを完全には読み込みません。すべてのプロジェクトの読み込みが完了していなくとも、コードベース内のナビゲーション、コード編集、プロジェクトの構築などの一般的なタスクの多くは実行可能です。

ライトウェイト ソリューション ロードは、Visual Studio “15” Preview 4 で、実際のプロジェクトでの動作に関する情報を収集するための限定機能としてリリースされました。これまでのところ、パフォーマンスは良好な結果を示しています。

限定ロールアウトでは、ソリューションの読み込み時間が半分から 4 分の 1 であることが確認されています。

この機能の最終的な目標は、IDE を可能な限り迅速に使用可能な状態にすることです。ライトウェイト ソリューション ロードを使用した場合、コードを開いて作業を始めるまでの時間が 1 ~ 2 分短縮されることが確認されています。Preview 5 のリリース後も同様の結果が得られることを期待しています。

ぜひお試しください

ライトウェイト ソリューション ロードは、Preview 5 では既定で有効化されていませんが、中規模から大規模の管理されたプロジェクトに携わる開発者の方は、ぜひこの機能をご使用いただき、ご意見をお聞かせください。ライトウェイト ソリューション ロードを使用するには、[Tools]、[Options]、[Projects and Solutions]、[General] の順に選択し、ページ下部の [Lightweight Solution load] チェックボックスをオンにします。

ライトウェイト ソリューション ロードの有効化後は、通常どおりにプロジェクトやソリューションを開いて作業することができます。設定はその後のソリューションの読み込み時に適用され、IDE を再起動する必要はありません。

Preview 5 では、ライトウェイト ソリューション ロードは管理されたプロジェクトを対象としています。中規模から大規模の C# ソリューションや VB ソリューションで作業する場合、この機能を使用することを強くお勧めします。C++ や他の種類のプロジェクトとの複合ソリューションを開くこともできます。ただし、他の種類のプロジェクトではパフォーマンス強化の一部が適用されない場合があるので注意が必要です (注意事項を参照*)。

ライトウェイト ソリューション ロードの有効化は、動作が高速化されるというメリット以外、実作業への影響はありません。この機能でぜひ以下のことを試してみてください。

  • コードベースのナビゲーションに [Navigate To] (Ctrl+,) や [Go to Definition] (F12)、[Find in Files]、[Find all References] を使用する
  • リファクタリングやインラインでの名前の変更
  • ソリューションの構築やデバッグ

操作によっては、バックグラウンドでプロジェクト データを読み込む際に、若干時間がかかる場合があります。

ライトウェイト ソリューション ロードは現在試験提供中のため、改善すべき点も残っています。

  • プロジェクトに関連する機能が IDE で表示されない場合は、ソリューション エクスプローラーでプロジェクトを開いてみてください。作業中に予期しない挙動があった場合はご報告をお願いします。
  • NuGet パッケージの復元はまだ統合されていません。ライトウェイト ソリューション ロードを有効化する前にパッケージを復元するか、またはコマンド ラインを使用することをお勧めします。
  • プロジェクトがすべて読み込まれるまでテスト エクスプローラーにテストが表示されません。
  • ソリューション内のすべてのプロジェクトでターゲットの変更やアップグレードを行う場合は、ライトウェイト ソリューション ロードを無効化しておくことをお勧めします。

*Preview 5 では、ライトウェイト ソリューション ロードは管理されたプロジェクトを対象としていますが、C++ 開発者の方にも Preview 5 で実装された多数のパフォーマンス強化をご利用いただけるようになります。シリーズの第 4 回の記事で紹介しますのでご期待ください。これらの機能強化は、今後のリリースでライトウェイト ソリューション ロードに統合される予定です。

フィードバックのお願い

ぜひライトウェイト ソリューション ロードをご利用いただき、ご意見をお聞かせください。IDE の読み込みが遅かったり、応答がなかったりするなど、パフォーマンス関連の問題が発生した場合は、IDE の右上に表示されている [Report a problem] ツール (英語) からご報告ください。ここでリンクしているツールは、パフォーマンスの問題の診断に必要なトレースやその他のアセットを自動的に収集します。

大規模なコードベースを使用している開発者の方で、作業エクスペリエンスのフィードバックにご協力いただける場合は、簡単なアンケート (英語) に連絡先と開発作業に関する質問への回答をご記入いただけますと幸いです。今後の開発エクスペリエンス改善の参考とさせていただきます。

Will Buik (Visual Studio IDE プロジェクトおよび構築担当プログラム マネージャー)

Will Buik は経験豊富な Visual Studio ユーザーで、Visual Basic 4 でプログラミングを始めて以来、プログラミングやソフトウェア開発、ハードウェアの構築を得意とし、現在は長年使用している開発ツールの業務に従事しています。

 


Visual Studio “15” でのメモリ不足によるエラーが減少

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Reduced Out of Memory Crashes in Visual Studio “15” 2016/10/12

 

今回の記事は、Visual Studio “15” Preview 5 のパフォーマンス強化についてお伝えする 5 回のシリーズの第 3 回です。これまでの 2 つの記事では、Visual Studio “15″ で可能になった起動時間の短縮ソリューションの読み込み時間の短縮についてお伝えしました。

Visual Studio には多様な機能が詰め込まれており、実に多くの開発者が業務で活用しています。高い応答性を確保しながらこれらの機能をサポートするためには、大量のメモリが必要になります。しかし、Visual Studio 2015 では特定のシナリオでメモリ使用量が増えすぎることで、メモリ不足によりクラッシュしたりインターフェイスの応答が悪くなったりするという報告がお客様から多数寄せられました。VS “15” では、Visual Studio の高い機能性とパフォーマンスを維持しながら、これらの問題を解決することに取り組んでいます。

Visual Studio ではさまざまな分野で機能の最適化を進めていますが、今回の記事では JavaScript と TypeScript の言語サービス、デバッガーでのシンボルの読み込み、VS での Git のサポートの 3 つの分野について説明します。この記事では、全体を通じてそれぞれのシナリオで測定した下記の 2 つのメトリックを比較し、改善状況についてお伝えします。

ピーク時の仮想メモリ使用量: Visual Studio は 32 ビット アプリケーションであるため、仮想メモリの使用量は 4GB に制限されます。仮想メモリに割り当てられたメモリがこの制限を超過すると、「メモリ不足 (OOM: Out of memory)」エラーが発生し Visual Studio がクラッシュします。ピーク時の仮想メモリ使用量は、この 4GB の制限にプロセスがどの程度近付いたか、つまりプロセスがクラッシュするまでどの程度の余裕が残っていたかを示します。

ピーク時のプライベート ワーキング セットのサイズ: 物理メモリ内には、プロセスが実行するコードや使用するデータが含まれる仮想メモリのサブセットが必ず存在します。「ワーキング セット」とは、その物理メモリの使用量を表すメトリックです。このワーキング セットの一部である「プライベート ワーキング セット」は、特定のプロセスのみが使用しているメモリです。これは複数プロセスの間で共有されないため、メモリ使用量が比較的大きくなります。この記事では、Visual Studio (devenv.exe) プロセスとそれに関連するサテライト プロセスのプライベート ワーキング セットのピーク時の使用量の計測値を示します。

JavaScript 言語サービス

Visual Studio 開発者の 3 人に 1 人は日常的に JavaScript (JS) コードを作成しており、JS 言語サービスを多数の Visual Studio セッションのコンポーネントの 1 つとして読み込んでいます。JS 言語サービスは、JS の編集エクスペリエンスの生産性を高める IntelliSense やコード参照などの機能を提供します。

このような生産性機能をサポートしつつ高い応答性も確保するために、言語サービスはかなりのメモリを消費します。メモリ使用量はソリューションの内容によって変化し、主にプロジェクト数、ファイル数、ファイル サイズの影響を受けます。さらに、JS 言語サービスは C# などの他の言語サービスと同時に VS に読み込まれることも多いため、プロセスでのメモリ使用量がさらに増加する原因となります。このため、メモリ不足による VS のクラッシュを減少させるためには、JS 言語サービスのメモリ使用量の削減が不可欠です。

VS “15” では、JS コードのサイズや内容によらず、メモリ使用量の増加が Visual Studio の信頼性に影響しないよう対策が実施されています。JavaScript の編集エクスペリエンスの品質を低下させることなくこの目標を達成するために、VS “15” Preview 5 では JS 言語サービス全体をサテライト プロセスの Node.js プロセスに移行し、そこから Visual Studio に処理内容を返すようにしました。また、JavaScript と TypeScript の言語サービスを統合し、両方の言語サービスが読み込まれるときのセッションの総メモリ使用量を削減しました。

メモリへの影響を測定するために、下記のシナリオの場合の Visual Studio 2015 Update 3 と VS “15” Preview 5 の結果を比較しました。

  • WebSpaDurandal (英語) ソリューションを開きます。このソリューションは Asp.Net のサンプルで、VS で開かれた JS コードのサイズの 95% パーセンタイル値を表しています。
  • _references.js を作成し自動同期を有効にします。
  • 10 個の JS ファイルを開きます。
  • 編集、補完機能の使用、ファイルの作成や削除、フォーマット ツールの実行を行います。

このシナリオでは下図のような結果が得られました。

グラフ 1: JavaScript 言語サービスのメモリ使用量

Visual Studio のピーク時の仮想メモリ使用量は 33% 削減され、JS 開発者にとってメモリ不足によるクラッシュを減少させるには十分な効果が得られます。Preview 5 ではピーク時のプライベート ワーキング セットの合計サイズが Visual Studio プロセスとその子ノード プロセスの合計を表していますが、こちらは Visual Studio 2015 とそれほど変わりません。

デバッガーでのシンボルの読み込み

デバッグ作業の生産性を高めるためには、シンボル情報が不可欠です。マイクロソフトの最新の Windows 用コンパイラでは、シンボル情報は PDB ファイルに格納されています。PDB ファイルには、関数名、実行形式のバイナリのオフセット、実行ファイルで定義されているクラスや構造の型情報、ソース ファイル名など、該当するコードに関する情報が大量に含まれています。Visual Studio のデバッガーが呼び出しスタックを表示したり変数や式を評価する場合、それに対応する PDB を読み込み、その中の関連する部分を参照します。

Visual Studio 2012 よりも前のバージョンでは、複雑な Natvis ビューで型の評価を行っていましたが、パフォーマンスはあまりよくありませんでした。これは、大量の型情報をオンデマンドで PDB から取得するときに、ディスク上に存在する PDB ファイルへのランダム IO が多数発生するためです。従来型のハード ディスク ドライブでは、よいパフォーマンスを得ることは困難です。

Visual Studio 2012 では、この機能が C++ のデバッグ エクスペリエンスに追加され、デバッグ セッションの初期に大量のシンボル データを PDB から事前に取得するようになりました。これにより、型を評価するときのランダム IO がなくなり、パフォーマンスは大幅に向上しました。

しかしこの最適化の結果、場合によっては必要以上の量のシンボル データが大量に読み込まれ、事前に取得されるシンボル データの量が多くなりすぎるという問題が発生しました。たとえば、呼び出しスタックが表示されるときに、[Locals] ウィンドウや [Watch] ウィンドウなどの型の評価が不要なデータを含め、スタックのすべてのモジュールからシンボル データが事前に取得されていました。大規模なプロジェクトにはシンボル データを使用可能なモジュールが多数含まれており、各デバッグ セッションでのメモリ使用量はかなり大きくなります。

VS “15” Preview 5 では、事前取得により向上したパフォーマンスを維持しながら、シンボル情報が使用するメモリの量を削減しました。今回のバージョンでは、変数や式の評価や表示に必要なモジュールのみが事前取得されるようになりました。

これについて、下記のシナリオでメモリ使用量の変化を測定しました。

  • Unreal Engine ソリューションの UE4.sln を読み込みます。
  • Unreal Engine エディターを起動します。
  • VS デバッガーを Unreal Engine のプロセスにアタッチします。
  • E:\UEngine\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl_Variadics.inl の 640 行目にブレークポイントを設定します。
  • ブレークポイントまで実行します。

このシナリオでは下図のような結果が得られました。

グラフ 2: VS デバッガーを Unreal Engine のプロセスにアタッチした場合のメモリ使用量

このシナリオでは、VS 2015 はメモリ不足によりクラッシュしました。VS “15” Preview 5 の仮想メモリ使用量は 3GB、プライベート ワーキング セットのサイズは 1.8GB でした。明らかに改善されてはいますが、満足な結果とは言えません。マイクロソフトでは、ネイティブなデバッグ作業シナリオでのメモリ使用量の削減を、今後の VS “15” 開発でさらに進める予定です。

Visual Studio での Git のサポート

Visual Studio に Git のサポートが追加されたときには、libgit2 というライブラリが使用されていました。libgit2 では、さまざまな操作時に Git のインデックス ファイル全体をメモリにマッピングします。リポジトリのサイズはインデックス ファイルのサイズに比例します。このため、大きなリポジトリを使用する場合、Git の操作により仮想メモリで大きなスパイクが発生します。既に仮想メモリ容量が逼迫している場合、このスパイクにより VS がクラッシュする場合があります。

VS “15” Preview 5 では libgit2 を使用せずに git.exe を呼び出すようにして、仮想メモリのスパイクが VS のプロセス外で発生するようにしました。git.exe の使用により、VS のメモリ使用量が削減されただけでなく、機能性も向上し開発が容易になりました。

Git 操作でのメモリ使用量の変化を測定するために、下記のシナリオで Visual Studio 2015 Update 3 と VS “15” Preview 5 の結果を比較しました。

  • チーム エクスプローラーで Chromium リポジトリ (英語) を開きます。
  • [Changes] パネルに移動して保留中の変更を表示します。
  • F5 キーを押して画面を更新します。

このシナリオでは下図のような結果が得られました。

グラフ 3: チーム エクスプローラーの [Changes] パネルを更新した場合のメモリ使用量の変化

VS 2015 では、更新中に 300 MB 程度の仮想メモリのスパイクが発生しました。VS “15” では、仮想メモリの使用量増加は見られませんでした。プライベート ワーキング セットのサイズの増加は VS 2015 では 79 MB、VS “15” では 72 MB で、これはすべて git.exe によるものです。

まとめ

VS “15” では、Visual Studio のメモリ使用量の削減に尽力しています。この記事では、3 つの分野での進展についてお伝えしました。まだ改善すべき課題は残っており、今後もさらに努力していきます。

マイクロソフトでは以下のさまざまな方法で皆様のご協力をお願いしています。

  • マイクロソフトでは、プレリリース版を含めたすべてのリリースでテレメトリをモニタリングしています。ぜひ VS “15” Preview 5 をダウンロードしてご利用ください。日常的に使用される外部ソースのデータが増加することで、マイクロソフトが参考にさせていただくシグナルの質も向上します。
  • メモリの高負荷 (またはその他の品質) 問題が発生した場合は [Report a problem] ツール (英語) からご報告ください。こちらの環境で問題を再現できるような形でご報告いただけると大変助かります。問題を再現できるサンプルや実際のソリューションをお送りいただけますと幸いです。このような対応が難しい場合は、問題発生時の記録を添付し ([Report a problem] ツールより簡単に収集できます)、事象についてできるだけ詳細な内容をご報告ください。
Ashok Kamath (Visual Studio 担当主任ソフトウェア エンジニアリング マネージャー)

Ashok Kamath は Visual Studio のパフォーマンスおよび信頼性を担当するチームのリーダーで、以前は .NET 共通言語ランタイム チームに所属していました。

 

Visual Studio “15” で C++ ソリューションの読み込みとビルドを高速化

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Faster C++ solution load and build performance with Visual Studio “15” 2016/10/13

 

Visual Studio “15” では、C++ 開発者の皆様の生産性を大きく向上させることを目指しています。この目標に向けて、先日リリースされた Preview 5 ビルドには多数の改良点が実装されました。この記事ではその主な機能について説明します。

C++ ソリューションの読み込みを高速化

C++ プロジェクトに向けて、「迅速なプロジェクトの読み込み」という試験的な機能が導入されました。C++ プロジェクトを初めて開いたときの読み込み時間を短縮するもので、2 回目以降はさらに短くなります。この試験機能を使用する場合は、下図のように [Tools]、[Options] の順に選択してから [Enable Faster Project Load] を [True] に設定します。

次の簡単なデモでは、1968 個のプロジェクトを含む大規模な Chromium Visual Studio ソリューションを用いて、読み込み時間が短縮されることを証明しています。詳細については、C++ ソリューションの読み込みの高速化に関するブログ記事 (英語) を参照してください。

これとは別に、Visual Studio ではソリューションの読み込みを高速化する「ライトウェイト ソリューション ロード」機能の試験も行っています。この 2 つの機能にはまったく異なる手法が使用されています。詳細についてはこちらの記事を参照してください。
ライトウェイト ソリューション ロード機能は、すべてのプロジェクトをまとめて読み込むのではなく、ソリューション エクスプローラーでプロジェクトが明示的に拡張されたときに該当プロジェクトのみを読み込むというものです。C++ チームは迅速なプロジェクトの読み込み機能に集中的に取り組んでいるため、現時点ではライトウェイト ソリューション ロードのサポートは最小限にとどまっています。RC 版 Visual Studio 15 では、ライトウェイト ソリューション ロードと迅速なプロジェクトの読み込み機能の両方がサポートされる予定で、この 2 つを組み合わせて優れたエクスペリエンスが実現されます。

/debug:fastlink でビルド サイクルを短縮

開発者ビルドで /debug:fastlink エクスペリエンスとの統合によりリンクが高速化され、ビルド時間が短縮されました。リンカーの改良により、アプリケーションのビルド時間が 2 分の 1 から 4 分の 1 に短縮されます。

次の図では、C++ の主要なソースに対するリンク時間が /debug:fastlink によりどの程度短縮されたかを示しています。/debug:fastlink の詳細や Visual Studio との統合については、先日公開された C++ のビルド サイクル短縮に関するブログ記事 (英語) を参照してください。

メモリ不足によるデバッグ中のクラッシュが減少

VS “15” Preview 5 では、シンボル データの事前取得により向上したパフォーマンスを維持しつつ、シンボル情報が使用するメモリの量を削減しました。今回のバージョンでは、変数や式の評価および表示に関連するモジュールのみが事前取得されるようになりました。その結果、VS 2015 ではメモリ不足でクラッシュしていた Unreal Engine プロセスのデバッグを VS “15” Preview 5 で 行ったところ、仮想メモリの使用量は 3GB 以下、プライベート ワーキング セットのサイズは 1.8GB に抑えられ、クラッシュすることはなくなりました。明らかに改善されてはいますが、満足な結果とは言えません。マイクロソフトは今後の VS “15” 開発でも、ネイティブなデバッグ作業シナリオでのメモリ使用量の削減をさらに進める予定です。

まとめ

マイクロソフトでは、この機能をお試しになった皆様のエクスペリエンスを開発に活かすため、フィードバックをお待ちしています。C++ のコード ベースの活用におけるこの機能の感想をぜひお聞かせください。
問題点がありましたら、インストーラーまたは Visual Studio IDE 本体の [Report a Problem] オプションからご報告をお願いします。また、クエリやご意見を担当チームにメールで直接お送りいただけます。新機能のご提案は UserVoice (英語) までお寄せください。

Jim Springfield (Visual C++ チーム担当主任アーキテクト)

Jim Springfield は熱心な最先端の C++ 開発者で、コンパイラのフロントエンド、言語サービス エンジン、ライブラリなどの再設計に積極的に取り組んでいます。また、人気の C++ ライブラリの MFC および ATL の制作者で、直近では今後導入が予定されているエディターの Visual Studio Code の初期クロス プラットフォーム C++ 言語サービス エクスペリエンスを担当しています。

Ankit Asthana (Visual C++ チーム担当シニア プログラム マネージャー)

Ankit Asthana は主にクロス プラットフォームのモバイル開発とネイティブ コード生成ツールを担当しています。また、コンパイラ、分散コンピューティング、サーバー側の開発について豊富な知識を持っています。過去には IBM と Oracle Canada での開発経験を持ち、Java 7 (HotSpot) の最適化や通信機器を担当していました。2008 年には C++ に関する著書『C++ for Beginners to Masters』を出版し、数千部の売り上げを記録しています。

 

Visual Studio “15” の全体的な応答性を向上

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Improved overall Visual Studio “15” Responsiveness 2016/10/14

 

今回の記事は、Visual Studio “15” のパフォーマンス強化について 5 回にわたってお伝えするシリーズ記事の最終回です。

このシリーズでは下記の内容についてお伝えしてきました。

今回の記事では、Preview 5 に実装された機能強化のうち、Visual Studio を日常的に使用する際の応答性の向上を目的とするものをご紹介します。以下のセクションでは、デバッグのパフォーマンス向上、Git ソースの制御性の向上、XAML の編集エクスペリエンスの強化、拡張機能の管理による入力エクスペリエンスの強化について順番にご説明します。

デバッグ エクスペリエンスの高速化と編集中の応答性低下の防止

Visual Studio 2005 では、WPF、Windows フォーム、マネージ コンソール プロジェクトのホスティング プロセスが導入され、[Start Debugging] の応答を高速化するために、次回のデバッグ セッションで使用可能なプロセスをバックグラウンドで起動していました。しかし、この機能を導入した結果、[Stop Debugging] をクリックしたり、デバッグ セッションの終了後に Visual Studio を使用した場合に、Visual Studio が一時的に応答しなくなる問題が発生しました。

Preview 5 では、ホスティング プロセスを無効にして [Start Debugging] を最適化しました。これにより、ホスティング プロセスを使用しなくても従来の高速性が維持されるほか、以前からホスティング プロセスを使用していなかった ASP.NET、Universal Windows、C++ プロジェクトの場合はさらに高速になります。下記のグラフは、テスト マシンでサンプルの UWP 写真共有アプリ (英語)、素数の可視化を実行する C++ アプリ、簡単な WPF アプリの 3 つの起動時間を測定した結果です。

この機能強化を実現するために、[Start Debugging] を選択して [Diagnostic Tools] ウィンドウと IntelliTrace (既定でデバッグ セッションの開始時に毎回表示される) を初期化する場合のコストを最適化しました。IntelliTrace の初期化方法が変更され、デバッガーの他の処理やアプリケーションの起動と並列して初期化できるようになりました。また、ブレークポイントで停止した場合の IntelliTrace ロガーと Visual Studio プロセスの通信方法も効率化されました。

このほか、[Diagnostic Tools] ウィンドウに関連するバッググラウンド スレッドが Visual Studio のメイン UI スレッドのコードを同期的に実行する必要があった箇所も修正しました。これにより、ETW イベント コレクション内の非同期イベントの割合が増加し、デバッグ セッションを再開する場合に ETW セッションが終了するまで待機する必要がなくなりました。

Git.exe によるソース コードの操作の高速化

Visual Studio に Git のサポートが追加された時点では、libgit2 というライブラリが使用されていました。しかし、libgit2 とコマンド プロンプトから使用する git.exe は機能が異なるほか、libgit2 を使用すると Visual Studio のメイン プロセスに対して数百 MB のメモリ負荷が発生するという問題がありました。

Preview 5 では、この libgit2 の実装を廃止して、代わりに git.exe をプロセス外から呼び出すようにしました。そのため、Git がマシン上のメモリを消費することには変わりないものの、VS のメイン プロセスに対してメモリ負荷は発生することはなくなりました。また、git.exe を使用することで Git 操作が段階的に高速化することも期待されます。現時点では、大規模なリポジトリに対して git clone コマンドを実行した場合に処理が高速化したことを確認しています。テスト用マシンで Roslyn .NET Compiler リポジトリのクローンを作成したところ、Visual Studio 2015 では 5 分 40 秒かかったのに対し、Visual Studio “15” では所要時間が 4 分と、30% の短縮になりました。以下の動画はそのようすを示したものです (4 倍速で再生しています)。

今後のリリースでは、この新しいアーキテクチャによって他の操作も高速化される予定です。

また、Git の使用について特に多くのご不満が寄せられていたのが、コマンド ラインからブランチを切り替えた場合に Visual Studio がソリューション内のすべてのプロジェクトを 1 つずつ読み込み直すという問題です。この問題も修正され、ファイル変更の通知ダイアログの [Reload All] が [Reload Solution] に変更されました。

これにより、ソリューションの再読み込みが非同期で 1 回のみ実行され、個々のプロジェクトを再読み込みする場合よりもはるかに短時間で処理が終了します。

XAML のタブ切り替えの高速化

データやお客様からのフィードバックによると、開発者の 25% が 1 日に 1 回以上は XAML のタブを切り替えるときに 1 秒以上の遅延を経験しています。さらなる調査の結果、この遅延はマークアップ コンパイラが原因であることが判明しました。そこで、XAML 言語サービスを利用することで、タブの切り替えを大幅に高速化しました。以下の動画で、この機能強化の成果をご確認ください。

マークアップ コンパイラは各 XAML ファイルの g.i.* ファイルを作成します。このファイルには XAML ファイル内の名前を持つ要素を表すフィールドが含まれていて、名前を持つ要素をコードビハインドから参照する場合に使用できます。たとえば、<Button x:Name=”myButton” /> という要素が存在する場合、g.i.* ファイルには Button 型の名前を持つボタンのフィールドが含まれ、コード内で “myButton” を使用することができます。

XAML ファイルを保存したり、保存されていない XAML ファイルから他のファイルに切り替えたりすると、分離コード ファイルを開いた場合に IntelliSense が最新の名前を持つ要素を表示できるように、Visual Studio がこの g.i.* ファイルを更新します。従来のリリースでは、この g.i.* ファイルの更新は毎回マークアップ コンパイラが実行していました。マネージ プロジェクト (C#/VB) では、マークアップ コンパイラが UI スレッドで実行されていたため、複雑なプロジェクトでタブを切り替えると目に見える遅延が発生していました。

Preview 5 ではこの問題が修正され、XAML 言語サービスが保持している XAML ファイルの情報を利用して IntelliSense に表示するフィールドの名前と型を判別してから、バックグラウンド スレッドで Roslyn を使用して g.i.* ファイルを更新するようになりました。言語サービスでは、コンパイラの速度低下の原因となる解析や型メタデータの読み込みをすべて完了しているため、マークアップ コンパイラを実行する場合よりもはるかに高速です。ただし、g.i.* ファイルが存在しない場合 (XAML ファイルの名前を変更した場合やプロジェクトの obj ディレクトリを削除した場合) は、マークアップ コンパイラを実行して g.i.* ファイルを最初から生成し直す必要があるため、これまでと同様に遅延が発生します。

XAML の入力エクスペリエンスの応答性向上

XAML 言語サービスで UI の遅延が発生する主な原因は、初期化、メタデータの変更への対応、デザイン アセンブリの読み込みです。今回のバージョンでは、処理をバックグラウンド スレッドに移動することで、これら 3 つの原因をすべて解消しました。

デザイン アセンブリ メタデータの読み込みについては、下記の機能強化も実施されました。

  • デザイン アセンブリ メタデータのシリアル化層が新たに追加され、境界を越える呼び出しが大幅に減少しました。
  • WPF プロジェクトでデザイナーのアセンブリ シャドウ キャッシュが再利用されるようになりました。また、すべての種類のプロジェクトでシャドウ キャッシュがセッション間で再利用されるようになりました。従来、これらのシャドウ キャッシュはメタデータが変更されるたびに作成し直されていました。
  • メタデータが変更されるたびに再計算されていたデザイン アセンブリ メタデータが、セッション期間中はキャッシュされるようになりました。

これらの変更により、ソリューションの読み込みが完全に完了する前に XAML の IntelliSense を使用できるようになりました。

入力時の応答性低下の原因となっている拡張機能の特定

入力時の応答性低下については、多数のご報告をいただいています。現在これらの不具合の修正を進めていますが、この応答性低下の原因の大半はキーボードの操作中にコードを実行する拡張機能です。このような原因を確認できるように、[Help]、[Manage Visual Studio Performance] からレポートにアクセスできるようになったほか、入力エクスペリエンスに影響を与えている拡張機能を通知する機能が追加されました。

入力の応答性低下の原因となっている拡張機能の通知

[Help]、[Manage Visual Studio Performance] の順に選択すると拡張機能の詳細が表示されます。

試用と問題のご報告のお願い

今回の記事では Preview 5 に実装された機能強化の一部をご紹介しました。マイクロソフトは、今後も Visual Studio の応答性の向上に向けた取り組みを継続してまいります。皆様が最も必要とする機能に重点的に取り組むことができるように、ぜひ Visual Studio “15” Preview 5 をダウンロードしてご試用いただき、[Report-a-Problem] ツール (英語) から機能強化に関するご提案をお寄せください。

Dan Taylor (シニア プログラム マネージャー)

Dan Taylor は、5 年前にマイクロソフトに入社して以来、.NET と Visual Studio のパフォーマンス強化に取り組んでいるほか、Visual Studio と Azure のプロファイリングおよび診断ツールを担当しています。

 

TACO に関する質問にお答えします!

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Answers to your top TACO questions 2016/10/20

 

先月開催された Microsoft Ignite カンファレンスで、光栄にもパネル ディスカッションに参加させていただきました。モバイル アプリ開発に関するディスカッション (英語) で、Xamarin のスペシャリストの James Montemagno、Visual Studio C++ チームの Ankit Asthana、UWP チームの Daniel Jacobson と共に Visual Studio Tools for Apache Cordova (略称 “TACO”) についてお話ししました。セッションでは、オーディエンスの方々から非常に興味深い質問を多数いただきました。よくいただく質問もありましたので、Visual Studio ブログ読者の皆様のご参考になるように、この記事では TACO に関して寄せられた特に一般的な質問への回答を載せたいと思います (TACO は「タコス」ではないので、ソフトシェルがいいかハードシェルがいいかというご質問にはお答えしかねます!)。

この記事で取り上げていない内容についてご不明な点がありましたら、ページ下部のコメント欄までお寄せいただければ幸いです。重要なご質問には追加記事でお答えさせていただきます。

TACO とは何ですか?

TACO は Tools for Apache Cordova の略称で、Web テクノロジ (HTML、JavaScript、CSS) を使用したモバイル アプリケーション開発をより簡単に、よりわかりやすく、より迅速に進めるための一連のユーティリティで構成されており、Android、iOS、Windows の各デバイス向けのアプリ開発に使用できます。TACO はマイクロソフトが開発した製品スイートであり、以下のものがあります。

.NET と Web 開発の両方のスキルがある開発者は、モバイル開発に Xamarin と Cordova のどちらを選ぶべきですか?

私もそうですが、Visual Studio ブログ読者の多くは .NET と Web ベースのテクノロジの両方の開発経験を持っています。そのため、.NET のスキルをモバイルに活かせる Xamarin と、Web ベースのスキルを活かせる Apache Cordova のどちらもモバイル開発にとっては魅力的に映るでしょう。だからこそこの質問は、何年経っても一番多く寄せられる質問なのです。また、マイクロソフトが Xamarin を買収し、Xamarin を Visual Studio で無料で使用できるようになったため、今後はさらに増えると思われます。

この質問に対しては、「場合による」としかお答えできません。アプリや開発チームの事情はそれぞれ違うので、開発者やチームのスキルを考慮してどちらのテクノロジがより適切であるかを判断する必要があります。なお、どちらを使っても既存のコードのほぼ 100% を iOS、Android、Windows の各アプリケーションで再利用できます。

Cordova が適しているケース

  • JavaScript、HTML、CSS、およびこれらのテクノロジをベースに構築されたライブラリを用いて開発する場合
  • 既に Web サイトや Web コンテンツを所有していて、それらをモバイル アプリで再利用したい場合
  • カメラなどの特に一般的なデバイス機能の利用を計画している場合
  • 不具合の修正や差分更新をアプリに発行する際にストアへの再登録を不要にする CodePush (英語) などのサービスを活用したい場合

Cordova ではあらゆる種類のモバイル アプリを作成できますが、ゲームなどのグラフィックやデータ処理の負荷が高いアプリケーション、また、高機能でネイティブ アプリ並みのユーザー エクスペリエンスとアニメーションを備えるアプリの構築には向いていません (ネイティブ並みのアプリを構築できるフレームワークを使用するという方法はあります)。お客様からお話を伺ったところ、Cordova の用途で共通していたのは、「基幹業務」機能のモバイル化や、データ入力やデータ フォームをベースとする Web アプリのモバイル化でした。たとえば、経費や勤務時間の追跡、販売店の在庫管理、投資ポートフォリオ追跡などです。

Xamarin と Cordova のどちらでもデバイス ネイティブ機能を利用することはできますが、そのしくみには大きな違いがあります。Xamarin にはデバイスのネイティブ API のサポートがすべて組み込まれていますが、Cordova では各種のオープン ソース プラグインを追加する必要があります (プラグインの詳細については後述のセクションを参照)。プラグインは品質が一定しておらず、また Xamarin ほど頻繁には更新されません。Adobe やマイクロソフトなどの企業では、特にビジネスやエンタープライズ企業で頻繁に使用されるプラグインが正常に動作するよう保守を怠らないようにしていますが、それ以外のプラグインについては規模の大きいコミュニティに委ねられています。

Xamarin が適しているケース

  • ネイティブ API 機能に完全にアクセスしたい場合
  • 最新のユーザー インターフェイス ガイドラインに沿ったアプリケーションを作成する必要がある場合
  • C#、.NET、XAML (Xamarin.Forms の場合)、およびこれらのテクノロジをベースに構築されたフレームワークで開発する場合
  • 既に .NET ライブラリ (JSON.NET など) やその他の .NET アセットを所有していて、これらをモバイル アプリで再利用する場合
  • デバイスのパフォーマンスを最大限に発揮したい場合

Xamarin では NuGet などの既存の .NET エコシステムのテクノロジを使用でき、ネイティブ アプリと同等のパフォーマンスで動作する完全にネイティブなアプリケーションを構築できます。各プラットフォームの API を利用できるため、それぞれのプラットフォームで提供されている最新の優れた機能を活用することができます。ネイティブなプラットフォームを使用してアプリを構築する場合は Xamarin を使用することをお勧めします。

どちらを選択してもやるべきこと

どちらのツールを使用するにしても、まずはツールを試すためにプロトタイプをいくつか作成し、開発スタイルやアプリケーションのニーズに本当に適合しているかをご確認ください。

既に Web アプリはあります。モバイル化に Cordova を利用したいのですがどうすればよいですか?

既存の Web アプリケーションをモバイル化する最も簡単な方法は、いわゆるホステッド Web アプリケーションを作成することです。つまり、Cordova アプリケーションを作成し、そのすべてのコンテンツをデバイスのローカル ドライブに保存するのではなく Web サーバー上でホストするのです。これは、Web 開発者にはお馴染みの Web サーバーでホストされる従来のモデルを踏襲したものです。そのため既存の Web アセットを活用できるうえ、作成したアプリをアプリ ストアに公開することができます。ホストされた Web アプリを Apache Cordova で作成する方法については、TACO のドキュメント サイトのチュートリアル (英語) をご覧ください。このホステッド Web アプリ モデルでは、これまでのようにアプリケーション内で Web サイトをホストできるだけでなく、Cordova プラグイン モデルを使用してホステッド Web アプリケーションからデバイス ネイティブ機能にアクセスすることも可能です。

このモデルでは多少のダウンサイズが可能ですが、ネットワーク接続がない状況でオフラインでの動作が可能なアプリケーションを作成する必要がある場合には追加作業が発生します (ネットワーク接続を使用できないときは Web サーバーからアプリのコンテンツを取得できないため)。

ほかにも、モバイル デバイス専用の別のバージョンを作成することもあるでしょう。その場合には共通のコードを共有できます。詳細については以降のセクションを参照してください。

Cordova と新しい Progressive Web Apps モデルにはどのような違いがありますか?

Progressive Web Apps (PWA) では、エンド ユーザーがホーム画面に追加可能な形のモバイル バージョンの Web サイトを構築できます。この PWA のアプリは Web サーバーで実行されますが、オフライン キャッシュの処理、プッシュ通知の送信、バックグラウンドでのコンテンツ更新などの機能を追加できます。Geolocation などの現在使用可能な Web 標準 API を使用すると、ネイティブ アプリのように機能する Web エクスペリエンスを簡単に作成できるため、アプリ ストアでアプリを探す必要がなくなります。詳細については、Ionic チームが執筆したこちらの記事 (英語) をご覧ください。

Apache Cordova と現在の形式の PWA との大きな違いは、主に下記の 3 つです。

  1. PWA ではデバイスのネイティブ機能に完全にアクセスすることができません。標準 Web API でサポートされている機能にのみアクセスできます。Cordova では、特定の機能を提供するプラグインさえ作成されていれば、すべてのデバイス機能を使用することも不可能ではありません。
  2. PWA はアプリ ストアで公開されません。作成したアプリをアプリ ストアで公開する場合は、Cordova で作成する必要があります。現在 Microsoft Edge チームでは PWA アプリを Windows ストアで公開する方法 (英語) を検討していますので、今後にご注目ください。
  3. PWA をサポートしているモバイル プラットフォームは現時点では限られています。iOS や Windows のデバイスでは現在 PWA モデルをサポートしておらず、最新バージョンの Android と Chrome のみがサポートしています。この記事の執筆時点では、PWA は Chrome ブラウザーで使用可能です。Firefox と Opera の各 Web ブラウザーでも試験版の機能として使用できます。Microsoft Edge に関しては今後 PWA のサポートを追加することが発表されています (英語)。あらゆる大手デバイス メーカーや主要なフォーム ファクターに対応し、エンド ユーザーに幅広く提供するためには、現時点では Cordova を使用することをお勧めします。

Apache Cordova ではプッシュ通知などのネイティブ機能を使用できますか?


はい。Apache Cordova でプラグインを使用すれば、さまざまなデバイス ネイティブ機能を使用できます。たとえば、カメラ、バッテリ状態、プッシュ通知などのデバイスの機能に対応したプラグインがあります。Cordova プラグイン リポジトリ (英語) を検索すると、特に一般的なデバイス機能に対応した各種プラグインが見つかります。プッシュ通知を連携させる場合は、Azure App Services を使用して Cordova アプリでプッシュ通知を追加する方法をお読みください。

プラグインを作成すると次のようなことが可能になります。

  • サポートされているすべてのプラットフォームで単一の JavaScript API を使用する
  • サポートされているプラットフォームのそれぞれのネイティブなコードを実装する (iOS の場合は Swift、Android の場合は Java、Windows の場合は C#)

チームでは、企業のビジネスにとって最も重要なプラグインが確実に動作するよう支援を行っています。精力的に活動している Cordova 開発者コミュニティでも、その他の機能の開発が進められています。マイクロソフトでは、Android、iOS、Windows のプラットフォームでサポートされているテクノロジについては、それに対応する重要なコア プラグインがそれらのデバイスで正常に動作することを確認しています。

どうすれば 5 ~ 10 年使い続けられるモバイル アプリを作成できますか?

私が過去に携わったプロジェクトでは、開発チームによる保守作業が 5 年以上ほとんど必要ないソリューションを構築したことがありました。同じような経験をされた開発者様も多く、このように長く使用できるモバイル アプリの作成方法についてご質問をいただいています。これほど長期の使用に耐えるモバイル Web アプリを開発したことがある方なら、Cordova で同様のモバイル アプリを作成することも必ずできます。

ただし、複雑なアプリを作成する場合には事情が変わってきます。たとえば、画面が複数あって、デバイス ネイティブ機能にアクセスしたり、プッシュ通知などの機能に対応したサードパーティ サービスも使用するようなアプリです。このようなアプリは、今市場に出回っているデバイスだけを考慮して設計すればよいわけではなく、5 ~ 10 年の間に主流となるデバイスに変化があることを考慮しておかなければなりません。未来のデバイスで UI がどのように動作し、どのようなデバイス機能がサポートされているかを検討し、今後も使用し続けられるサービスを選択する必要があります。しかし、私も例外なく、多くの方にとって将来の要件を正しく予想する困難と言えます。

Microsoft Ignite カンファレンスでのモバイル関連のパネル ディスカッションでは、Cordova、Xamarin、Objective-C、Swift、Java、その他どのサービスを使用しても、モバイル アプリの将来について予測することは不可能であるという意見で概ね一致しました。それよりは、将来の要件やモバイル デバイスの変化に対応するためにスケーリング可能なサービス層を構築することが有効であると考えます。たとえば、ビジネス ロジックをアプリケーションに直接コードとして組み込むのではなく、RESTful API などを使用してアプリケーションから呼び出されるサービス層をバックエンドに作成して、そこからロジックを処理するようにします。こうすると、時間が経ってアプリケーションのニーズが変化したときに、または新しいモバイル アプリを作成した場合に、コードを変更することなく既存のサービス層をそのままアプリから使用することができます。

アプリのサービス層をサポートする以外に、次のマイクロソフトのサービスがお客様の業務に活用できないか検討してみてください。

他にご質問はありますか? いつでもお待ちしています!

この記事では、開発者の皆様から寄せられた一般的な質問の一部を取り上げましたが、他にもさまざまな疑問をお持ちかと思います。どうぞお気軽に下部のコメント欄までご質問ください。また、メールでも受け付けています。Cordova に関する問題やベスト プラクティスについては、Stack Overflow の “visual-studio-cordova” タグ (英語) もご参照ください。TACO の詳細についてはこちらのドキュメント サイト (英語) もご覧ください。

Jordan Matthiesen (@JMatthiesen)

Tools for Apache Cordova 担当プログラム マネージャー

Jordan Matthiesen は、マイクロソフトで Web アプリケーションおよびモバイル アプリケーション開発者向けの JavaScript ツールを担当しています。それ以前にも 18 年以上の開発経験があり、現在は優秀なモバイル開発者からできるだけ多くの意見を取り入れることに力を入れています。プライベートでは、妻と 4 人の子ども、2 匹の猫、1 匹の犬と共にコーヒーを飲みながらゆっくり過ごす時間を大切にしています。

 

新しい Visual Studio for Mac を発表

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Announcing the new Visual Studio for Mac 2016/11/16

 

本日、Connect(); 2016 (英語) で午前中に行われた基調講演では、Nat Friedman と James Montemagno が Visual Studio ファミリの最新製品である Visual Studio for Mac (英語) をご紹介しました。Visual Studio for Mac は、Xamarin と .NET によるモバイルおよびクラウド アプリ開発に最適化された開発環境で、Android、iOS、.NET Core テクノロジなど、Mac での .NET 開発を一手に引き受けます。ネイティブ ユーザー インターフェイスを備えた Visual Studio for Mac には、Android および iOS 向けの最新の API や UI デザイナーなど、モバイル アプリやサーバー アプリケーションを妥協することなく作成、デバッグ、テスト、発行するために必要なすべてのツールが統合されています。

C# と F# の両方が標準でサポートされているほか、プロジェクト テンプレートは、モバイル フロントエンドとバックエンドでコードを共有するためのベスト プラクティスを示したスケルトンとして利用できます。新しい Connected Application テンプレートを使用すると、Android および iOS のフロントエンドと補完的な .NET Core ベースのバックエンドを作成できます。

Visual Studio for Mac を起動すると、Visual Studio IDE で馴染みのある Roslyn コンパイラ、IntelliSense のコード補完、リファクタリング機能を利用できます。また、Visual Studio for Mac では Visual Studio と同じ MSBuild のソリューションおよびプロジェクト形式が使用されるため、Mac と Windows 間でプロジェクトを透過的に共有できます。

さらに、Visual Studio for Mac では、マルチプロセスのデバッグ機能を使用して、フロントエンド アプリケーションとバックエンドを同時にデバッグすることができます。

モバイル ファースト

Visual Studio for Mac では、統合されたデザイナー、コード編集機能、パッケージ化ツールや発行ツールなどモバイル アプリを作成するための優れたエクスペリエンスが提供され、以下の機能によって補完されます。

  • 非常に人気の高い C# 7 プログラミング言語のフル機能
  • Android、iOS、tvOS、watchOS、macOS 向けの完全な .NET API
  • Xamarin.Forms API の抽象化によりコードを最大限に共有
  • NuGet.org の多数の .NET ライブラリにアクセスしてモバイル開発をスピードアップ
  • LLVM 最適化コンパイラにより高度に最適化されたネイティブ コード

しかし、アプリはクライアントだけでは完結しません。そのため、Visual Studio for Mac ではバックエンド開発向けの機能も提供されます。

この製品に含まれる機能一覧については、リリース ノート (英語) をご確認ください。

クラウド ファースト

現在では、モバイル アプリケーションが単独で機能することはめったにありません。大半のモバイル アプリは、複雑な処理を実行し、ユーザーをつなぐためにバックエンドを利用しています。

.NET Core を使用して独自のバックエンド サービスを構築し、Visual Studio for Mac でこれらのサービスを Windows または Linux サーバーにデプロイすることができます。プロジェクト テンプレートを使用すると、エンドツーエンドの構成で稼働させることができます。

さらに、たとえば Azure App Services のプッシュ通知、データ ストレージ、ユーザー アカウント、ユーザー認証など、Azure モバイル サービスをアプリケーションに簡単に統合することもできます。この機能は新しい “Connected Services” プロジェクト ノードで利用できます。

Visual Studio for Mac は、ASP.NET Core を使用してカスタム バックエンドを展開する場合にも、パッケージ化された Azure サービスを使用する場合にも対応します。

この製品に含まれる機能一覧については、リリース ノート (英語) をご確認ください。

今後の展望

本日、Visual Studio ファミリの最新製品である Visual Studio for Mac の初回プレビューをリリースしました。これはまだ始まりにすぎません。今後数か月にわたり、Visual Studio および Visual Studio Code チームと協力して、高度な Web 編集機能から、Language Server Protocol 経由でのプログラミング言語のサポートの拡大まで、皆様にご愛用いただいている多数の機能を Mac に追加してまいります。

Visual Studio for Mac (英語) ページにアクセスして、ぜひプレビュー版をお試しください。皆様からのフィードバックをお待ちしております。

Visual Studio 2017 Release Candidate を発表

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Visual Studio 2017 Release Candidate 2016/11/16

 

本日 Connect(); 2016 (英語) で、次期 Visual Studio リリース候補版となる Visual Studio 2017 Release Candidate (英語) が発表されました。Visual Studio の開発は、常に皆様にいただく声を重視しながら進めています。プレビルド版やプレビュー版を実際にご使用いただき、フィードバックをくださった皆様に改めて感謝を申し上げます。

 

今回のリリースでは、生産性機能やパフォーマンス強化が多数実施され、モバイル開発エクスペリエンスやクラウド開発エクスペリエンスも改良されています。ここではその一部をご紹介します。さらに詳しい情報については、Visual Studio 2017 のリリース ノートと既知の問題Visual Studio 2017 RC に関するよく寄せられる質問 (英語)visualstudio.com の Visual Studio 2017 RC ページ (英語) をご覧ください。

 

今回は、Visual Studio 2017 RC の他にも Visual Studio for Mac と Visual Studio Mobile Center が発表されました。Visual Studio 2017 RC の説明に入る前に、この 2 つの製品についてもお伝えします。Visual Studio for Mac は Mac 向けにゼロから開発したもので、Xamarin for Visual Studio、ASP.NET Core、Azure を使用したクライアントからクラウドへのネイティブなモバイル開発を対象としたフルスタック製品となっています。この詳細については、Visual Studio for Mac の概要を説明した Miguel de Icaza のブログ記事 (英語) をお読みください。Visual Studio Mobile Center は「モバイル アプリの管制塔」の役割を担うもので、モバイル開発者に広く使用されている複数のサービスが 1 つにまとめられており、クラウド用アプリの構築、テスト、デプロイ、監視を 1 か所から行うことができます。この詳細については、Visual Studio Mobile Center の詳細に関する Nat Friedman のブログ記事 (英語) をお読みください。

生産性が大幅にアップ

Visual Studio 2017 には、日常的な生産性を向上させるための新機能や機能強化が多数実装されています。

IntelliSense: IntelliSense にフィルタリング機能が追加され、使い勝手が大幅に向上しました。このフィルタリング機能を使用すると、リストが長い場合にずっと操作しやすくなります。たとえば、CamelCase 検索などの機能で大文字の 2 文字を入力するだけで IntelliSense が結果を適切にフィルタリングし、入力した文字が大文字になっている 2 語の語句を表示します。また、IntelliSense が高度化され、ただ上位の結果を提示するだけではなく、最も可能性が高い結果が提示されるようになりました。

ナビゲーション: フィルタリング機能とプレビュー機能が改良され、[Navigate To] が大幅に強化されました。また、[Find All References] ウィンドウで新たに色付けやグループ化、拡大プレビューに対応しました。

ライブ編集: ライブ コード分析機能は非常に便利な機能で、その名のとおりエディターでコードやフラグに関する問題を分析します。ライブ ユニット テストでは、パスの不正に関する情報をエディターに直接表示します。この機能では、テストでエラーが発生した場合にユーザーに知らせるだけではなく、ユニット テストの簡単な基礎をワンクリックで作成できます。Visual Studio はこれに従ってテストを作成してユーザーに提示し、即座にバックグラウンドで実行を開始します。これらのテストの合否はコード上に直接表示されます。

プロジェクトに関連付けられていないファイルを開く: Visual Studio 2017 RC では、プロジェクトやソリューションに関連付けられていないコード ベースやファイルを直接開いて作業を行えます。ファイルを開くには、メニューから [File]、[Open]、[Folder] の順に選択して該当するフォルダーに移動し、ファイルを選択します。

デバッグ: クイック実行を使用すると、一時的なブレークポイントを設定する必要がありません。デバッグを開始すると左側に緑色のグリフが表示され、これをクリックするとその場所までコードが実行されます。また、右側にはパフォーマンスに関するヒントを示すグリフが表示されます。これによりパフォーマンスに関する問題を即座に特定できます。正常なパフォーマンスが発揮されていない場合は、このグリフをクリックすると診断ツールのウィンドウが開き、パフォーマンスに関する問題をすぐに発見して解決することができます。

この他にも、サポート対象の言語全体で多数の機能強化が実装されています。この詳細については、VS 2017 の生産性機能の強化に関する MSDN マガジンの記事 (英語)Visual Studio 2017 RC のリリース ノートを参照してください。

モバイル開発機能を強化

Visual Studio では、Android、iOS、Windows の各デバイス向けのモバイル アプリを開発する際に、既に皆様がお持ちの C#、JavaScript、C++ のスキルを活用できます。C++ や JavaScript を使用している開発者は、Cordova や Ionic を使用して共有可能なコードを開発できます。C# アプリでネイティブ アプリを開発する場合は、Xamarin を使用すると最大 80% のコードを共有できます。

テストはモバイル開発の中でも最も手間のかかる作業で、すべてのユーザーに対応するのは不可能であるとしても、大半のユーザーに対応するために、幅広い範囲の実在するデバイスでテストを作成し実行する必要があります。Visual Studio 2017 のモバイル テスト レコーダーでは、テストで実行した操作を簡単に記録できます。ワンクリックで Xamarin Test Cloud にテストをアップロードし、実在する数千種類のデバイスのテストをクラウド上で実行することができます。

クラウドでの開発を合理化

クラウドを利用すると、アプリをテストする方法だけでなく、アプリの作成方法も変化します。Visual Studio 2017 RC では、アプリケーションのデプロイ方法や更新方法のアーキテクチャ パターンからマイクロソフトの開発プロセスに至るまでのさまざまなプラクティスを皆様の開発作業に簡単に応用できます。

今回のリリースには、アプリケーションを Docker コンテナーにパッケージ化しクラウドにデプロイする統合ツールが含まれています。Visual Studio 2017 RC では DevOps ワークフローが改良されていて、Git を基盤としてバージョン管理を行い、継続的インテグレーションや継続的デプロイメントのパイプラインの作成を大幅に簡素化できます。こうした改良の中で特にご注目いただきたい 1 つが .NET Core で、Linux をワンクリックで .NET Core アプリケーションのターゲットに指定し、Docker コンテナーにパッケージ化し、Docker レジストリで公開して、クラウドで実行することができます。デプロイが完了すると、.NET Core は高速でアプリを実行します。

基礎を見直し

VS 2017 ではあらゆる面のパフォーマンスが強化されています起動の高速化読み込み時間の短縮C++ ソリューションの読み込みの高速化メモリ使用量の削減など、大幅に進化しています。Visual Studio のコールド スタート時の起動速度は 3 倍、ソリューションの読み込み速度は 2 ~ 4 倍に高速化されています。詳細については上記リンク先の連載記事で説明されているため、この記事では詳しくは説明しません。下の方にあるビデオの終盤では、Visual Studio 2017 と Visual Studio 2015 でのソリューションの読み込みを比較していますのでぜひご覧ください。

また、プレビュー版をインストールした方はお気づきかと思いますが、Visual Studio 2017 ではインストール時間が短縮されています。新しいインストーラーはコンポーネント化された軽量なもので、Visual Studio が独立したワークロードに分割されていて必要なものだけをインストールできるため、所要時間が大幅に短縮されます。

この記事で紹介したものをはじめ、強化された機能を実際に使用している様子をお見せするビデオを作成しました。そのうちの 1 本をここでご紹介します。

Visual Studio 2017 の拡張性

先日、拡張機能を作成される方に向けて、Tim Sneath が Visual Studio 2017 の拡張性に関するブログ記事 (英語) を公開しました。この記事では、Visual Studio の拡張機能に関するすべての変更、および開発者が作成した拡張機能を Visual Studio の次期メジャー バージョンで動作させるために必要なことについて説明しています。

詳しくは該当記事をお読みいただくことにして、この記事では概要を簡単にお伝えしたいと思います。

拡張機能のパフォーマンス監視システム: 拡張機能のユーザー向けに、拡張機能の読み込み速度や入力速度が低下した場合に金色の通知バーが表示されるようになりました。[Help]、[Manage Visual Studio Performance] の順に選択すると、実行中のすべての拡張機能のパフォーマンスをいつでも表示できます。

拡張機能の更新やインストールをバッチ実行: 複数の拡張機能を同時にインストール、更新、削除する操作が大幅に容易になりました。

拡張機能が依存するコンポーネントを自動的に検出しインストール: Visual Studio 2017 RC では既定のインストール ファイルのサイズが大幅に削減されたため、VS にインストールされていないコンポーネントについては、拡張機能が依存しているものが自動的に検出され、インストールされるようになりました。

拡張機能の開発者向けのパフォーマンスを強化: Visual Studio 2017 では、拡張機能の開発者に向けて、ソリューション読み込みの軽量化や拡張機能での NGEN のサポートなどのパフォーマンス強化が実施されています。

VS 製品ファミリの拡張機能はすべて Visual Studio Marketplace と呼ばれる場所で公開されています。Visual Studio Marketplace およびここで公開されている新機能の詳細については、Marketplace のブログ (英語) をご覧ください。

製品化に向けたパートナー様のご協力

Visual Studio の高い生産性と強力な機能は、パートナー様のコミュニティで作成された多数の拡張機能によって実現されています。現時点では、Visual Studio 2017 の他に Visual Studio 2017 RC 互換のプレビュー版拡張機能をインストールできます。現在 VS 2017 RC で使用可能な拡張機能は、すべてこちらのページ (英語) に記載されています。

ぜひお試しください

Visual Studio 2017 RC (英語) には皆様にお試しいただきたい新機能や機能強化が多数実装されています。この記事で紹介したものは、そのうちのほんの一部です。今回のリリースのすべての機能と既知の問題は、Visual Studio 2017 RC のリリース ノートに記載されています。

Visual Studio 2017 は、最新バージョンの Visual Studio の正式名称です。旧バージョンの Visual Studio 2015 に替わるものであり、これまで Visual Studio “15” と呼ばれていました。今回はこの名称と共に、Visual Studio “15” Preview または Visual Studio 2015 がインストールされているマシンに Visual Studio 2017 RC をインストールする方法も公開されました。Visual Studio 2015 などの旧バージョンの VS と Visual Studio 2017 RC は共存インストールが可能ですが、Visual Studio “15” Preview と Visual Studio 2017 RC の共存インストールはできません。このため、Visual Studio 2017 RC のインストーラーを実行するとクリーニング ツールが自動的に Visual Studio “15” Preview の生成物を検出し、削除します。また、Visual Studio 2017 RC はほぼ全体がサポート対象となりますが、一部のワークロードやコンポーネントはプレビュー期間中でサポート対象外となります。これらの機能は、インストーラーの UI で [Preview] というマークが表示されます。Visual Studio 2017 と以前のリリースとの互換性の詳細についてはこちらのページを参照してください。また、オフラインでのインストールの詳細についてはこちらのページ (英語) を参照してください。その他の一般的な問題については、Visual Studio 2017 RC についてよく寄せられる質問 (英語) を参照してください。

マイクロソフトでは皆様のフィードバックをお待ちしています。問題点がありましたら、インストーラーまたは Visual Studio IDE 本体の [Report a Problem (英語)] オプションからご報告をお願いいたします。また、開発者コミュニティ ポータル (英語) に寄せられたフィードバックもご覧ください。ご提案は UserVoice (英語) までお寄せください。

最後になりますが、Connect(); 2016 ページ (英語) では基調講演やその他のビデオを公開していますので、ぜひこちらもご覧ください。

Connect(); 2016 の最新情報(VSTS & TFS)

$
0
0

 

本記事は、マイクロソフト本社の Brian Harry’s blog の記事を抄訳したものです。
【元記事】 News from Connect(); 2016 2016/11/16

 

本日、ニューヨークで開催中のイベント Connect(); において魅力的な新機能やサービスが続々と発表されています。Connect(); で発表される最新情報は多岐にわたるため、この記事では TFS と Team Services に関連する情報に絞ってご紹介したいと思います。

TFS 2017 RTM をリリース

特に大きなニュースの 1 つが、TFS 2017 RTM 版のリリースです。オンプレミスの TFS をご利用のお客様に向けて Team Services の多数の機能強化が提供されます。TFS 2017 の新機能は次のとおりです。

  • パッケージ管理 – 非公開の NuGet フィードの作成と管理
  • コード検索 – プロジェクト コレクション全体のすべてのコードの容易な検索
  • アジャイル計画機能の強化 新しいフォーム、作業項目のフォロー、ライブ更新、通知の機能強化など
  • Git 関連の機能強化 プル リクエストの大幅なアップグレード、反復型のレビュー、squash マージなど
  • ビルド機能の強化 – Java ビルド テンプレート、Xamarin のビルド タスク、Docker のサポートなど
  • リリース管理機能の強化 – ARM テンプレートのサポート、タスク グループ、手動での承認タスク、リリースのスケジュール設定など
  • テスト機能の強化 – 10 分の 1 以下になったテスト結果ストレージ、手動テスト関連の多数の機能強化、テストのレポートと追跡に関する機能強化など
  • Marketplace – TFS での有料拡張機能のサポート、インストール エクスペリエンスの強化など
  • その他多数

以下のリンクをご利用ください。

パッケージ管理の一般提供開始

NuGet をサポートするパッケージ管理サービスがリリースされた以外に、Team Services のパッケージ管理も更新されました。NPM のサポートが追加されたため、NuGet パッケージと NPM パッケージの両方を管理できます。その他のプロトコルにも順次対応する予定です。また、パッケージ管理サービスにビジネス モデル利用条件が導入され、ユーザーは 5 名まで無料、それ以上は料金が発生するようになります。詳細については、Marketplace のパッケージ管理のページ (英語) をご覧ください。

リリース管理の一般提供開始

リリース管理サービスが TFS 2017 に追加された以外に、Team Services でも一般提供が開始され、料金モデルが適用されます。新しいモデルではビルドとリリースが単一のアプローチとして統合されているため、管理が簡単になります。基本的なコンセプトとしては、複数のパイプラインを同時実行する場合にライセンスを購入することになります。利用できるパイプラインには、お客様自身がホストするプライベート パイプラインと、マイクロソフトがお客様の代わりにホストするホスト パイプラインがあります。各アカウントでは、ビルド/リリース用のプライベート パイプラインが 1 つ無料で提供されます。エージェントで複数のビルド/リリース パイプラインを同時実行したい場合は、プライベート パイプライン (英語) を追加購入できます。今後、エージェントを購入する必要はなくなり、必要な数だけプライベート エージェントを利用できます。お客様の代わりにマイクロソフトがエージェントをホストする場合、毎月 240 分は無料でビルド/リリース用のホスト パイプラインを使用できます。それ以上使用する場合や、複数のホスト パイプラインを同時実行する場合は、ホスト パイプラインを追加購入し、必要な数だけ使用することができます。

Azure CI/CD の統合

CI/CD パイプラインのセットアップは、厄介な作業です。その理由は、開発するアプリの種類が無限に考えられるためです。どのような種類のアプリであるかを事前に把握できれば、プロセスを大幅に簡素化できます。本日、Azure App Service アプリ向けに CI/CD パイプラインをセットアップできる新機能が Azure ポータルに導入されました。これにより、CI/CD パイプラインのセットアップが格段に容易になるほか、セットアップ後にパイプラインを Visual Studio Team Services (VSTS) で編集し、自由に拡張機能を追加してカスタマイズすることもできます。

この機能を利用するには、Azure Web サイトで [Continuous Delivery] を選択します。

azure-cd-1

シンプルなウィザードに従って、Git リポジトリやアプリの種類 (例: ASP.NET) などを設定し、オプションとしてパイプラインのテスト環境の構成を指定します。また、コードが GitHub に存在する場合は GitHub リポジトリも選択可能です。

azure-cd-2v2

完了すると、自動的にリリースがデプロイされ、結果がポータルに表示されます。

azure-cd-3

完全な CI/CD パイプラインの構成が完了したら、Team Services にアクセスし、デプロイメントのスケジュール設定、手動でのトリガー、スタティック分析など、その他多数の機能を追加してパイプラインをカスタマイズできます。

ホストされた Linux エージェントのプレビュー

Linux でホストされたビルド/リリース エージェント プールが新たに導入され、プライベート エージェントを構成することなく Linux でビルドとリリースを実行できるようになりました。ホストされた Linux プールのプレビューは今後数週間にわたってロールアウトされます (お客様のアカウントですぐに表示されない場合はしばらくお待ちください)。

Linux エージェントは、こちらのリポジトリ (英語) をベースとした Docker コンテナー内の Ubuntu Linux ホストで実行されており、標準の Java、Node、Docker、および .NET Core ツールをすべて備えています。コンテナーの開始時に、ホスト VM の Docker ソケットと /opt/vsts/work の作業フォルダーをマッピングします。これにより、スクリプトまたは Visual Studio Marketplace の Docker 拡張機能 (英語) を使用して、リリース プロセスの一部として他の Docker コンテナーを作成または起動できるようになります。

Docker サポートのプレビューの機能強化

マイクロソフトは、コンテナー ベースのアプリケーションでさらに簡単に CI/CD を実現できるように取り組んでいます。今回、Docker 拡張機能を更新し、新機能を追加すると共に操作性を向上させました。その一環として、Azure Container Service と新しい Azure Container Registry のサポートが組み込まれました。前述の Linux プールと併せて、Team Services でのコンテナーのビルド、テスト、発行がこれまで以上に簡単になります。

また、CI/CD パイプラインのセットアップ プロセスを自動化するツールのプレビュー版もリリースされます。Visual Studio 2017 RC には、ASP.NET Core Preview ワークロードの一部として継続的デリバリー ツールが含まれており、VSTS で DevOps パイプラインを簡単に作成できます。Docker をサポートする ASP.NET Core プロジェクトをセットアップすると、git push が実行されるたびにビルドと Azure Container Services へのデプロイが自動的に実行されます。シンプルなウィザードに従って、個別の「開発」、「ステージング」、「運用」環境など、ビルド、パッケージ、デプロイメント タスクのすべてを作成できます。この機能を利用するには、ASP.NET Core Preview ワークロードをインストールします。また、Azure CLI でも同じシナリオをコマンド ラインからサポートしています。

今後の記事で、このツールや VSTS で実行できる Docker ワークフロー全体について詳しく解説いたします。

作業項目の検索機能のプレビュー

作業項目の検索機能が強化され、シンプルなフィールド ベースの SQL フルテキスト インデックスに代わって、マイクロソフトのコード検索ソリューションでも使用されている Elastic Search プラットフォームをベースとする標準的なドキュメント中心型の検索機能が採用されました。その結果、あらゆる作業項目コンテンツが適切に検索されるようになりました。また、検索構文も強化され、クエリ言語を学習しなくても全文検索とフィールド ベースの検索を組み合わせて使用できるようになったほか、検索結果エクスペリエンスも強化され、ランク付けの精度が向上すると共にプレビューが適切に表示されるようになりました。

以下のスクリーンショットは、「Home Page」という文字列を含み、「Aaron Cathcart」に割り当てられた作業項目を検索した結果です。

witsearch

TFS のインポート

オンプレミス環境の自社管理ソリューションから SaaS への移行に関心をお持ちのお客様が増えています。TFS のお客様は、すべてのデータを保持しながら VSTS に移行したいとお考えです。そこで今回、新たに TFS インポート サービスのプレビューをリリースしました。これにより、TFS のチーム プロジェクト コレクション全体をインポートすることができます。さらに、オンプレミスの Active Directory の ID を AAD の ID にマッピングできるほか、TFS の完全なエクスペリエンスを Visual Studio Team Services で利用するために必要なすべてのものを移行できます。

TFS インポートのプレビューの詳細については、http://aka.ms/TFSImportData (英語) をご覧ください。

マイクロソフトは既に多数の大企業の TFS のお客様と連携し、数千人のユーザーを含む TFS サーバーを Team Services にインポートする作業を実施しています。このサービスの提供範囲を拡大し、さらに多くのお客様の移行を支援できることを嬉しく思います。

今回の一連の機能強化が皆様のお役に立てば幸いです。

Brian Harry


Visual Studio Mobile Center (プレビュー版) の概要

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Introducing Visual Studio Mobile Center (Preview) 2016/11/16

 

本日、Connect(); 2016 (英語) の午前中に行われた基調講演において、モバイル アプリを開発、管理するためのクラウド サービス Visual Studio Mobile Center (英語) のプレビューをご紹介しました。Mobile Center は、Swift、Objective-C、Java、Xamarin、React Native で作成されたアプリをはじめ、iOS と Android をターゲットとするすべてのアプリ向けに設計されています。

モバイル アプリ開発に必要なサービスを統合

優れたモバイル エクスペリエンスを提供するためには、フレームワークや IDE 以外にも、迅速にテストと改良を反復できるように、アプリを継続的にビルド、テスト、配布、監視するためのサービスが必要です。多くのチームは、さまざまなツールや製品からサービスをつなぎ合わせてワークフローを構築しています。しかし、これには時間がかかるうえ、優れたアプリを提供するという本来の使命に集中することができません。

そこでマイクロソフトは、Mobile Center を構築しました。Mobile Center は、開発者が高品質なモバイル アプリを短期間で提供できるように、あらゆるクラウド サービスとライフサイクル サービスを統合したものです。Mobile Center ではアプリをビルド、テスト、配布、監視できるほか、バックエンドのクラウド サービスを簡単に追加して、必要に応じてアプリをスケーリングし、何百万人ものユーザーに提供することができます。

プレビューには多数の優れた機能が含まれており、今後もさらに追加される予定です。現在の機能は以下のとおりです。

  • 各プル リクエストからアプリを自動的にビルドする
  • 数千もの実機のデバイスでアプリをテストする
  • 合格したビルドをベータ テストの参加者に配布する
  • アプリのクラッシュやバグを監視する
  • モバイル分析を使用してユーザーの実際の使用方法を確認する
  • モバイル バックエンドに接続して、スケーリングを自動化したり、オフライン データ同期、表形式データ ストレージ、エンド ユーザー認証サービスといった重要なクラウド サービスを追加したりする

開発者が優れたアプリケーションの開発に集中できるように、これらのサービスは連携して機能し、シンプルで合理的なエンドツーエンドのワークフローを構築できるように設計されていますが、個別に使用することもできます。たとえば、モバイル テストやベータ版の配布など、一部のサービスのみを選択できます。また、パブリック REST API、オープンソースの SDK、コマンドライン ツールを使用して、サービスを独自のワークフローに統合することも可能です。

Mobile Center は、HockeyApp や Xamarin Test Cloud といった既存のモバイル開発者向けサービスの次世代版です。来年後半には、HockeyApp や Test Cloud のお客様がシームレスに移行できるように、Mobile Center に新規と既存のすべての HockeyApp および Test Cloud アプリが表示される予定です。

Mobile Center は簡単に利用を開始できます。招待をリクエストして承認されたら、既存の HockeyApp の資格情報、GitHub アカウント、Microsoft アカウントのいずれかを使用してサインインし、アプリを接続すればビルドを開始できます。プレビュー版は無料でご利用いただけます。希望されるすべてのお客様がサービスを利用してフィードバックを提供できるように、使用量には一定の制限が設けられています。

今後の展望

Mobile Center の今後のバージョンでは、Cordova およびユニバーサル Windows プラットフォームへのサポートの拡大、プッシュ通知や高度な分析といったクラウド サービスの追加が予定されています。

ぜひサインアップ (英語) してご意見をお聞かせください!

MSBuild ベースの .NET Core Tools の「アルファ版」を発表

$
0
0

 

本記事は、マイクロソフト本社の .NET Blog の記事を抄訳したものです。
【元記事】 Announcing .NET Core Tools MSBuild “alpha” 2016/11/16

 

マイクロソフトはこのたび、新しい MSBuild ベースの .NET Core Tools (英語) の最初の「アルファ版」リリースを発表しました。この .NET Core Tools は、Visual Studio 2017 RCVisual Studio for Mac (英語)Visual Studio Code (英語)、コマンド ラインでお試しいただけます。また、.NET Core 1.0 (英語).NET Core 1.1 (英語) の両方のランタイムで利用できます。

.NET Core と ASP.NET Core の開発を始めたときに重視したのは、Windows、Mac、Linux のいずれでも動作し、Visual Studio 以外のエディターでも機能するプロジェクト システムを構築することでした。新しいプロジェクト形式 project.json はそのために作成されました。一方、お客様からは新しい project.json モデルは気に入っているものの、そのプロジェクトを既存の .NET コードでも利用できるようにしたいというご意見もいただきました。これを実現するために現在マイクロソフトでは、既存の .NET プロジェクトと相互運用できるように .NET Core を .csproj/MSBuild ベースに変更し、project.json の優れた機能を .csproj/MSBuild に移行する取り組みを行っています。

Windows、macOS、Linux での .NET Core 開発に利用できるエクスペリエンスは現時点で 4 つあります。

お気づきかと思いますが、Visual Studio ファミリに新しく加わった、Mac 専用の製品があります。この Visual Studio for Mac は、Xamarin および .NET Core プロジェクトをサポートするもので、現在はプレビュー版です。Visual Studio for Mac での .NET Core の使用方法の詳細については本記事の「Visual Studio for Mac」セクションをご覧ください。

新しい MSBuild ベースの .NET Core Tools プレビューは、こちらから (英語) ダウンロードできます。また、新しいエクスペリエンスの詳細については .NET Core のドキュメントをご覧ください。

概要

最近投稿されたブログ記事 (英語) をご覧になっていれば、新しい Preview 3 リリースで MSBuild ビルド システムと csproj プロジェクト形式がサポートされるようになったことをご存知でしょう。マイクロソフトでは以下の理由から、.NET Core に MSBuild を取り入れることにしました。

  • .NET ツール エコシステムの一貫性確保 – MSBuild は、.NET ツール エコシステムの重要なコンポーネントです。MSBuild 向けのツール、スクリプト、Visual Studio 拡張機能は、.NET Core で機能するように拡張されるべきです。
  • プロジェクト間参照の実現 – MSBuild を利用すると、複数の .NET プロジェクト間でのプロジェクト間参照が可能になります。他の .NET プロジェクトではすべて MSBuild が使用されるため、.NET Core も MSBuild に切り替えることで、たとえば、.NET Core プロジェクトからポータブル クラス ライブラリ (PCL) を参照したり、.NET Framework プロジェクトから .NET Standard ライブラリを参照したりすることができます。
  • 実証済みのスケーラビリティ – MSBuild は、大規模なプロジェクトをビルドできることが実証されています。.NET Core の採用が広がるにつれて、だれもが信頼できるビルド システムを用意することが重要になります。MSBuild に変更することで、.NET Core だけでなく、すべての種類のプロジェクトにおけるエクスペリエンスが向上します。

project.json から csproj への移行は重要な変更であり、これについては多くのご意見をいただいていました。まず、変更のない点について説明します。

  • プロジェクト ファイルは 1 つ – 依存関係やターゲット フレームワークの情報はすべて 1 つのプロジェクト ファイルに格納されます。既定ではソース ファイルを指定する必要はありません。
  • ターゲットと依存関係 – .NET Core のターゲット フレームワークとメタパッケージの依存関係に変更はなく、新しい csproj 形式でも同様の方法で宣言されます。
  • .NET Core CLI Toolsdotnet ツールでは引き続き同じコマンド (dotnet builddotnet run など) が提供されます。
  • .NET Core テンプレート – 引き続き dotnet new でテンプレートを利用できます (例: dotnet new -t library)。
  • 複数のバージョンの .NET Core をサポート – 新しいツールは、.NET Core 1.0 と .NET Core 1.1 のどちらを対象とする場合も利用できます。なおこのツール自体は、既定では .NET Core 1.0 上で実行されます。

多くの皆様が既に .NET Core と、既存の project.json のプロジェクト形式およびビルド システムを採用しています。そして、私たちも同様です。そこで、project.json プロジェクト ファイルを csproj に移行するための移行ツールを作成しました。私たちのプロジェクトで利用した限りでは、問題なく移行できています。この移行ツールは Visual Studio と Visual Studio for Mac に組み込まれています。また、コマンド ライン (dotnet migrate コマンド) でも利用可能です。マイクロソフトでは皆様のご意見を基に移行ツールを引き続き改良し、最終リリースまでには大きな規模で実行できるようにする予定です。

今回、MSBuild と csproj プロジェクト形式を使用するように .NET Core を変更したことで、.NET Core の改善点を他の種類のプロジェクトに広げることも可能になりました。マイクロソフトでは特に他の種類の .NET プロジェクトについても、csproj 形式でのパッケージ参照に標準化しようと考えています。

ここからは、サポート対象の 4 つのエクスペリエンスそれぞれにおける .NET Core のサポートについて説明します。

Visual Studio 2017 RC

Visual Studio 2017 RC には、新しい .NET Core Tools のサポートが「Preview」ワークロードとして含まれています。Visual Studio 2015 のエクスペリエンスと比較して、以下の点が改善されています。

  • プロジェクト間参照が機能するようになりました。
  • プロジェクト参照と NuGet 参照が共に csproj で同様に宣言されます。
  • プロジェクトを開いている間に、csproj プロジェクト ファイルを手動で編集できます。

インストール

Visual Studio 2017 は Visual Studio のサイトからインストールできます。

Visual Studio 2017 RC に .NET Core Tools をインストールするには、下図のように、[Web and Cloud] ワークロードの下にある [.NET Core and Docker (Preview)] を選択します。なお、Visual Studio のインストール プロセス全体が変更されています。その詳細については、Visual Studio 2017 RC に関するブログ記事をご覧ください。

.NET Core workload

プロジェクトの新規作成

.NET Core のプロジェクト テンプレートは、Visual Studio の [.NET Core] プロジェクト ノードから利用できます。馴染みのある一連のプロジェクトが表示されます。

.NET Core templates

プロジェクト間参照

.NET Standard プロジェクトを、.NET Framework、Xamarin、UWP の各プロジェクトから参照できるようになりました。下図は、1 つの .NET Standard ライブラリを 2 つのアプリ プロジェクトで利用しています。 

project to project references

NuGet パッケージ参照の管理

馴染みのある NuGet パッケージ マネージャーで NuGet パッケージ参照を管理できます。下図では、プロジェクトに Newtonsoft.Json パッケージが追加されています。

パッケージ参照は csproj プロジェクト ファイルに追加されます。プロジェクト ファイルを詳しく調べる必要はありませんが、必要ならプロジェクト ファイルを編集してパッケージ参照を追加または削除することも可能です。Visual Studio のソリューション エクスプローラーには変更内容が適切に反映されます。

csproj ファイルの編集

プロジェクトを開いている間に、IntelliSense を使用して csproj ファイルを編集できるようになりました。マイクロソフトでは、このような操作を日常的に行うのはごく一部の開発者だけだと考えていますが、それでもこれは重要な改善点といえます。また、NuGet 参照とプロジェクト参照の類似性を表示できる便利な機能もあります。

Editing csproj files

動的なプロジェクト システム

新しい csproj 形式のプロジェクトには、既定ですべてのソース ファイルが追加されます。.cs ファイルをいちいち指定する必要はありません。実際にこの動作を確認するには、Visual Studio の外部からプロジェクト ディレクトリに .cs ファイルを追加します。1 秒以内に、この .cs ファイルがソリューション エクスプローラーに追加されるはずです。

プロジェクト ファイルの内容を最小限に抑えると、読みやすさをはじめとする多くのメリットが得られます。カテゴリ全体にわたる変更や、従来それに伴って発生していたマージ競合が減るため、ソース管理にも有効です。

project.json プロジェクトを開き、アップグレードする

Visual Studio 2017 で project.json ベースの xproj プロジェクトを開くと、そのプロジェクトを csproj にアップグレードするように促すメッセージが表示されます。下図がそのメッセージです。この移行は一方向のみであり、ソース管理機能やバックアップを利用する以外に、project.json に戻す方法はありません。

.NET Core migration

Visual Studio for Mac

Visual Studio for Mac は Visual Studio ファミリに新しく加わった製品であり、Mac でのクロス プラットフォームのモバイルおよびクラウド開発に特化しています。この製品では、.NET Core および Xamarin プロジェクトがサポートされます。実際、Visual Studio for Mac は Xamarin Studio を発展させたものです。

Visual Studio for Mac は、Visual Studio 2017 RC に関して上述した内容によく似た .NET Core 開発の実現を目的としています。マイクロソフトでは、.NET Core Tools、Visual Studio for Mac、Visual Studio 2017 の来年のリリースが近づく中で、引き続き両方のエクスペリエンスを向上させてまいります。

インストール

Visual Studio for Mac は Visual Studio のサイト (英語) からインストールできます。.NET Core および ASP.NET Core プロジェクトがサポートされています。

プロジェクトの新規作成

.NET Core のプロジェクト テンプレートは、Visual Studio の [.NET Core] プロジェクト ノードから利用できます。馴染みのある一連のプロジェクトが表示されます。

.NET Core templates

下図は、新しい ASP.NET Core プロジェクトの例です。

ASP.NET Core New Project

その他のエクスペリエンス

Visual Studio for Mac では、xproj の移行はまだサポートされていません。この機能は、リリースまでに追加される予定です。

Visual Studio for Mac では、プロジェクトが読み込まれている間の csproj ファイルの編集が既にサポートされています。csproj ファイルを開くには、プロジェクト ファイルを右クリックし、[Tools]、[Edit File] の順に選択します。

Visual Studio Code

Visual Studio Code の C# 拡張機能も、新しい .NET Core Tools リリースをサポートするように更新されました。現時点では、プロジェクトのビルドとデバッグをサポートしています。拡張機能のコマンド (コマンド パレット内) はまだ更新されていません。

インストール

VS Code は visualstudio.com (英語) からインストールできます。.NET Core のサポートは、C# 拡張機能をインストールすることで追加できます。インストールするには、[Extensions] タブを使用するか、C# ファイルを開いたときにメッセージが表示されるのを待ちます。

.NET Core プロジェクトのデバッグ

csproj の .NET Core プロジェクトをビルドおよびデバッグできます。

VS Code Debugging

アプリケーションをデバッグする際、VS Code によって launch.json と task.json が作成されます。launch.json はアプリケーションを設定するたびに更新する必要があります。例として launch.json gist を作成しましたのでご確認ください。

.NET Core CLI Tools 

.NET Core CLI Tools (英語) も更新されています。(Visual Studio と同様に) MSBuild ベースとなり、csproj プロジェクト ファイルを使用するようになりました。以前に project.json ファイルの処理に使用されていたロジックはすべて削除されました。CLI ツールは (実装の観点からすると) はるかにシンプルになり、MSBuild に大きく重心を移していますが、その有用性や必要性は変わっていません。

マイクロソフトが CLI ツールを更新するためのプロジェクトを立ち上げたとき、CLI ツールの存在意義を考慮する必要がありました。特に、MSBuild 自体が独自のコマンド ライン構文、エコシステム、歴史を持つコマンドライン ツールであるためです。その結果、シンプルかつ直観的なツールを提供することで、.NET Core (およびその他の .NET プラットフォーム) の導入を容易にし、MSBuild ベースのツールと MSBuild ベースではないツールの両方に対応した統合インターフェイスを利用できるようにすることが重要だという結論に達しました。将来のリリースで .NET Core Tools の拡張性に重点が移るにつれて、このビジョンの価値が高まっていくことでしょう。

インストール

新しい .NET Core Tools をインストールするには、.NET Core SDK の Preview 3 (英語) をインストールします。この SDK には .NET Core 1.0 が付属しています。また、別途インストールできる .NET Core 1.1 と共に使用することも可能です。

VS の外部で project.json ベースの開発を行っている場合は、MSI/PKG ではなく zip ファイルからインストールすることを推奨します。

複数バージョンの共存

新しい SDK をインストールすると、dotnet コマンドの既定の動作が変わります。つまり、MSBuild を使用し、project.json ではなく csproj プロジェクトを処理するようになります。同様に、dotnet new を実行すると csproj プロジェクト ファイルが作成されます。

プロジェクト単位で以前の project.json ベースのツールを使用し続けるには、プロジェクト ディレクトリ内に global.json ファイルを作成し、このファイルに “sdk” プロパティを追加します。次の例は、project.json ベースのツールを dotnet で強制的に使用するようにするための global.json です。

テンプレート

dotnet new コマンドを使用すると、新しいプロジェクトを作成できます。このコマンドは引き続き、-t 引数によってプロジェクトの複数の種類をサポートします (例: dotnet new -t lib)。サポートされるすべてのテンプレートは次のとおりです。

  • console
  • web
  • lib
  • xunittest

マイクロソフトでは、今後一連のテンプレートを拡張していくと共に、コミュニティの皆様がテンプレートを拡張しやすいようにする予定です。具体的には、dotnet new で完全なサンプルを取得できるようにしたいと考えています。

project.json プロジェクトのアップグレード

dotnet migrate コマンドを使用すると、project.json プロジェクトを csproj 形式に移行できます。またこのコマンドは、project.json ファイル内に存在するプロジェクト間参照も自動的に移行します。詳細については、dotnet migrate コマンドのドキュメント (英語) を参照してください。

以下は、project.json から csproj に移行した後に得られる既定のプロジェクト ファイルの例です。マイクロソフトでは引き続き csproj 形式を簡素化し、そのサイズを減らすための手段を探っているところです。

他の種類のプロジェクトについては、既存の .NET csproj ファイルには GUID とファイル参照が含まれています。これらは .NET Core csproj プロジェクト ファイルから (意図的に) 省かれています。

プロジェクト参照の追加

csproj にプロジェクト参照を追加するには、<ItemGroup> 要素の内側に <ProjectReference> 要素を配置します。以下はその例です。

<ItemGroup>
  <ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj" />
</ItemGroup>

この操作の後、dotnet restore を実行して「アセット ファイル」(project.lock.json ファイルの代替となるファイル) を生成する必要もあります。

NuGet 参照の追加

マイクロソフトでは、csproj の全体的なエクスペリエンスに対してもう 1 つの改良を行いました。それが、NuGet パッケージの情報を csproj ファイルに組み込む機能です。これは、新しい <PackageReference> 要素を使用して行います。以下はその例です。

<PackageReference Include="Newtonsoft.Json">
  <Version>9.0.1</Version>
</PackageReference>

.NET Core 1.1 を使用するようにプロジェクトをアップグレード

dotnet new コマンドを実行すると、.NET Core 1.0 を使用するプロジェクトが作成されます。下記の例のように、.NET Core 1.1 を使用するようにプロジェクト ファイルを更新することもできます。

上記のプロジェクト ファイルは、以下の 2 点が更新されています。

  • ターゲット フレームワークを netcoreapp1.0 から netcoreapp1.1 へと更新
  • Microsoft.NETCore.App のバージョンを ‘1.0.1’ から ‘1.1.0’ へと更新

運用環境のアプリへの対応

マイクロソフトは 6 月に、.NET Core 1.0 と、project.json ベースの .NET Core Tools をリリースしました。開発者の多くがアプリをビルドする PC 上や、運用環境でのサーバー/クラウド上でこのリリースを日常的に利用していることと思います。このたびリリースした .NET Core 1.1 も、同じようにご利用いただけます。

ただし、今回の .NET Core Tools のリリースはアルファ版とされており、運用環境での使用は推奨されていません。運用環境での利用には、Visual Studio 2015 を含め、既存の project.json ベースの .NET Core Tools (Preview 2) を使用することが推奨されます。

新しい MSBuild ベースの .NET Core Tools をリリース時には、プロジェクトを Visual Studio 2017 および Visual Studio for Mac で開いて、すばやく移行できるようになる予定です。

現時点では、サンプル プロジェクトまたはソース管理を行っているプロジェクトを使用して、今回リリースした Tools のアルファ リリースや Visual Studio 2017 RC の .NET Core Tools の「Preview」ワークロードをお試しください。

まとめ

ぜひ新しい .NET Core Tools リリースをお試しいただき、ご意見をお寄せください。新しい csproj/MSBuild のサポートは、Visual Studio 2017 RC、Visual Studio for Mac、Visual Studio Code、コマンド ラインでお試しいただけます。Windows、macOS、Linux における .NET Core 開発のための優れた手段をご活用ください。

この記事をまとめると、最も大きな変更点は以下のようになります。

  • .NET Core の csproj のサポートがアルファ リリースとして利用可能になりました。
  • .NET Core が Visual Studio 2017 RC および Visual Studio for Mac に組み込まれました。Visual Studio Code には、C# 拡張機能を通じて追加できます。
  • .NET Core Tools のベースとなるテクノロジが、他の .NET プロジェクトと同じものになりました。

project.json と csproj についてご意見をお寄せくださった皆様には、改めてお礼を申し上げます。引き続き皆様のご意見をお待ちしておりますので、新しいリリースをぜひお試しください。

.NET Core 1.1 をリリース

$
0
0

 

本記事は、マイクロソフト本社の .NET Blog の記事を抄訳したものです。
【元記事】 Announcing .NET Core 1.1 2016/11/16

 

このたび、.Net Core の最初の「Current」リリースとなる .NET Core 1.1 RTM (英語) がリリースされました。これにより、Visual Studio 2015、Visual Studio 2017 RC、Visual Studio Code、Visual Studio for the Mac で .NET Core 1.1 アプリを作成できるようになります。

今回の 1.1 リリースでは下記の点が強化されています。

  • .NET Core: ディストリビューションの追加とパフォーマンスの強化
  • ASP.NET Core (英語): Kestrel の強化、Azure のサポート追加、生産性の向上
  • EF Core (英語): Azure および SQL 2016 のサポート

最新ニュース: ASP.NET Core 1.1 と Kestrel の組み合わせが、TechEmpower のプレーン テキスト形式ベンチマーク (英語) において主要なフルスタック Web フレームワークの中で最高速度を記録しました。

最新ニュース: Google Cloud (英語) が新たに .NET Foundation Technical Steering Group に加わります。Google の参加を歓迎します!

.NET Core の変更内容の詳細は、.NET Core 1.1 のリリース ノート (英語) にすべて記載されていますのでご確認ください。3 週間前にリリースされた .NET Core 1.1 Preview 1 (英語) からそれほど大きな変更はありません。

インストール方法

新しいリリースは .NET Core ダウンロード ページ (英語) からインストールできます。今回の .NET Core は「Current」リリースです。[Current] ボタンをクリックして、表示されるリンクをご利用ください。

ディストリビューション

新たに下記のディストリビューションがサポートされました。

  • Linux Mint 18
  • openSUSE 42.1
  • macOS 10.12 (.NET Core 1.0 でも新たにサポート)
  • Windows Server 2016 (.NET Core 1.0 でも新たにサポート)

サポート対象のディストリビューションは .NET Core 1.1 のリリース ノート (英語) にすべて記載されています。

ドキュメント

今回のリリースに合わせて .NET Core のドキュメント ページが更新されています。ドキュメントは今後も継続的に更新されます。また、利用しやすく充実した内容となるように、ページのデザインやコンテンツも改善しています。

ASP.NET Core (英語)Entity Framework (英語)C# (英語)VB (英語) のドキュメントは、今回のリリースから docs.microsoft.com に移動されました。また、F# のドキュメント (英語) は数か月前に追加されています。

docs.microsoft.com で公開されているドキュメントはオープン ソースです。より充実した内容にするために、GitHub での Issue の作成や活動へのご協力をお願いします。まずは dotnet/docs (英語)aspnet/docs (英語) から参加されることをお勧めします。

パフォーマンス

先日、TechEmpower (英語) のプレーン テキスト形式ベンチマークで、ASP.NET Core 1.1 と Kestrel の組み合わせが主要なフルスタック Web フレームワークの中で最高速度を記録しました。このすばらしい結果は、大規模なエンジニアリングの取り組みの成果です。

Windows 版 .NET Core 1.1 では、ガイド付き最適化のプロファイル (PGO) と呼ばれるパフォーマンス最適化手法を CoreCLR ランタイムで採用しています。この技術は .NET Framework で長年使用されていましたが、.NET Core ではまだ採用されていませんでした。以前リリースされた .NET Core 1.1 Preview 1 では実装されていません。

PGO は、マイクロソフトのテスト環境での計測に使用するアプリの記録に基づいて、C++ コンパイラで生成されたバイナリを最適化します。マイクロソフトではこのプロセスを「トレーニング」と呼び、冬の夜明け前の午前 6 時にランニングするくらいワクワクする瞬間です。PGO は、バイナリでどのコードパスがどのような順序で使用されたかを記録します。今回のリリースに向けたトレーニングには、簡単な “Hello World” アプリが使用されました。

マイクロソフトのテスト環境では、PGO で最適化された CoreCLR を使用して実行される ASP.NET の MusicStore アプリ (英語) で 15% のパフォーマンス向上が見られました。他の Web アプリケーションでもこれと同様の効果が得られると考えています。今後はトレーニングに使用するアプリの種類を増やし、さらに高い効果が得られるように改良を進めてまいります。

Linux および macOS では、CoreCLR のコンパイルに Clang と LLVM が使用されます。次回リリースでは、Clang バージョンの PGO (英語) を使用することを計画しています。Clang PGO の収集はまだ初期の段階ですが、こちらでも同様の効果が得られると見ています。

API

.NET Core 1.1. では新たに 1,380 個の API (英語) が追加されました。新しい API の多くは、移植可能な PDB (英語) の読み込みなど、この製品自身をサポートするためのものです。.NET Core 1.1 では NETStandard.Library 1.6.0 (英語) がサポートされています。

NETStandard.Library 2.0 (英語) は 2017 年にリリースされるバージョンでサポートされる予定で、.NET Core 1.1 ではサポートされません。

.NET Core 1.1 を使用する

まずは、.NET Core 1.1 をインストールします。.NET Core 1.1 は、インストーラー (英語) やパッケージ マネージャーを使用して OS にグローバルにインストールすることも、zip 形式でダウンロード (英語) して限定的に (容易に削除できるように) インストールすることもできます。

安全な共存インストール

.NET Core 1.1 は、.NET Core 1.0 が既にインストールされているマシンに安全かつグローバルにインストールできます。

dotnet new コマンドを実行すると新しいテンプレートが作成されます。このテンプレートはマシン内の最新のランタイムを参照しますが、それが望ましくない場合もあります。その場合は、project.json のバージョン番号を手動で古いバージョン番号に変更すると回避できます。皆様からのフィードバックにお応えして、この挙動は Visual Studio 2017 の最終バージョンと同時にリリースされる新バージョンのツールで変更される予定です。dotnet new コマンドではなく Visual Studio を使用してプロジェクトを新規作成すれば、この問題は発生しません。

使用の開始

.NET Core はコマンド ライン ツールから使用できます。コマンド プロンプトかターミナルで下記のコマンドを実行します。

dotnet new
dotnet restore
dotnet run

.NET Core 1.1 をお試しいただく場合は、Docker で .NET Core を使用している dotnet-bot サンプル (英語) もご利用になれます (Docker を必ず使用する必要はありません)。

既存の .NET Core 1.0 プロジェクトのアップグレード

既存の .NET Core 1.0 プロジェクトは .NET Core 1.1 にアップグレードできます。以下に、新しくなった dotnet new コマンドで生成される新しい project.json ファイルの内容を紹介しますので、新しいバージョン番号をご確認のうえ、既存の project.json ファイルにコピー アンド ペーストしてください。プロジェクトを新しいバージョンの .NET Core に自動的にアップグレードするツールはありません。

.NET Core 1.1 の既定の project.json ファイルは下記のとおりです。

この project.json ファイルは .NET Core 1.0 のものとほぼ同じですが、ターゲット フレームワークが netcoreapp1.1 に、メタパッケージのバージョンが 1.1.0 に変わっています。

.NET Core 1.1 に一時的に、または恒久的に移行する場合、下記のように project.json ファイルを変更します。

  • ターゲット フレームワークを netcoreapp1.0 から netcoreapp1.1 に変更する。
  • Microsoft.NETCore.App パッケージのバージョンを 1.0.x (1.0.01.0.1 など) から 1.1.0 に変更する。

.NET Standard Library プロジェクトをアップグレードする

.NET Standard Library プロジェクトを変更する必要はありません。

マイクロソフトは NETStandard.Library 1.6.1 (英語) メタパッケージを公開しましたが、ライブラリを生成する際にそれを参照しても効果はありません。最新のパッケージは、新しい Microsoft.NETCore.App 1.1.0 (英語) メタパッケージの依存関係として提供されています。

.NET Core 1.1 Docker イメージの使用

.NET Core 1.1 は Docker で使用できます。最新のイメージは microsoft/dotnet (英語) で公開されています。

latest タグは .NET Core 1.1 SDK を指すように変更されています。これは .Net Core 1.1 Preview 1 リリース時の記事でご説明していた当初の意向とは異なっています。Current リリースと LTS リリースが存在する他のプラットフォームについて調べたところ、latest タグで最新バージョンが指定されることが確認されたためです。どうぞご了承ください。

.NET Core 1.1 では 2 つのランタイム タグが新たに追加されました。

  • Linux: 1.1.0-runtime
  • Windows: 1.1.0-runtime-nanoserver

.NET Core 1.1 では 2 つの SDK タグが新たに追加されました。

  • project.json を使用する Preview 2 ベースの SDK: 1.1.0-sdk-projectjson
  • CSProj を使用する Preview 3 ベースの SDK: 1.1.0-sdk-msbuild

.NET Core 1.1 を試用する場合は、.NET Core Docker サンプル リポジトリ (英語) で公開されている [dotnetapp-current samples] の [dotnetapp-current] を使用すると便利です。他のサンプルも、project.json と Dockerfile の両ファイルのバージョン文字列を前述の説明のように適切なものに変更すると、.NET Core 1.1 イメージを使用するように簡単に変更できます。

Current リリース

以前に .NET Core 1.1 のブログ記事でご説明したように、マイクロソフトでは業界の慣習にならって「Long Term Support (LTS、英語)」と「Current」の 2 種類のリリースを提供しています。.NET Core 1.1 は Current リリースとして最初のリリースです。特定の Current リリースに対しては、セキュリティ更新プログラムを除いて更新プログラムはほとんどリリースされません。

大多数の開発者の方には LTS リリースを導入することをお勧めします。Visual Studio では LTS リリースが既定のエクスペリエンスとなります。ただし、一部の開発者の方には Current をお使いいただき、フィードバックをご提供いただけますと幸いです。数値化することは簡単ではありませんが、.NET Core 開発者全体での採用率が LTS リリース 80%、Current リリース 20% 程度になることが適切であろうと考えています。

まとめ

ぜひ新しい .NET Core リリースをお試しになり、フィードバックをお寄せください。.NET Core 1.1 (英語)、ASP.NET Core、EF Core では、皆様のアプリの品質とパフォーマンスが向上されるように重要な機能強化を多数行っています。今回のリリースは最初の Current リリースとして、数年間のサポートがある LTS リリースを待たずに .NET Core を更新したい開発者に向けて各種の機能をいち早くお届けするものです。

今回の主な変更点についてもう一度お伝えします。

  • パフォーマンスが向上し、TechEmpower のベンチマーク (英語) で 1 位を獲得
  • OS ディストリビューションを 4 つ追加
  • 新機能を数十個追加、不具合を数百か所修正
  • ドキュメントを更新

.NET Core 1.0 と .NET Core 1.1 Preview 1 を使用してフィードバックをお寄せくださった皆様に改めて感謝申し上げます。プロジェクトにご協力いただきありがとうございました。今回の最新リリースについても皆様のご意見をお待ちしております。

Visual Studio 2015、Visual Studio 2017 RC、Visual Studio Code、Visual Studio for the Mac でぜひ .NET Core 1.1 アプリを作成してみてください。

Visual Studio 2017 RC のライブ ユニット テスト

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Live Unit Testing in Visual Studio 2017 RC 2016/11/18

 

Visual Studio 2017 に新機能のライブ ユニット テストが導入されました。この機能を使用すると、スピードが求められる開発作業の中でも、品質を確保しながら必要なテストをすべて網羅できるため、生産性が大幅にアップします。たとえば、なじみの薄いコード ベースのバグを修正する必要がある場合、この機能を使用すれば、修正によるコード変更がシステムの他の部分に影響しないかをすぐにチェックできます。また、コードを入力していくとその場でフィードバックを得られるので、より生産的にコーディングを進められるだけでなく、バグの修正やユニット テスト作成も楽しくなるに違いありません。

ライブ ユニット テストでは、コードの編集中にバックグラウンドで影響範囲のユニット テストが実行され、その結果やテスト範囲がリアルタイムでエディターにわかりやすく表示されます。コード変更の既存テストへの影響のほか、新たに追加したコードが 1 つ以上の既存のテスト範囲でカバーされているかどうかも即座にフィードバックされます。このため、バグの修正や機能の追加の際に、ユニット テストの作成が必要かどうかを把握できます。コード ベースのテストがすべて成功すればひと安心です。

ライブ ユニット テストは Visual Studio 2017 Enterprise エディションで使用可能で、.NET Framework をターゲットとした C# と VB のプロジェクトに対応しています。この機能では、VB と C# のコンパイラを使用してコンパイル時にコードを実装します。次に、そのコードでユニット テストを実行してデータを生成します。このデータは、テスト範囲に含まれるコードの行を分析するために使用されます。そして、このデータを使用して編集箇所のテストを実行し、すぐにエディター内に結果を表示します。コードを編集したりテストを追加または削除したりするたびにデータが更新され、影響を受けるテストが特定されます。

ライブ ユニット テストを開始する

ライブ ユニット テストを開始するには、上部のメニュー バーの [Test] コマンドから下図のように選択します。

Visual Studio のライブ ユニット テストでは、広く使われている MSTest、xUnit、NUnit の 3 つのユニット テスト フレームワークが主に使用されます。これらを使用する場合は、アダプターとフレームワークが以下の最小バージョンかそれよりも新しいバージョンであることを確認してください。ライブ ユニット テストを使用できない場合は、既存のプロジェクトからは古いアダプターとテスト フレームワークの参照を削除 (“Microsoft.VisualStudio.QualityTools.UnitTestFramework” への参照を必ず削除) し、新しいものを追加してください。これらのコードはすべて NuGet.org で入手できます。

  • xUnit: xunit.runner.visualstudio バージョン 2.2.0-beta3-build1187 および xunit 2.0 (またはそれ以降)
  • NUnit: NUnit3TestAdapter バージョン 3.5.1 および NUnit version 3.5.0 (またはそれ以降)
  • MSTest: MSTest.TestAdapter 1.1.4-preview および MSTest.TestFramework 1.0.5-preview (またはそれ以降)

ライブ ユニット テストのエクスペリエンス

ライブ ユニット テスト機能を有効化すると、テストでカバーされるコードの部分がすぐに表示され、テストの合否もエディター内で確認できます。ユニット テストの結果と範囲は、コード エディターで 1 行ごとに下記のように表示されます。

clip_image001実行可能なコードのうち少なくとも 1 つのテストでエラーが発生している行には赤色の “×” が表示されます。

clip_image002実行可能なコードのうちすべてのテストが成功した行には緑色の “✓” が表示されます。

clip_image003実行可能なコードのうちどのテスト範囲にも含まれない行には青色の横線が表示されます。

ライブ テスト ユニットでのコードの範囲とテスト結果がリアルタイムで提示されるため、手動で範囲を選択してテストを実行する手間がなくなります。また、コードの変更によりプログラムでエラーが発生すると緑色の “✓” が赤色の “×” に変わり、1 つ以上のテストが失敗したことがリアルタイムで通知されます。

また、“✓” や “×” にマウス カーソルを合わせると、その時点で該当する行をカバーしているテストの数が下図のように表示されます。

“✓” や “×” をクリックすると、該当する行で実行されているテストが下図のように表示されます。

ツール ヒントの中で失敗したテストにマウス カーソルを合わせると、下図のようにウィンドウが拡大されてエラーの詳細情報を確認できます。

さらに、失敗したテストをツール ヒントでクリックすると、そのテストに直接移動できます。バックグラウンドでライブ ユニット テストを実行中でも、該当するテストに移動して簡単にコードのデバッグ、編集、続行の工程を実施できます。デバッグ、編集、続行のサイクルの中でライブ ユニット テストを停止したり再開したりする必要はありません。

リファクタリング作業などでしばらくテストでエラーが発生することがわかっている場合などには、いつでもライブ ユニット テストを一時停止/完全停止することができます。その場合も、開始のときと同様に下図のように上部のメニュー バーの [Test] コマンドから必要な項目を選択するだけです。

一時停止すると、エディター内でテストの範囲が表示されなくなります。ライブ ユニット テストのメニューで [Continue] をクリックすると一時停止が解除され、テスト範囲が再び表示されるようになります。一時停止中は、一時停止前にライブ ユニット テストで収集されたデータはそのまま維持されます。[Continue] をクリックすると一時停止された後のすべての編集内容が確認され、グリフが適切に更新されます。

ライブ ユニット テストは必要に応じて完全に停止することもできます。完全停止した後にライブ ユニット テストを再開した場合、以前のデータはすべて消去されているため、停止する前に表示されていたグリフは表示されません。

まとめ

ライブ ユニット テストを使用すれば、開発者の生産性をアップさせ、あらゆるテストを網羅して、開発中のソフトウェアの品質を向上させることができます。.NET 開発者の皆様はぜひ Visual Studio 2017 でこの機能をお試しください。テスト主導で開発を行っているチームなら、日々のワークフローをゲーム感覚で楽しめるようになるはずです。最初のテストがすべて失敗したとしても、さまざまなテクニックを駆使して 1 つずつ困難をクリアしていくのは気持ちが良いものです。その感覚は練習の成果をコーチに認められたときの喜びにも似ています。

問題点がありましたら、インストーラーまたは Visual Studio IDE 本体の [Report a Problem (英語)] オプションからご報告をお願いします。また、新機能のご提案は UserVoice (英語) までお寄せください。

ライブ ユニット テストのビデオ (英語) でこの機能のデモをぜひご覧ください。

Joe Morris (Visual Studio 担当シニア プログラム マネージャー、@_jomorrisJoe)

Joe Morris は 19 年前にマイクロソフトに入社し、この 3 年間はスタティック分析と開発者の生産性について集中的に取り組んでいます。

Manish Jayaswal (Visual Studio 担当主任エンジニアリング マネージャー)

Manish Jayaswal はコンパイラ テクノロジ、デバッガー、プログラム言語、品質保証、エンジニアリング システムの各分野の深い専門知識を活かして、商用ソフトウェア開発の管理を長年担当してきました。

 

Visual Studio Tools for Unity 3 プレビューをリリース

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Visual Studio Tools for Unity 3 Preview 2016/11/17

 

今回の Connect() (英語) において、Visual Studio Tools for Unity (VSTU) 3 プレビューがリリースされました。VSTU はマイクロソフトが提供する無料の Visual Studio アドオンで、Unity のゲーム開発用ツールおよびプラットフォームと連携してプログラミングやデバッグを行うためのリッチな機能を提供します。

VSTU 3 プレビューは [Game Development with Unity] ワークロードの一部として Visual Studio 2017 RC のインストーラー (英語) からインストールできます。このワークロードでは、Unity 開発者が Visual Studio 2017 RC でクロスプラットフォームの Unity ゲームを作成、デバッグする際に必要となるコンポーネントをインストールすることができます。

VSTU 3 プレビューは、Visual Studio ギャラリー (下記リンク) から Visual Studio 2015 Update 3 向けにも提供されています。

VSTU 3 では、コードの編集とデバッグといった IDE の基本機能が重点的に改良されています。今回のリリースの注目すべき点をご紹介します。

Unity メッセージのコードの色付け: エディター内で Unity メッセージ (またはイベント関数) を他のメソッドと区別し目立たせることができるようになりました。既定ではキーワードの色が適用されていますが、ユーザー独自の色付けが可能です。次のスクリーンショットは明るいオレンジ色に設定した例です。

IntelliSense: Visual Studio の C# 用 IntelliSense エンジンによる Unity メッセージのコード補完がサポートされています。Unity メッセージがサポートされているクラスでメソッドを宣言し始めると、IntelliSense が機能し、スクリプトで使用可能な Unity メッセージのリストが表示されます。

式エバリュエーターの改善: 式エバリュエーターは、ローカル変数の値や、開発者がウォッチ ウィンドウやイミディエイト ウィンドウに入力した式の結果を表示します。この式エバリュエーターを改善し、C# 開発者がよく知っている .NET デバッガーの動作に近付けました。

Visual Studio 2017 RC と Unity

Visual Studio 2017 RC をスクリプト エディターとして使用する場合は、Unity 5.4 以降が必要です。Unity では Visual Studio 2017 RC のインストール場所が特定されないため、ユーザーが手動で指定する必要があります。マイクロソフトでは、将来のバージョンの Unity では手動での指定が不要になるように Unity と協力して取り組んでいます。Unity で [Edit]、[Preferences]、[External tools] の順にクリックし、[External Script Editor] で [Browse] を選択し、Visual Studio 2017 RC の .exe ファイルの場所を指定してください。既定では、このファイルは次の場所にあります。

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
VSTU 3 プレビューについてご提案や問題点がありましたら、インストーラーまたは Visual Studio IDE 本体の [Report a Problem] からご報告 (英語) をお願いします。開発者コミュニティ ポータル (英語) に寄せられているフィードバックもご確認ください。ご提案は UserVoice (英語) でもお待ちしております。お気軽にフィードバック (英語) をお寄せください。VSTU 3 の開発の参考にさせていただきます。
Jb Evain (主任ソフトウェア エンジニアリング マネージャー)
@jbevain

Jb Evain は Visual Studio Tools for Unity のエクスペリエンスを担当しています。開発者ツールやプログラム言語に情熱を傾け、10 年以上にわたって開発者テクノロジの分野に携わっています。

JavaScript を使用する iOS 開発者や Android 開発者に向けた新機能

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Whats’s new for iOS and Android developers using JavaScript? 2016/11/17

 

今週発表された Visual Studio 2017 RC には、Visual Studio Tools for Apache Cordova (TACO、英語) の最新リリースが含まれています。このリリースにあたって、マイクロソフトではモバイル開発者の皆様が日々直面している大きな課題に取り組みました。その取り組みは、主に次の 2 つのテーマに分けられます。

  1. 高速かつ信頼性の高いビルド: Visual Studio の新しいインストーラーでは、サードパーティ製コンポーネントの十分に検証されたツールチェーンのオフライン インストールを組み合わせることで、より高速なビルドが実現されています。これにより、トラブルシューティングや修復もさらに容易になります。
  2. 編集とデバッグの大幅な高速化: 新しいブラウザー ベースのシミュレーターでは、コードをすばやく実行してブラウザー内で即座に結果を確認できます。ライブ リロード、プラグイン シミュレーション、Ionic Framework のサポートにより、Visual Studio に市場最速の開発者ワークフローが実現されています。

高速かつ信頼性の高いビルド

Cordova 開発者の方々とお話ししたところ、現時点で最も一般的な問題となっているのは環境のセットアップとアプリケーションの構築に関連するものでした。これは当然のことでしょう。たとえば、ネイティブなターゲット プラットフォームの SDK を使用してネイティブなアプリケーションを構築するというように、構築こそが Cordova のすべてであるからです。マイクロソフトの調査によると、TACO を使用している開発者の 26% は、主に NPM とネットワーク ファイアウォールでの問題により初回のビルドでエラーを経験しています。今回のリリースでは、この問題の解決に取り組みました。

高速なインストールと確実な動作

Visual Studio の新しいインストーラーでは、迅速にインストールが完了し「確実に動作」する Mobile development with JavaScript ワークロードが追加されています。

このワークロードはツールチェーンの依存関係の総数が削減され、テストが強化されています。十分に検証された新しい「ツールセット」を使用することで、モバイル開発者は Cordova などのオープン ソース パッケージを含め、プレリリース版の開発作業に必要なすべてのコンポーネントを入手できます。オフライン インストールが必要な方にもご利用いただけます。初期テストでは、ほとんどの場合「ダウンロード」してから「コードの作成」を開始するまでの所要時間は 15 分以内でした。

アプリケーションの開発をプロトタイプから製品版へと進めていくと、不足している依存関係をインストールするように促すダイアログが Visual Studio で表示されるようになります。たとえば、あるデバイスにデプロイするときに Android SDK が不足している場合、これをインストールするように促されます。便利だと思いませんか。シンプルなツールチェーンで開発を始め、アプリケーションが拡張し必要なツールチェーンが複雑になるにつれて徐々にインストールを進めていくことができます。

ツールセット

インストールの合理化のほかに、さまざまな環境でのビルドの信頼性向上にも重点的に取り組みました。ビルドに関してご報告いただいている問題のほとんどには、NPM のエラー、ネットワークのファイアウォール、ローカル ツールチェーンの互換性不足が複合的に関連しています。このような問題に対処し、正しい状態を維持するために、TACO では「ツールセット」という概念が新たに導入されました。このツールセットは Visual Studio で使用される検証済みの一連のツールを 1 つのパッケージにまとめたものです。たとえば、既定の Cordova 6.3.1 ツールセットには Cordova 6.3.1、Node 4.4.3、NPM 2.15.0 が含まれており、コンピューターにその他のものがインストールされていても、TACO でアプリケーションを作成する際にはサンドボックス化されたツールセットが使用されます。ツールの組み合わせが既知のものであるため、開発者の期待どおりに動作するアプリケーションを作成できます。細かくカスタマイズしたい場合は、任意のツールチェーンの依存関係のグローバル インスタンスを使用することもできるため、全体を完全に管理できます。

プロジェクトで使用するツールセットを構成するには、config.xml を開いてエディターの [Toolset] セクションに移動します。ツールセットの構築、保守、配布はマイクロソフトが行います。iOS、Android、Windows の新しいバージョンのリリース後すぐにマイクロソフトが新しいツールセットをリリースしますので、Visual Studio の更新を頻繁にご確認ください。

ビルド エラーの把握が容易に

ビルド エラーが発生したときのトラブルシューティングを容易にするために、小規模ながらも重要な変更が行われ、ビルド出力を容易に確認できるようになりました。ビルド出力画面のエラーの表示が色付けされて見やすくなっています。また、処理のステップを区切るためのヘッダーがビルド出力に追加され、ビルド処理のどこでエラーが発生したかを特定しやすくなっています。

この機能は便利であると同時に、楽しいアスキー アートも含まれています。

編集とデバッグを大幅に高速化

今回のリリースでは、Visual Studio Code の Cordova Tools 拡張機能の中から、広く使用されている Cordova Simulate が導入されています。TACO をある程度使用したことがある開発者にとっては、モバイル アプリのブラウザー内シミュレーションとしてこれまで使用されてきた Ripple エミュレーターに代わる存在となります。Cordova Simulate が提供するローカルで実行可能な高速のブラウザー ベース ワークフローは、最新の Web 開発での利用に適しており、エミュレーターやデバイスを使用せずにほぼすべてのモバイル開発を可能にします。

Cordova Simulate では、Ripple と同様に下記に対応しています。

  • さまざまなサイズのデバイスをテスト
  • 地理位置情報、コンパス、加速度センサーを設定してシミュレート
  • 画像、スタイルシート、JavaScript、HTML をライブでリロード
  • DOM エクスプローラーや JavaScript デバッガーなどのブラウザー ベースの開発ツールを Visual Studio 内で使用

また、Ripple にはない機能もあります。

  • カメラ、連絡先、ファイル、メディアなど、より多くのプラグインをシミュレート (詳細はこちらのドキュメント (英語) を参照)
  • iframe ではなく専用のブラウザー ウィンドウでアプリをシミュレート
  • カスタム プラグインや一般的でないプラグインの API 応答を保存

この新ツールの詳細については、後日このブログで詳細記事を公開する予定です。どうぞご期待ください。

Visual Studio 2017 RC を使用してご意見をお寄せください

今回ご紹介した機能以外にも、不具合を数多く修正したほか、ビルド プロセスを作り直して安定性の向上とビルド時間の短縮を実現しています。モバイル アプリの構築に Cordova を試してみたいと思っている方は、ぜひ今回のリリース (英語) をお試しになりご意見をお寄せください。

ツールをご利用いただいてお気づきになった点は、メールで直接お送りいただくか、Stack Overflow (英語)Twitter までお寄せください。また、ドキュメントに関するご意見はドキュメント サイト (英語) まで直接お寄せください。

今後のプレリリース版ソフトウェアに関する最新情報をご希望の方は、TACO insiders (英語) にご参加ください。皆様のご協力をお待ちしております。

Jordan Matthiesen (@JMatthiesen)
JavaScript モバイル開発者ツール担当プログラム マネージャー
Jordan Matthiesen はマイクロソフトで Web アプリケーションおよびモバイル アプリケーション開発者向けの JavaScript ツールを担当しています。それ以前にも 18 年以上の開発経験があり、現在は優秀なモバイル開発者からできるだけ多くの意見を取り入れることに力を入れています。プライベートでは、妻と 4 人の子ども、2 匹の猫、1 匹の犬と共にコーヒーを飲みながらゆっくり過ごす時間を大切にしています。

 

Visual Studio “15” の全体的な応答性を向上

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Improved overall Visual Studio “15” Responsiveness 2016/10/14

 

今回の記事は、Visual Studio “15” のパフォーマンス強化について 5 回にわたってお伝えするシリーズ記事の最終回です。

このシリーズでは下記の内容についてお伝えしてきました。

今回の記事では、Preview 5 に実装された機能強化のうち、Visual Studio を日常的に使用する際の応答性の向上を目的とするものをご紹介します。以下のセクションでは、デバッグのパフォーマンス向上、Git ソースの制御性の向上、XAML の編集エクスペリエンスの強化、拡張機能の管理による入力エクスペリエンスの強化について順番にご説明します。

デバッグ エクスペリエンスの高速化と編集中の応答性低下の防止

Visual Studio 2005 では、WPF、Windows フォーム、マネージ コンソール プロジェクトのホスティング プロセスが導入され、[Start Debugging] の応答を高速化するために、次回のデバッグ セッションで使用可能なプロセスをバックグラウンドで起動していました。しかし、この機能を導入した結果、[Stop Debugging] をクリックしたり、デバッグ セッションの終了後に Visual Studio を使用した場合に、Visual Studio が一時的に応答しなくなる問題が発生しました。

Preview 5 では、ホスティング プロセスを無効にして [Start Debugging] を最適化しました。これにより、ホスティング プロセスを使用しなくても従来の高速性が維持されるほか、以前からホスティング プロセスを使用していなかった ASP.NET、Universal Windows、C++ プロジェクトの場合はさらに高速になります。下記のグラフは、テスト マシンでサンプルの UWP 写真共有アプリ (英語)、素数の可視化を実行する C++ アプリ、簡単な WPF アプリの 3 つの起動時間を測定した結果です。

この機能強化を実現するために、[Start Debugging] を選択して [Diagnostic Tools] ウィンドウと IntelliTrace (既定でデバッグ セッションの開始時に毎回表示される) を初期化する場合のコストを最適化しました。IntelliTrace の初期化方法が変更され、デバッガーの他の処理やアプリケーションの起動と並列して初期化できるようになりました。また、ブレークポイントで停止した場合の IntelliTrace ロガーと Visual Studio プロセスの通信方法も効率化されました。

このほか、[Diagnostic Tools] ウィンドウに関連するバッググラウンド スレッドが Visual Studio のメイン UI スレッドのコードを同期的に実行する必要があった箇所も修正しました。これにより、ETW イベント コレクション内の非同期イベントの割合が増加し、デバッグ セッションを再開する場合に ETW セッションが終了するまで待機する必要がなくなりました。

Git.exe によるソース コードの操作の高速化

Visual Studio に Git のサポートが追加された時点では、libgit2 というライブラリが使用されていました。しかし、libgit2 とコマンド プロンプトから使用する git.exe は機能が異なるほか、libgit2 を使用すると Visual Studio のメイン プロセスに対して数百 MB のメモリ負荷が発生するという問題がありました。

Preview 5 では、この libgit2 の実装を廃止して、代わりに git.exe をプロセス外から呼び出すようにしました。そのため、Git がマシン上のメモリを消費することには変わりないものの、VS のメイン プロセスに対してメモリ負荷は発生することはなくなりました。また、git.exe を使用することで Git 操作が段階的に高速化することも期待されます。現時点では、大規模なリポジトリに対して git clone コマンドを実行した場合に処理が高速化したことを確認しています。テスト用マシンで Roslyn .NET Compiler リポジトリのクローンを作成したところ、Visual Studio 2015 では 5 分 40 秒かかったのに対し、Visual Studio “15” では所要時間が 4 分と、30% の短縮になりました。以下の動画はそのようすを示したものです (4 倍速で再生しています)。

今後のリリースでは、この新しいアーキテクチャによって他の操作も高速化される予定です。

また、Git の使用について特に多くのご不満が寄せられていたのが、コマンド ラインからブランチを切り替えた場合に Visual Studio がソリューション内のすべてのプロジェクトを 1 つずつ読み込み直すという問題です。この問題も修正され、ファイル変更の通知ダイアログの [Reload All] が [Reload Solution] に変更されました。

これにより、ソリューションの再読み込みが非同期で 1 回のみ実行され、個々のプロジェクトを再読み込みする場合よりもはるかに短時間で処理が終了します。

XAML のタブ切り替えの高速化

データやお客様からのフィードバックによると、開発者の 25% が 1 日に 1 回以上は XAML のタブを切り替えるときに 1 秒以上の遅延を経験しています。さらなる調査の結果、この遅延はマークアップ コンパイラが原因であることが判明しました。そこで、XAML 言語サービスを利用することで、タブの切り替えを大幅に高速化しました。以下の動画で、この機能強化の成果をご確認ください。

マークアップ コンパイラは各 XAML ファイルの g.i.* ファイルを作成します。このファイルには XAML ファイル内の名前を持つ要素を表すフィールドが含まれていて、名前を持つ要素をコードビハインドから参照する場合に使用できます。たとえば、<Button x:Name=”myButton” /> という要素が存在する場合、g.i.* ファイルには Button 型の名前を持つボタンのフィールドが含まれ、コード内で “myButton” を使用することができます。

XAML ファイルを保存したり、保存されていない XAML ファイルから他のファイルに切り替えたりすると、分離コード ファイルを開いた場合に IntelliSense が最新の名前を持つ要素を表示できるように、Visual Studio がこの g.i.* ファイルを更新します。従来のリリースでは、この g.i.* ファイルの更新は毎回マークアップ コンパイラが実行していました。マネージ プロジェクト (C#/VB) では、マークアップ コンパイラが UI スレッドで実行されていたため、複雑なプロジェクトでタブを切り替えると目に見える遅延が発生していました。

Preview 5 ではこの問題が修正され、XAML 言語サービスが保持している XAML ファイルの情報を利用して IntelliSense に表示するフィールドの名前と型を判別してから、バックグラウンド スレッドで Roslyn を使用して g.i.* ファイルを更新するようになりました。言語サービスでは、コンパイラの速度低下の原因となる解析や型メタデータの読み込みをすべて完了しているため、マークアップ コンパイラを実行する場合よりもはるかに高速です。ただし、g.i.* ファイルが存在しない場合 (XAML ファイルの名前を変更した場合やプロジェクトの obj ディレクトリを削除した場合) は、マークアップ コンパイラを実行して g.i.* ファイルを最初から生成し直す必要があるため、これまでと同様に遅延が発生します。

XAML の入力エクスペリエンスの応答性向上

XAML 言語サービスで UI の遅延が発生する主な原因は、初期化、メタデータの変更への対応、デザイン アセンブリの読み込みです。今回のバージョンでは、処理をバックグラウンド スレッドに移動することで、これら 3 つの原因をすべて解消しました。

デザイン アセンブリ メタデータの読み込みについては、下記の機能強化も実施されました。

  • デザイン アセンブリ メタデータのシリアル化層が新たに追加され、境界を越える呼び出しが大幅に減少しました。
  • WPF プロジェクトでデザイナーのアセンブリ シャドウ キャッシュが再利用されるようになりました。また、すべての種類のプロジェクトでシャドウ キャッシュがセッション間で再利用されるようになりました。従来、これらのシャドウ キャッシュはメタデータが変更されるたびに作成し直されていました。
  • メタデータが変更されるたびに再計算されていたデザイン アセンブリ メタデータが、セッション期間中はキャッシュされるようになりました。

これらの変更により、ソリューションの読み込みが完全に完了する前に XAML の IntelliSense を使用できるようになりました。

入力時の応答性低下の原因となっている拡張機能の特定

入力時の応答性低下については、多数のご報告をいただいています。現在これらの不具合の修正を進めていますが、この応答性低下の原因の大半はキーボードの操作中にコードを実行する拡張機能です。このような原因を確認できるように、[Help]、[Manage Visual Studio Performance] からレポートにアクセスできるようになったほか、入力エクスペリエンスに影響を与えている拡張機能を通知する機能が追加されました。

入力の応答性低下の原因となっている拡張機能の通知

[Help]、[Manage Visual Studio Performance] の順に選択すると拡張機能の詳細が表示されます。

試用と問題のご報告のお願い

今回の記事では Preview 5 に実装された機能強化の一部をご紹介しました。マイクロソフトは、今後も Visual Studio の応答性の向上に向けた取り組みを継続してまいります。皆様が最も必要とする機能に重点的に取り組むことができるように、ぜひ Visual Studio “15” Preview 5 をダウンロードしてご試用いただき、[Report-a-Problem] ツール (英語) から機能強化に関するご提案をお寄せください。

Dan Taylor (シニア プログラム マネージャー)

Dan Taylor は、5 年前にマイクロソフトに入社して以来、.NET と Visual Studio のパフォーマンス強化に取り組んでいるほか、Visual Studio と Azure のプロファイリングおよび診断ツールを担当しています。

 


JavaScript を使用する iOS 開発者や Android 開発者に向けた新機能

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 Whats’s new for iOS and Android developers using JavaScript? 2016/11/17

 

今週発表された Visual Studio 2017 RC には、Visual Studio Tools for Apache Cordova (TACO、英語) の最新リリースが含まれています。このリリースにあたって、マイクロソフトではモバイル開発者の皆様が日々直面している大きな課題に取り組みました。その取り組みは、主に次の 2 つのテーマに分けられます。

  1. 高速かつ信頼性の高いビルド: Visual Studio の新しいインストーラーでは、サードパーティ製コンポーネントの十分に検証されたツールチェーンのオフライン インストールを組み合わせることで、より高速なビルドが実現されています。これにより、トラブルシューティングや修復もさらに容易になります。
  2. 編集とデバッグの大幅な高速化: 新しいブラウザー ベースのシミュレーターでは、コードをすばやく実行してブラウザー内で即座に結果を確認できます。ライブ リロード、プラグイン シミュレーション、Ionic Framework のサポートにより、Visual Studio に市場最速の開発者ワークフローが実現されています。

高速かつ信頼性の高いビルド

Cordova 開発者の方々とお話ししたところ、現時点で最も一般的な問題となっているのは環境のセットアップとアプリケーションの構築に関連するものでした。これは当然のことでしょう。たとえば、ネイティブなターゲット プラットフォームの SDK を使用してネイティブなアプリケーションを構築するというように、構築こそが Cordova のすべてであるからです。マイクロソフトの調査によると、TACO を使用している開発者の 26% は、主に NPM とネットワーク ファイアウォールでの問題により初回のビルドでエラーを経験しています。今回のリリースでは、この問題の解決に取り組みました。

高速なインストールと確実な動作

Visual Studio の新しいインストーラーでは、迅速にインストールが完了し「確実に動作」する Mobile development with JavaScript ワークロードが追加されています。

このワークロードはツールチェーンの依存関係の総数が削減され、テストが強化されています。十分に検証された新しい「ツールセット」を使用することで、モバイル開発者は Cordova などのオープン ソース パッケージを含め、プレリリース版の開発作業に必要なすべてのコンポーネントを入手できます。オフライン インストールが必要な方にもご利用いただけます。初期テストでは、ほとんどの場合「ダウンロード」してから「コードの作成」を開始するまでの所要時間は 15 分以内でした。

アプリケーションの開発をプロトタイプから製品版へと進めていくと、不足している依存関係をインストールするように促すダイアログが Visual Studio で表示されるようになります。たとえば、あるデバイスにデプロイするときに Android SDK が不足している場合、これをインストールするように促されます。便利だと思いませんか。シンプルなツールチェーンで開発を始め、アプリケーションが拡張し必要なツールチェーンが複雑になるにつれて徐々にインストールを進めていくことができます。

ツールセット

インストールの合理化のほかに、さまざまな環境でのビルドの信頼性向上にも重点的に取り組みました。ビルドに関してご報告いただいている問題のほとんどには、NPM のエラー、ネットワークのファイアウォール、ローカル ツールチェーンの互換性不足が複合的に関連しています。このような問題に対処し、正しい状態を維持するために、TACO では「ツールセット」という概念が新たに導入されました。このツールセットは Visual Studio で使用される検証済みの一連のツールを 1 つのパッケージにまとめたものです。たとえば、既定の Cordova 6.3.1 ツールセットには Cordova 6.3.1、Node 4.4.3、NPM 2.15.0 が含まれており、コンピューターにその他のものがインストールされていても、TACO でアプリケーションを作成する際にはサンドボックス化されたツールセットが使用されます。ツールの組み合わせが既知のものであるため、開発者の期待どおりに動作するアプリケーションを作成できます。細かくカスタマイズしたい場合は、任意のツールチェーンの依存関係のグローバル インスタンスを使用することもできるため、全体を完全に管理できます。

プロジェクトで使用するツールセットを構成するには、config.xml を開いてエディターの [Toolset] セクションに移動します。ツールセットの構築、保守、配布はマイクロソフトが行います。iOS、Android、Windows の新しいバージョンのリリース後すぐにマイクロソフトが新しいツールセットをリリースしますので、Visual Studio の更新を頻繁にご確認ください。

ビルド エラーの把握が容易に

ビルド エラーが発生したときのトラブルシューティングを容易にするために、小規模ながらも重要な変更が行われ、ビルド出力を容易に確認できるようになりました。ビルド出力画面のエラーの表示が色付けされて見やすくなっています。また、処理のステップを区切るためのヘッダーがビルド出力に追加され、ビルド処理のどこでエラーが発生したかを特定しやすくなっています。

この機能は便利であると同時に、楽しいアスキー アートも含まれています。

編集とデバッグを大幅に高速化

今回のリリースでは、Visual Studio Code の Cordova Tools 拡張機能の中から、広く使用されている Cordova Simulate が導入されています。TACO をある程度使用したことがある開発者にとっては、モバイル アプリのブラウザー内シミュレーションとしてこれまで使用されてきた Ripple エミュレーターに代わる存在となります。Cordova Simulate が提供するローカルで実行可能な高速のブラウザー ベース ワークフローは、最新の Web 開発での利用に適しており、エミュレーターやデバイスを使用せずにほぼすべてのモバイル開発を可能にします。

Cordova Simulate では、Ripple と同様に下記に対応しています。

  • さまざまなサイズのデバイスをテスト
  • 地理位置情報、コンパス、加速度センサーを設定してシミュレート
  • 画像、スタイルシート、JavaScript、HTML をライブでリロード
  • DOM エクスプローラーや JavaScript デバッガーなどのブラウザー ベースの開発ツールを Visual Studio 内で使用

また、Ripple にはない機能もあります。

  • カメラ、連絡先、ファイル、メディアなど、より多くのプラグインをシミュレート (詳細はこちらのドキュメント (英語) を参照)
  • iframe ではなく専用のブラウザー ウィンドウでアプリをシミュレート
  • カスタム プラグインや一般的でないプラグインの API 応答を保存

この新ツールの詳細については、後日このブログで詳細記事を公開する予定です。どうぞご期待ください。

Visual Studio 2017 RC を使用してご意見をお寄せください

今回ご紹介した機能以外にも、不具合を数多く修正したほか、ビルド プロセスを作り直して安定性の向上とビルド時間の短縮を実現しています。モバイル アプリの構築に Cordova を試してみたいと思っている方は、ぜひ今回のリリース (英語) をお試しになりご意見をお寄せください。

ツールをご利用いただいてお気づきになった点は、メールで直接お送りいただくか、Stack Overflow (英語)Twitter までお寄せください。また、ドキュメントに関するご意見はドキュメント サイト (英語) まで直接お寄せください。

今後のプレリリース版ソフトウェアに関する最新情報をご希望の方は、TACO insiders (英語) にご参加ください。皆様のご協力をお待ちしております。

Jordan Matthiesen (@JMatthiesen)
JavaScript モバイル開発者ツール担当プログラム マネージャー
Jordan Matthiesen はマイクロソフトで Web アプリケーションおよびモバイル アプリケーション開発者向けの JavaScript ツールを担当しています。それ以前にも 18 年以上の開発経験があり、現在は優秀なモバイル開発者からできるだけ多くの意見を取り入れることに力を入れています。プライベートでは、妻と 4 人の子ども、2 匹の猫、1 匹の犬と共にコーヒーを飲みながらゆっくり過ごす時間を大切にしています。

 

Visual Studio 2017 RC のデータ サイエンス ワークロード

$
0
0

 

本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。
【元記事】 The Data Science Workloads in Visual Studio 2017 RC 2016/11/18

 

Facebook で写真に写っている人物が自動でタグ付けされたり、オンライン サイトでおすすめの商品が表示されたり、写真をキーワード検索できたり、クレジット カードの不正利用が警告されたりと、機械学習とデータ サイエンスは、私たちのごく身近に存在しています。

このたび、Visual Studio 2017 RC (英語) 向けのデータ ストレージデータ サイエンスの専用ワークロードがリリースされました。このワークロードには、次世代のインテリジェントなアプリやサービスの構築に必要なバックエンドやツールがすべて含まれています。

それぞれのワークロードについて詳しく見ていきましょう。

  1. データ ストレージとデータ処理: ビッグ データのストレージと高度な分析に使用します。
  1. データ サイエンス: 分析、モデルの構築、スマート アプリの作成に必要なツールがすべて含まれています。
  • Python Tools for Visual Studio: デスクトップ、Web、指数、データ サイエンス/機械学習
  • R Tools for Visual Studio: 主に統計とデータ サイエンス/機械学習
  • F#: さまざまなデータ処理タスクに適した関数主導型 .NET 言語

R と Python が使用される理由

既にサポートされている Python に加え、このたび Visual Studio で新たに R 言語がサポートされます。R はデータ サイエンスや統計に特化した言語で、豊富なパッケージが使用可能な形で提供されています。

世間では人気の言語がランキング形式で紹介されているのをよく見かけ、信憑性には疑問が残りますが、分析分野で R と Python が欠かせないという点は間違いないようです。

マイクロソフトでは、ほぼすべてのストレージ テクノロジや分析テクノロジで既に R と Python をサポートしているか (直接または SDK 経由)、近くサポートが予定されています。次に個々のツールについて説明します。

Python Tools for Visual Studio

VS 2017 RC は Python (英語) と高度に統合されており、機械学習からデスクトップ、IoT、Web までさまざまな用途に対応しています。CPython (2.x および 3.x)、IronPython、Jython、PyPy などのほとんどのインタープリターや Anaconda ディストリビューション (英語) に対応し、また PyPI (英語) で公開されている膨大な数のパッケージにアクセス可能です。Python の新機能の詳細は、製品リリース ノートに記載されています。

R Tools for Visual Studio (RTVS)

RTVS は VS を強力な R IDE (英語) に変えるツールで、IntelliSense やデバッグ、REPL、履歴などの基本機能に加えて、SQL データベースで実行されている R のストアド プロシージャや複数の独立プロット、リモート処理などの高度な機能にも対応しています。リモート処理では、ターミナル サーバーを使用した場合と同様にリモート マシンで RTVS のすべての機能を利用できます。このため、データの一部をノート PC のローカルで使用し、後に大規模なサーバーに接続して完全版の IDE にて作業を続け、最後にコードをデプロイする場合などに非常に便利です。

Visual Studio では、標準的な CRAN R (英語) バージョンと、パフォーマンスや企業向け機能が強化されたバージョンの Microsoft R の両方に対応しています。

F#

F# (英語) は、従来のオブジェクト指向型や命令形 (手続き型) プログラミングに加えて関数型プログラミングにも対応した言語です。データ処理に適しており、データのアクセス、操作、処理に関するサードパーティのエコシステムも充実しています。Visual Studio の Visual F# ツールは、F# アプリケーションの開発、および F# コードによるその他の .NET アプリケーションの拡張をサポートしています。F# は .NET で頻繁に使用され、機械学習での種関数型言語に非常によく似ています。

専用パッケージをご用意

データ サイエンス ワークロードは、Visual Studio への統合に加えて数百種類のパッケージがプレインストールされており、画像処理 (英語)生物情報学 (英語)天文学 (英語) などの高度な分析にも対応しています。データ サイエンス ワークロードには、既定で下記の機能が含まれています。

  • Microsoft R Client (英語): マイクロソフトが提供する強化版の R で、マルチコア、パッケージのバージョン管理、分散型メモリをサポートしています。
  • Anaconda Python ディストリビューション (英語): Continuum.io が監修するクロス プラットフォーム Python パッケージ コレクションで、機械学習、指数計算、Web などのシナリオに対応しています。

Python 用 Azure SDK

Azure SDK では、Python を含むすべてのサービスと言語をサポートしています。Python 用 Azure SDK (英語) では、コンピューティングやストレージ、ネットワーク、Key Vault、監視サービスなどの中核機能を .NET と同等に完全にサポートしています。Data Lake Store、Data Lake Analytics、SQL Database、DocumentDB などのサービスの管理に加え、SQL Database や SQL Server、DocumentDB、Data Lake Store File System などの各種データベースをサポートしています。

開発にご協力ください (オンラインで OK)!

ツールからライブラリに至るまで、データ サイエンス一式はすべてオープン ソースで、GitHub でホストされています。ぜひコード ベースをご覧いただき、フォークの作成や不具合の報告、さらには新機能の追加などにご協力いただけますと幸いです。各リポジトリは下記からアクセスできます。

無料のインタラクティブな Python 用および R 用ノートブック

Visual Studio は非常に生産的なデスクトップ IDE ですが、ブラウザーの中で直接データの分析とプロットを行いその結果を共有するなど、「強力な REPL」程度の機能だけが必要な場合があります。

Azure ではJupyter (英語) でホストされているノートブックを無料で提供しています。

Jupyter とはコードが実行できる OneNote のようなもので、テキスト (マークダウン言語)、コード、インライン グラフィックなどに対応しています。現時点では R、Python 2、Python 3 (Anaconda ディストリビューション) の各言語に対応していて、F# も近いうちにサポートされる予定です。Azure Notebooks の詳細をご希望の方は、ぜひサンプルをご覧ください。

この無料サービスは、特に教職員や学生の皆様の利用やオンライン セミナー、製品デモ、リアルタイムなレポートの共有などに適しています。高品質なノートブックが多数公開されていますので、どうぞご覧ください (英語)

まとめ

データ サイエンスは、データからインテリジェントなアクションを導き出すことを可能にします。詳しくは Connect() のデータ サイエンスと Web 開発に関するビデオ (英語) でご覧いただけます。Visual Studio のデータ サイエンス ワークロードは、デスクトップ、クラウド、IoT、モバイルなどの環境を問わず、次世代のインテリジェントなアプリ構築のために必要なすべてを提供する初めての試みです。組み込み済みのライブラリやパッケージを確認し、ぜひお試しください。また、CRAN や PyPI についてもご意見をお聞かせいただけますと幸いです。

問題点がありましたら、インストーラーまたは Visual Studio IDE 本体の右上角の [Report a Problem (英語)] からご報告をお願いします。また、PTVS (英語)RTVS (英語) の GitHub リポジトリにも問題をご報告いただけます。このほか、ご提案がありましたら UserVoice (英語) までお寄せください。

Shahrokh Mortazavi (Visual Studio クラウド プラットフォーム ツール担当パートナー PM)

Shahrokh Mortazavi はマイクロソフトでデータ サイエンス用開発ツールのチームを担当しており、主に Python や R、Jupyter Notebooks を扱っています。以前は、マイクロソフトのハイ パフォーマンス コンピューティング グループに所属していました。Microsoft Research では Phoenix コンパイラ ツール チェーン (コード生成、分析、JIT) の経験があり、それ以前は Sun Microsystems のコード生成および最適化コンパイラ バックエンド チームでリーダーを 10 年以上務めていました。

 

Release Management の一般提供を開始

$
0
0

 

本記事は、マイクロソフト本社の Microsoft Application Lifecycle Management の記事を抄訳したものです。
【元記事】 Announcing general availability of Release Management 2016/11/16

 

このたび、Visual Studio Team Services の Release Management の一般提供が開始されました。Release Management は Team Foundation Server 2017 でも使用できます。

マイクロソフトは、Release Management のパブリック プレビューを開始して以来、継続的に新機能を追加 (英語) してきました。このサービスは非常に多くのお客様にご利用いただき、製品改良の参考となる貴重なご意見を多数いただいています。

Release Management は DevOps に不可欠な要素であり、高品質なソフトウェアを速いペースで継続的に提供するうえで重要です。Release Management では、開発環境、テスト環境、ステージング環境、運用環境といった複数の環境へのアプリケーションのデプロイやテストを自動化することが可能で、あらゆるアプリケーション プラットフォームにデプロイし、オンプレミスまたはクラウドをターゲットにすることができます。

Continuous delivery Automation flow

Release Management はクロス プラットフォーム対応で、Java から ASP.Net や Node.js まで、さまざまな種類のアプリケーションをサポートします。また、各種 ALM ツールとの統合やリリース プロセスのカスタマイズも可能です。たとえば、Release Management を Jenkins や TeamCity のビルドと統合したり、GitHub から入手した Node.js のソースをアーティファクトとして直接デプロイしたりできます。また、あらかじめ用意された自動化タスクを使用するか、ニーズに応じてカスタムの自動化タスクや拡張機能を作成して、デプロイメントをカスタマイズすることもできます。

自動デプロイメント

Visual Studio Release Management では、複数の環境にわたるリリース パイプラインを設計、自動化し、任意のプラットフォームやアプリケーションをターゲットにすることができます。リリースのタイミングは、ビルドの用意ができた時点で実行することも、スケジュールを設定することもできます。パイプラインの自動化により、市場投入までの期間を短縮できるほか、ユーザーからのフィードバックにも迅速に対応できます。

release-summary

承認ワークフローの手動または自動承認

開発/テスト環境では承認を完全に自動化し、運用環境では承認を手動で行うといったように、デプロイメントを事前に承認するか、後から承認するかを容易に構成できます。承認は自動で通知されるため、チーム メンバー全員がリリース状況を把握し、共同作業を行うことができます。また、リリースや承認の監査にも完全に対応しています。

RM approvals

リリースごとに品質を向上

リリースにはテストが不可欠です。リリース時の信頼性を向上するために、確認が必要なすべての項目に関して、パフォーマンス テスト、A/B テスト、機能テスト、セキュリティ テスト、ベータ テストなどのテスト タスクを構成できます。[Manual Intervention] を選択すると、自動化されたフローを追跡し、手動でテストを実施することもできます。

Release Quality

Azure へのデプロイが容易

Release Management では、Azure へのデプロイに関して、組み込みのタスクと簡単な設定により、リリースを非常に容易に構成できます。Azure Web Apps、Docker コンテナー、Virtual Machines などにデプロイできるほか、VMware、System Center Virtual Machine Manager、その他の仮想化プラットフォームで管理されているサーバーなど、幅広いターゲットにデプロイできます。

エンドツーエンドで追跡

リリースにおいて追跡可能性は非常に重要です。各環境のコミットや作業項目など、リリースやデプロイメントの状態を追跡することができます。

詳細については、Release Management (英語) のドキュメントを参照してください。

Visual Studio Team Services で Release Management を試用する場合はこちらのページ (英語) にアクセスしてください。

ご不明な点やご意見、フィードバックがありましたら、Gopinath.ch (アットマーク) microsoft (ドット) com までご連絡ください。

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

Gopinath

Release Management チーム

Twitter: @gopinach

Package Management の一般提供を開始: NuGet、npm などのサポート

$
0
0

 

本記事は、マイクロソフト本社の Microsoft Application Lifecycle Management の記事を抄訳したものです。
【元記事】 Package Management is generally available: NuGet, npm, and more 2016/11/16

 

このたび、Team Services と TFS 2017 で Package Management の一般提供が開始されました。まだご利用でない方は、ぜひ Visual Studio Marketplace (英語) からインストールしてください。

業界最高レベルの NuGet 3 のサポート

Package Management で NuGet がサポートされたことにより、パッケージをホストし、チーム、ビルド、リリースで利用できるようにして、継続的デリバリー ワークフローを実現できます。Package Management では最新の NuGet 3.x クライアントが業界最高レベルでサポートされているため、.NET エコシステムに容易に追加できます。NuGet.Server のプライベート コピーをホストしている場合やパッケージをファイル共有で管理している場合、Package Management を使用するとこのような手間をなくすことが可能で、移行時にも役立ちます (英語)

Package Management で NuGet の使用を開始する方法については、こちらのドキュメント (英語) を参照してください。

Package Management で npm を使用

Package Management チームでは、NuGet だけでなく、npm パッケージ (英語) のサポートにもこの数か月間、重点的に取り組んできました。開発に Node.js や JavaScript、その派生言語を使用している場合は、Team Services を使用して、プライベートの npm パッケージと NuGet パッケージの両方をホストできます。

npm は、Package Management ライセンスを持つすべての Team Services ユーザーにご利用いただけます。npm の利用を開始するには、Marketplace から Package Management (英語) をインストールし、こちらのドキュメント (英語) をご確認ください。

TFS 2017 Update 1 でも npm がサポートされます。最新情報については、開発タイムライン (英語) をご覧ください。

npm in Package Management

一般提供時の変更点: 料金、リージョンなど

プレビュー期間中に Package Management を利用していた場合、引き続き利用するには Marketplace でライセンスをご購入 (英語) いただく必要があります。ご利用中のアカウントは自動的に 60 日間の試用版に移行されます。Package Management ハブの通知バーを確認するか、アカウントの [Users] ハブに直接アクセスしてライセンスを購入してください。

Package Management の料金は次のとおりです。

  • 5 ユーザーまで: 無料 (この場合も、Marketplace (英語) でユーザーのライセンスを取得する必要があります)
  • 6 ~ 100 ユーザー: 1 人あたり 4 ドル
  • 101 ~ 1000 ユーザー: 1 人あたり 1.50 ドル
  • 1001 ユーザー以上: 1 人あたり 0.50 ドル

Package Management 拡張機能は次の Visual Studio サブスクリプションにも含まれています。

  • Visual Studio Enterprise の月間サブスクリプション
  • Visual Studio Enterprise の年間サブスクリプション
  • Visual Studio Enterprise with MSDN

詳細については、料金計算ツールでご確認ください。Package Management 拡張機能は Visual Studio Team Services のユーザー (利害関係者は含まれません) にのみ割り当てることができます。

最後に、Package Management の提供がインド南部とブラジル南部の各リージョンでも開始されたことをお知らせします。

次のステップ

TFS 2017 の Package Management をリリースしたことで、チームは拡張機能の付加価値の提供に専念できるようになりました。今後 1 年間、主に下記の分野に重点的に取り組む予定です。

  • パッケージのライフサイクル: Package Management は、ファイル リポジトリとしてのみでなく、コンポーネントの生成およびリリース管理サービスとしても利用できるようにしたいと考えています。そのため、バージョン管理やパッケージの生成に関するメタデータの強化など、Team Build や Release Management とパッケージを緊密に統合する機能への取り組みを継続します。
  • 依存関係の管理: パッケージは、NuGet.org、社内のチーム、グループ内のチームなど、さまざまな場所で作成されます。リリースまでの期間を短縮し、イノベーションを加速させることが常に求められる状況にあっては、コードを可能な限り再利用することが重要となります。このような再利用を可能にするために、依存関係の場所、ライセンス方法、安全性などの把握に役立つツールの開発に取り組んでいます。
  • エクスペリエンスの刷新: 昨年 11 月に Package Management をリリースした際には、サポートされるいくつかのシナリオに適したシンプルなユーザー エクスペリエンスが提供されました。しかし、これらの新しい取り組みによってサービスを拡大するにあたり、拡張されたユーザー エクスペリエンスに移行します。これにより、Team Services の他の機能との一貫性が向上するほか、パートナーが独自のデータや機能によって Package Management を拡張できるようになり、マイクロソフトによる今後のサービス拡大にも対応します。
  • Maven/Ivy: 製品の他の機能による Java エコシステムのサポートがこれまで以上に強化される中で、Package Management は Java 開発者が最もよく使用するパッケージのリポジトリになることが求められています。そこで、Package Management フィードに Maven パッケージのサポートを追加する予定です。

WinAppDriver: Selenium に似た Appium のテストを使用して、Windows であらゆるアプリのテストを実行

$
0
0

 

本記事は、マイクロソフト本社の SCOTT HANSELMAN の記事を抄訳したものです。
【元記事】 WinAppDriver – Test any app with Appium’s Selenium-like tests on Windows 2016/11/16

 

WinAppDriver - Appium testing Windows Apps

過去のブログ記事をさかのぼってみたところ、私は 2007 年から Selenium の Web テスト フレームワークを使用していました (英語)。現在では、Microsoft Edge を含む各種 Web ブラウザー向け (英語) の Selenium ドライバーが提供されており、Ruby、Python、Java、C# など、現在使用されているほぼすべての言語 (英語) で Selenium テストを作成することができます。

私は Selenium (英語) を愛用しており、BrowserStack などのシステムと併用 (英語) して、各種 OS でさまざまなブラウザーのテストを自動化しています。

“Appium” は Selenium 風の優れたテスト フレームワークで、以前の JsonWireProtocol に相当する “WebDriver (英語)” プロトコルが実装されています。

WebDriver は、ユーザー エージェントの問題検出や制御に使用するリモート コントロール インターフェイスで、プラットフォームや言語に依存しないワイヤ プロトコルにより、プロセス外のプログラムから Web ブラウザーの動作をリモートで指示することができます。

Appium の Web サイト (英語) では、「Appium は “クロス プラットフォーム” に対応しており、単一の API を使用して、複数のプラットフォーム (iOS/Android/Windows) に対するテストを作成できます。このため、iOS、Android、Windows のテスト スイート間でコードを再利用できます」と紹介されています。

Appium (英語) は Web サーバーとして機能し、REST API が公開されています。WinAppDriver (英語) では Appium を利用するために、Windows 10 Anniversary Edition で追加された新しい API を使用し、あらゆる Windows アプリのテストを実行することができます。「あらゆる Windows アプリ」とは、Win32、VB6、WPF、UWP など、文字どおりすべてのアプリを指します。あらゆるアプリを Windows ストアで公開できるだけでなく、私のような Web 開発者が使い慣れたツールを使用して、これらのアプリの完全な UI テストを実行できます。

Your preferred language, your preferred test runner, the Appium Server, and your app

テストは C# で作成し、Visual Studio テスト ランナーから実行することができます。任意のボタンを押すと、アプリをほぼ完全に制御できます。

// 電卓アプリを起動
DesiredCapabilities appCapabilities = new DesiredCapabilities();
appCapabilities.SetCapability("app", "Microsoft.WindowsCalculator_8wekyb3d8bbwe!App");
CalculatorSession = new RemoteWebDriver(new Uri(WindowsApplicationDriverUrl), appCapabilities);
Assert.IsNotNull(CalculatorSession);
CalculatorSession.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(2));
// 標準モードであることを確認
CalculatorSession.FindElementByXPath("//Button[starts-with(@Name, \"Menu\")]").Click();
OriginalCalculatorMode = CalculatorSession.FindElementByXPath("//List[@AutomationId=\"FlyoutNav\"]//ListItem[@IsSelected=\"True\"]").Text;
CalculatorSession.FindElementByXPath("//ListItem[@Name=\"Standard Calculator\"]").Click();

実際に使用を開始してみると、意外なほど簡単です。

public void Addition()
{
CalculatorSession.FindElementByName("One").Click();
CalculatorSession.FindElementByName("Plus").Click();
CalculatorSession.FindElementByName("Seven").Click();
CalculatorSession.FindElementByName("Equals").Click();
Assert.AreEqual("Display is  8 ", CalculatorResult.Text);
}

スタート メニューや Cortana を含め、Windows のあらゆる機能を自動化できます。

var searchBox = CortanaSession.FindElementByAccessibilityId("SearchTextBox");
Assert.IsNotNull(searchBox);
searchBox.SendKeys("What is eight times eleven");
 
var bingPane = CortanaSession.FindElementByName("Bing");
Assert.IsNotNull(bingPane);
 
var bingResult = bingPane.FindElementByName("88");
Assert.IsNotNull(bingResult);

“AccessibiltyIds” を使用し、ロケール固有ではない方法によってネイティブ コントロールを参照する場合は、プラットフォーム間でテスト コードを再利用することもできます。たとえば、Windows、iOS、Web アプリ、さらには VB6 Win32 アプリで共通のサインイン用コードを作成できます。 😉

Testing a VB6 app with WinAppDriver

Appium と WebAppDriver は、”コード化された UI テスト” の代わりに使用できます。コード化された UI テストは優れたテストですが、Windows アプリ専用です。Web 開発者またはクロス プラットフォーム アプリやモバイル アプリの開発者の皆様はぜひお試しください。


広告: 共有可能な優れた SQL を迅速に作成 (英語)SQL Prompt の無料試用版を使用して、チーム全体が共有可能な優れた SQL を迅速に作成する方法をご紹介しています。SQL を簡単に作成、リファクタリング、共有できます。ぜひお試しください (英語)

筆者紹介

Scott Hanselman は、大学教授と金融会社のチーフ アーキテクトという職歴を経て、現在はマイクロソフトに勤務する傍ら、講演やコンサルティング活動を行っています。父親であり、糖尿病患者であるほか、漫才師のなり損ない、コーンロー ヘアーのスタイリスト、著者という肩書きも持っています。
Viewing all 182 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>