Visual Studio 20周年ポエム

blogs.msdn.microsoft.com

Visual Studio 2017のRTMが3/7に決まりました。Visual Studio 97以来、Visual Studioブランドでは20周年だそうです。もちろんぽっと出たわけではなくて、それ以前の歴史もあります。

単独製品時代

以前はFORTRAN, Assembler, C, BASIC, Quick BASIC, Quick Cなどと言語別にブランド化されていました。Quickシリーズは日本語化されなかったので、知らない人も多いでしょうが、Windows 3.1上でIDEを実装して、高速なコンパイル(最適化はほどほど)を売りにしていました。英語製品でしたが、日本MSさんから販売されていました。

実際、Quick-CはMS-Cと比べてコンパイル速度がかなり早く、5倍以上は早かったんじゃないかな？Windows上で動くIDEということで、もちろんデバッガも内蔵。MS-CのデバッガであるCodeViewはDOS-BOXの互換性にかなり依存しており、IBM-PC/AT互換機のWindows 3.1じゃないといまいちうまく動きませんでした。

当時はPC-98もかなり勢力を占めていたので、Quickシリーズのデバッガにはかなり助けられました。

MSのアセンブラとか、言語製品は単独で9万とかしてたんですよ…。ちなみにMS-Cは外部の製品を買収してMSブランドが付けられています。6.0くらいから買収したときの色がなくなったように思います。高かったこともあって、私はほとんど使っていません。

Visual シリーズ

Quickシリーズがそれなりに成功したので、Visualシリーズが出てきます。Visual C++ 1.0。パッケージでかかったですね。Windows SDKと合わせて幅1m弱あったんじゃなかったかな？当時マニュアル含めて全訳されていて、Windows SDK, Oracleマニュアルなどで本棚が埋まるという。

デバッガもWindows仕様になり、大変便利でした。Visual C++ 1.5ってのも出ましたが、こちらは英語のみでした。確か日本語化されなかったWindows for Workgroups対応だったからじゃなかったっけ？一部用途で必要だったので、英語版も使っていました。

Visual BASICも並行して発売され、OCXのもとになるコントロールぽとぺたはサンデープログラマ、プログラムを専門としない人に大変良かったですね。

Visual Studioシリーズ

いろいろ統合されていたほうがいいよね、という話かどうか知りませんが、Visual Studio 97がリリースされました。これも使ったはずなんですが、あまり印象がないなぁ。

後で思い出したけど、Visual InterDevというものがつきました。これは初めてインタラクティブなWebサイトをつくるIDEでしたね。

Visual Studio Web Site

Visual J++もあったのか。Java関係で裁判にまでなった製品でしたが、当時のSunのJVMと違って起動が早くCOMにもアクセスできることもあって一部では使われていたようです。

Visual Studio 6.0

これは大ブレイクしましたね。いまだに…使っている人も多いのかもしれません。IIS 4.0,モデラー、BackOffice Serverなどがついて、サーバー機能も開発しやすくなりました。Visual StudioのIDEでWebサーバやデータベースの設定をGUIで行いデプロイするという仕組みがあったりしました。一回で終わりましたがｗ。

www.microsoft.com

Visual Studio 2002

.NET 1.0が初めてリリースされたバージョンですね。C#も日本で若干盛り上がりつつありました。当時はMLでしたけど、いまでも使われている方の多くが参加されていました。私自身はほとんど2002を使っていませんでした。

Visual Studio 2003

.NET 1.1と一緒にリリースされました。1.0は出しただけで、1.1が本番、という感じでしたが、この1.1で…特にASP.NET 1.1大変苦労された方から10年後、あの時めっちゃ苦労した、いまだに恨んでるみたいな話を聞いたときはびっくりしました。ちなみにそのあと改善された話がほとんどで、情報のキャッチアップしてない人ってこんなもんなんだな、と認識を新たにしました。

Visual Studio 2005

IDEが刷新されました。しかし、代わりに安定性にかけるところがあって、結構苦労しましたね。.NETが2.0になっていろいろ改善されて実用的になってきた感じがあります。

このころ、MSDN Offlineという今の無償セミナーの走りみたいなものが始まりました。

MSDN オフラインセミナー 〜開発者のためのスクール形式無償セミナー

第一回か第二回が C# のAnders Hejlsbergで、次期 C# および、Visual Studio 2008に含まれるLINQのプロトタイプ版を見せてもらいました。この時はまだ型定義をあらかじめ作っておくというものでした。

そして、Team Foundation Serverが初めて登場。このころのセットアップはほんとに大変でした…でも結構便利だなと思って使い始めたものです。

Visual Studio 2008

LINQが入り、IDEも結構安定してきました。WPF/WCF/WFも入りましたね。どれも壮大すぎて、気軽に使うというものではなくなったような気もしますが、WPFはがんばれ。

Visual Studio 2005, 2008もSQL Serverと一緒に遅れがすごいことになり、開発モデルの変更を余儀なくされた感じですね。

Visual Studio 2010

IDEがWPFベースになり、また安定性が(^^;。.NET Framework 4になり、いろいろ劇的に変わりました。CLRも劇的に変わって、ジェネリクスはほんとに助かりましたね。

Team Foundation Serverも大きく更新され、現在の基本となる機能はほとんど入ったはずです。Test Managerとかは便利です。

Visual Studio 2012

末尾に2とつくリリースは鬼門なんですかね？2002以来のポイントリリースって感じでした。IDEは少し良くなりました。.NET的には4.5がサポートされ、async/awaitが非常に便利でした。

Visual Studio 2013

ようやく実用期というリリースですね。

Visual Studio 2015

現行バージョンですね。.NET 4.6～4.6.2がリリースされて、.NET Core時代の幕開け…になりますかね？

In the Future

今や無償版にとどまらず、macOS用のVisual Studio for Mac, クロスプラットフォームのVisual Studio Codeまで出て、MS発のC#, VB以外にも多くの開発環境をサポートするIDEの基盤として、.NETおよび、Windows上の最良の環境としての発展を楽しみにしています！

(独り言).NET Core Toolsこれで安定するかな…

Visual Studio Team ServicesとChromeで未知のバグを発見する(15日目)

はじめに

テストケースだけでバグが検出できればいいのですが、そんな甘いものではなく、何気なく操作しているタイミングで出ることがよくあります。中には「神の手」を持つ方がいて、「この人が操作するときだけ起きる」というある意味素晴らしいバグハンターという方もいらっしゃいます。

特に開発時には無意識によけることもあり、こういうバグはテストケースでは救えません。どうするかといえば、「普段から記録しておけばいいんじゃね？」ということになります。

そういう操作を支援するのが「探索テスト(Exploratory testing)」機能です。ChromeのFeedback & test拡張機能および、Test Managerがサポートしています。

Chrome拡張機能

操作を記録する

Test & Feedback拡張機能を起動して、左端の△をクリックすると記録を開始します。

左端が赤枠の□になると記録開始です。以下の機能があります。

• テスト中(クリックすると停止)
• スクリーンショット
• メモ
• 動画
• VSTS/TFSにタスク/バグ/テストパターンを作成
• 操作タイムラインを見る
• Work Itemにリンクする
• デバイスに接続する
• 設定
• About画面

スクリーンショット＆メモ

画面に対するフィードバックをしたい場合、スクリーンショットを撮って、補足項目を文字入力します。

履歴

操作した履歴やスクリーンショットが確認できます。

作業項目と関連付け

特定の作業項目と関連付けておくことで、探索テストがどの作業に関連しているものかわかりやすくなります。

バグの作成

画面に問題があったので、バグとして登録します。Create bugで新しいバグとして登録します。特定の手順で再現することがわかるバグであれば、Create test caseで新しいテストケースを作れば今後再現テストに役立ちます。

バグ作成時、記録した操作及び、スクリーンショット、レスポンスの時間が全部記録されています(Chromeの機能でとっています)。

VSTSでのバグ確認

作成したバグはチームのバックログに登録されて、すぐに確認できます。

スクリーンショットが添付されているので、迷うことはありません。

添付されているhtmlにはChromeの開発者ツールで見える、応答状態もhtmlとして記録されています。

htmlをダウンロードして開くとこんな感じで確認できます。

Test Managerで探索テスト

Test Managerで起動する

Test Managerを使っても同様のことができます。こちらはどちらかといえばリッチクライアントアプリで探索テストするときに使うといいでしょう。あと、マイクも使えるので、音声で「どんな操作をした」という記録も採取できるのがいい点です。

探索テスト対象のビルドと環境に関連付けます。Test settingsやEnvironmentはSystem Center Virtual Machine Managerと連携した自動テストをするときに用意するので、ローカルテストの場合はデフォルトで構いません。

開始すると、このようなウィンドウが出てきます。タスクバーと同様のウィンドウ領域に影響するウィンドウなので(これは画像編集で小さくしています)、クライアントエリア全体＝フルスクリーンであると仮定するようなアプリはちょっと気を付けてください。

記録が終了するとこのように探索テストの結果が記録されます。

記録の日数について

Testの設定で保持日数の既定値が決まっています。長期間放置すると、VSTSが自動的に消してしまうので、注意しましょう。

まとめ

業務アプリであれば、普段から使って「あれここ変？」というような調査は難しいと思いますが、サービスや日常のアプリであれば、探索的テストを常時実行しておけば、ふとしたときでもバグが発生したときの操作記録が残るため、便利です。

特にChromeの拡張機能はとても便利ですね。VSTS/TFSにつながなくてもキャプチャや記録はとれるので、単独でも使いたい一品です。はやくEdgeやFirefoxにも(ry。

Visual Studio Team Servicesに接続して開発する(6日目)

ようやく今日からVisual Studioをつないで開発を行います。

Gitリポジトリ

まず、VSTSにGitリポジトリを作成してからVisual Studioで接続します。

初期化

最初はこのような画面が表示されます。既存のローカルリポジトリがあればそれをpushしてもいいですが、最初にVSTSで作ってからクライアントにcloneすれば.gitignoreの手間が省けます。

一番下にあるor initialize with a README or gitignoreにあるinitializeをクリックすれば指定したgitignore形式で作ります。

注意点として、C#やVB.NETという設定はなく、Visual Studioになっています。

cloneするためのツールも多く対応しています。.NET開発以外にもPhpStormやRubyMineとかにも対応しています。

(あまりないかもしれませんが)GitHubなどの外部リポジトリから引っ越すこともできます。Requires authorizationにチェックすると、非公開な認証が必要なリポジトリもインポートできます。

VSTS側で初期化した直後の状態です。.gitigonoreなどがあるので、このままクローンしてください。

リポジトリのメニューを開いて、リポジトリ名のそばにある☆をクリックすると、該当リポジトリがお気に入りとして扱われ、アクセスしやすくなります。ほかの人が作ったリポジトリに素早くアクセスする場合に使ってください。

一つのチームプロジェクトには複数(上限は非公表)のGitリポジトリを作ることができます。ビルドツールチェインはリポジトリ単位になるので、ある程度は分割したほうが便利でしょう。この辺はほかのGitサービスと考え方は変わらないはずです。

Gitセキュリティ設定

歯車アイコンから、Securityハブを使用して、チームプロジェクトにアクセスできるユーザーもしくはグループを設定します。コードの編集権を付けるにはContributorsグループに追加します。

チームプロジェクト内のリポジトリごとに設定することもできます。

特定のブランチ(通常masterやリリース用のブランチ)にむやみやたらにpushされて、ビルドが通らなくなるというのはよくあることです。

そのような事故を防ぐためにブランチ単位でブランチポリシーという機能を使って、レビューやCIおよび、テストが通っていないコミットを拒否することができます。

まだビルドがないので、上記の画面ではビルドの指定ができていません(^^;。Require a new build if older than xx hoursというのは、Gitでは細かい単位でコミットを行うこともあります。

単なるtypoやCSSの色修正でビルドやテストを全部やっていたら時間がいくらあっても足りません。そこで、直近xx時間以内のビルドは許容する、という指定です。開発が活発になって、しょっちゅうコミットするような状態になったら検討したほうがいいでしょう。

ブランチポリシーでレビュワーの指定ができます。この人(たち)がレビューしないとマージが行われません。

ブランチの…をクリックすると、既定ブランチにするか、ブランチを誤って削除できないようにします。devとかpull request作った後も残っていてほしいブランチは指定するといいでしょう。

ブランチと作業項目を関連付ける

ブランチはfeature,Backlog, Taskのいずれでも作成できます。機能レベルであれば、Backlogあたりで作るのがいいかもしれません。この辺りはいろいろ試行錯誤してルールを作ってみてください。タスクやissue単位でブランチを作るのもいいでしょう。

ブランチ名は / で区切ると階層になります。ここでは「チーム/backlog/id」というルールで切ってみました。こうするとブランチ名が何に関連づいているかわかりやすいでしょう。

タスクに着手したので、タスクをIn Progressに変更します。

Visual StudioからVSTSへ接続する

チームエクスプローラーから「接続の管理」を使用して「チームプロジェクトへ接続」をクリックします。なお、VSTSがサポートするVisual StudioはVS 2008 SP1 GDR1を適用したもの以降だそうです。

www.visualstudio.com

とはいえ、CIツールとして使う場合、Visual Studio 2013以降じゃないと、新しいビルドツールがサポートしていないとかいろいろ困ると思います。さらに、チームプロジェクトのリポジトリをGitで作った場合、サポートされるのはVisual Studio 2015 Update 1以降となっていますので、本当に使おうと思った場合、Visual Studio 2015 Update3を検討してください。

さて、接続しましょう。ここもTeam Foundation Serverと書いていますが、気にせず「追加」をクリックします。なお、Visual Studio 2017ではこのUIがまた少し変わっています。

接続するサーバーを追加するので「サーバー」をクリックします。

VSTSにつなぐ場合、アカウント名.visualstudio.comを指定して、OKをクリックします。

接続に使うアカウント名を選択します。

追加されましたので、「閉じる」をクリックします。

接続するチームプロジェクトを選択します。ちなみにVisual Studio 2017ではここでGitとTFVCの選択がやりやすくなっていますが、VS2015ではTFVCが優先されるようなUIです。

接続すると、複製(git clone)します。基本的に作成したリポジトリのクローンを先に行ってください。

複製先のフォルダを指定します。既定値はDocumentsフォルダのRepsの下に作成となっていますが、昨今のJavaScriptライブラリをcloneすると、ファイル名が簡単に260バイト超えてしまいます。

こんな風にc:\とかに短いフォルダを作成して、その下にcloneしましょう。

Gitの設定

チームプロジェクト内にある、Gitの設定を行っておきましょう。グローバル設定(全Gitリポジトリに共通)と、リポジトリの設定(リポジトリ毎)の二種類があります。リポジトリの設定はVSTSでリポジトリを初期化するとVisual Studioに最適化されたGit設定(.gitignore)がダウンロードされているので、設定する必要はありません。

Gitのグローバル設定ではメールアドレスと、氏名だけは必ず設定しておきましょう。何も設定しないとWindowsのログオンアカウントが使用されてしまいます。

プロジェクトを作成する

git clone後、いよいよVisual Studioで作成します。

.NET のWebアプリケーションを作ります。

.NET Coreでやってみます。

Application Insightsも構成してみます。

App Serviceを設定して、完成。

まとめ

ようやく開発らしいところになりました。ここから先、ようやく開発関係の機能紹介を行います。

Visual Studio 2017 RCの再インストールが必ず失敗する場合の対処

※:RC版の話なので、正式版では直っている可能性があります。

ちょっとした事情でVisual Studio 2017 RCを削除したのですが、問題が解決したので、再インストールしようとしたところ、こんなエラーが出て、どうしても実行できません。

[3874:0021][2016-11-23T06:57:22] Error 0x80131509: 場所 Microsoft.VisualStudio.Setup.Engine.VerifyInstallationPath(IServiceProvider services, String installationPath, IInstance instance, IQuery query) 場所 Microsoft.VisualStudio.Setup.Engine.Install(Product product, String destination, CancellationToken token)指定されたインスタンス 'aa78a46b' を、既存のインスタンス 'f90d13a0' と同じ場所または子ディレクトリにインストールすることはできません。

シングルクォートで囲まれた部分は環境によって変わります。なんだこれ、と思ったのですが、フィードバックで報告しようと思ったら、すでに答えがありました。

1. インストーラーを終了(しばらく待つ)
2. C:\Program Files (x86)\Microsoft Visual Studio\2017 をさっくり削除
3. C:\ProgramData\Microsoft\VisualStudio\Packages_Instances にある、ログに出力されているフォルダ(今回の場合は'f90d13a0')を削除

探すとこういうフォルダができているはずです。このフォルダで判定しているようですね。

で、こういう問題に当たった時、インストーラーの右上の吹き出しから「提案の送信」か「問題の報告」をクリックします。

フィードバッククライアントが表示されるので、適当にありそうな用語を「英語で」検索します。今回の場合はインスタンスというエラーが出ているので、Instanceで探してみます。

すると、こんな風に関連しそうなQ&Aが出てきます。今回の場合はここで解決策も見つかったのでそれが上の手順になります。たいていすでに報告済みな現象だと思いますので、まずは探してみてください。英語じゃないと出てこないのが若干ハードル高いかもしれませんが…。