技術情報関連

時差のシナリオに関してのご意見をありがとうございました

ディベロッパー製品開発統括部 — Tue, 08 Aug 2006 07:04:00 GMT

みなさん時差のシナリオに関して、ご意見をお寄せいただきまして、大変ありがとうございました。

今回は、お寄せいただいたなかで、ご質問がいくつかありましたので、答えさせていただきたいと思います。ユーザー設定のタイムゾーンに関するご質問ですが、特定のルール情報を包括的に含めたものを作るのか、タイムゾーンとして独立したものを作って切り替えるのかといった点では議論の余地が残っています。カスタムカルチャに関連付けさせることができるようにするといった話もございますので、可能性としては"ja-JP-01"といったような指定でのCultureAndRegionInfoBuilder クラスで作成するカスタムカルチャで取り扱うことも考えられます。この場合は以前、カスタムカルチャのシナリオでご紹介した、名前をコンピュータ全体で取り扱ってしまう懸念が残ります。

時差の変更の際の曖昧／重複に関するご質問は、いただいた通り、春先に時計の針を進めた際の失われる時間、秋に戻す際の重複する時間の判断をする関数のこととなります。差分（オフセット）時間やサマータイム区別する文字列が表記に含まれる場合はこの問題は生じませんが、これらの情報がないまま時刻のみがログに記録されている場合など、ご指摘いただいたように対応の方法を考えることになります。

今回、その他の皆さんからもお寄せいただいた、ご経験に基づく詳細なシナリオは、日本のお客さまに基本クラスライブラリをよりよくお使いいただくうえで、いずれも大変参考になるご意見でした。今後のタイムゾーンに関する機能の詳細に関して、頂いたご意見をあわせて、CLRチームと検討をさせていただきます。

繰り返しになりますが、再度、御礼申し上げます。

VBA, VSTO, VSTA

ディベロッパー製品開発統括部 — Wed, 02 Aug 2006 03:03:00 GMT

このブログをご覧になっている方の中の多くは業務等で Word や Excel といった Office 製品を使われていることと思います。ご存知のようにOffice製品は様々な言語を用いてその機能をカスタマイズすることが可能です。

今回はOffice製品をカスタマイズする既存の技術– Microsoft Visual Basic for Applications (VBA)、Visual Studio 2005 Tools for the Microsoft Office System (VSTO) に触れつつ、現在開発中であるVisual Studio 2005 Tools for Applications (VSTA) について簡単にご紹介したいと思います。

Office 製品において、定例化した作業を簡素化したり、既存の機能をカスタマイズしたくなった場合、まずは Office に搭載されているVBA が選択肢の候補となると思います。VBA の歴史は長く、また Visual Basic がベースになっていることもあって、多くのユーザーにとって馴染み深いものとなっていることと思います。

VBA は現在も非常に有益な言語ですが、昨今はセキュリティに関して注意を払う必要がありやや取り扱いが難しい場合があります。

このVBA のセキュリティ問題をクリアし、さらに生産性を高めたものが VSTO と言えます。しかしVSTO は単なるVBA の置き換えではありません。VSTO を用いることにより、C#、VBを用いて.NET Framework テクノロジを利用でき、アクションペインなどといった新しい機能をより簡単に拡張できるなどのメリットがあります。しかし、最も大きなメリットは、Visual Studio 2005上で開発を進めることができることではないでしょうか。

VSTO の機能の詳細についてはこちらをご覧ください。

また、製品概要に関してはこちらのサイトをご参照ください。

さて、このように比較的簡単にカスタマイズ可能な製品に触れられたユーザーの中には、自分が作ったアプリケーションにもエンドユーザーにカスタマイズできる手段を与えることはできないだろうかと考えることがあると思います。

これを実現するのが、VSTA となります。VSTA を用いることにより、エンドユーザーは C# や VB で書くマネージドコードによってアプリケーションのAdd-in を作成できるようになります。さらに、Office 製品からVisual Basic Editor が立ち上がるように、アプリケーションから VSTA IDE を立ち上げてAdd-in を書くことも可能とします。

さて、このVSTA は、Visual Studio Industry Partner (VSIP) メンバー向けのサイトからVisual Studio 2005 SDK - April 2006 V2 RTMを入手することにより、RC バージョンをお試しいただくことが可能となっています。

なお、VSIPメンバー参加は、SDKをお試しいただく目的であれば無料で参加いただくことが可能です。

VSIP の詳細についてはこちらをご参照ください。

登録に際しては、こちらからのサイトをご使用ください。

具体的なインストール方法は次のようになります。

1. Visual Studio 2005 SDK をインストール

2. 以下のコマンドを SDK をインストールしたパス (デフォルトでは C:\Program Files\Visual Studio 2005 SDK\2006.06) の下にある VisualStudioToolsForApplications\SetupPackage\ より実行

> msiexec /i vsta_aide.msi VSTAINVS=1

(ここで指定する VSTAINVSオプションはVSTA を Visual Studio 2005 に登録する場合に必要となります)

3. さらにその下の ”Language Packs” フォルダの下にあるランゲージパック (日本語の場合、”1041 Japanese - Japan”) をインストール

実際に既存のアプリケーションに Add-in 機能を追加するためにはいくつか手順を踏む必要があります。この手順を理解するために、まずはドキュメントに含まれるWalkthroughをお試しすることをお奨めします。このWalkthrough では、ShapeApp という付属のサンプルアプリケーションを用いて Add-in 機能を付加するまでの手順が細かく書かれています。 (但し英語で書かれておりますのでご了承ください)

正式版は Office 12 と合わせて公開される予定となっており、少なくとも InfoPath12 からVSTAを利用できるようになることとなっています。

まずは今回ご紹介したRC版を一足先に触れてみてその可能性を探ってみてはいかがでしょうか。

日本における時差のシナリオに関してご意見をお聞かせください

ディベロッパー製品開発統括部 — Fri, 21 Jul 2006 05:30:00 GMT

先日、.NET Frameworkの基本クラスライブラリを作っているチームから、時差を表すTimeZone クラスの機能に関して問い合わせが来たので、こちらのblogをご覧の皆さまからもご意見をお聞かせいただければと思い、今回は書いてみます。

現在、日本国内では時差はないので、国内向けのアプリケーションを作る場合は、さほど考える必要性がありません。しかし、最近では多国籍な会社のお客様からの要求や、国内でも特定地域でのサマータイムの実験の要求なども出ています。.NET Frameworkの基本クラスライブラリ（BCL)では、DateTime.ToUniverslTime メソッドやTimeZone.ToUniversalTime メソッドを使ってローカルの時刻を元に世界協定時刻（UTC)を導くことができますが、特定のタイムゾーンの時刻を変換するには、独自の工夫が必要です。

原文からの受け売りになりますが、現状BCLチームが大きなデザインとして考えているのは以下の点になります。

タイムゾーンの列挙
タイムゾーン間の時刻変換
タイムゾーンのシリアル化
DateTimeに標準時からの差分を組み込む
歴史的経緯からサマータイムのルールが年毎に変わっていたもののサポート

少し視点を日本に向けて歴史的経緯からみると、日本で昭和20年代に実施され廃止された、夏時刻法および西部標準時をどう取り扱うべきか（または取り扱わないべきか）というところも考えなくてはいけないでしょう。

ここで、原文の方を読み進めると、以下の9つの点に関して英語ユーザーからの意見を募っています。

ユーザー設定のタイムゾーンの作成（時間帯を、既定でコンピュータ上にあるもの以外に、プログラム的に作成すること）
ユーザー設定のタイムゾーンを恒久的にコンピュータ上に書き戻す
サマータイム設定を切った状態でタイムゾーンのコピーの作成
サマータイムのため、時計の時刻を前後した際のローカルタイムが未確定、もしくは曖昧／重複にあるかどうかを問い合わせる関数
歴史的経緯によって基本になる差分が年毎に変わったタイムゾーン（前述の夏時刻法に対する実装が関係してきます）
稼動中のコンピューターの現在のタイムゾーンの変更
スレッド単位、もしくはプロセス単位のアンビエントタイムゾーン*1の設定
一行で簡潔に変換を可能にするヘルパ関数（TimeZone.Convert(time, "Pacific", "Eastern") のような）
"PST", "EDT"といったタイムゾーンを組み込んだDateTimeに対する解析と書式設定

お手数ですが、以上の点につきまして、トラックバックにてご意見をお寄せください。形式は「どのようなものでも」ということなのですが、「必要／不要／多分必要」のいずれかのランクをつけていただき、それに関する簡単な説明を加えていただけますと、実装担当者との意思疎通の際に助かります。原文には「実装のお約束はできませんが」といった前置きがありますので、恐れ入りますが、この点はご容赦ください。

将来のよりよい製品をお届けするために、ぜひ、ご協力をお願い申し上げます。

*1 CultureInfo クラスのようにスレッドのような実行単位に対して環境的に設定することを意味しているでしょう。間違っていた場合は、後日修正をこちらに追記いたします。

続Atlasプロジェクトの国際化（日本でどうする？）

ディベロッパー製品開発統括部 — Tue, 04 Jul 2006 10:42:00 GMT

以前、ご紹介させていただいたAtlasですが、CTPも数回出ましたし、Go-Liveという形態で使っても良いことに３月からなっていますね。私も少し自分のプロジェクトのページをUpdatePanelを使ってコンテンツの一部分を書き変えたリ、テキストボックスにAutoCompleteExtenderで読み仮名からの自動補完の機能を付けてみたリしています。

Atlasの全容が明らかになるにしたがって、なかなか奥が深いことがわかります。クライアント側のスクリプトライブラリにインターフェイスや名前空間、継承といったオブジェクト指向の基礎となる部分を実装し、それらを使って基本クラスライブラリを作り、それを土台にコンポーネントのモデルとUIフレームワークを構築、コンポーネントやコントロールを組み上げるというものが、ブラウザの違いを吸収する層の上にあるので、開発者の生産性やコードの再利用性などはかなり高いのではと思います。スクリプトライブラリはAtlasをインストールしていただければ、ソースコードをご覧いただけるので、研究調査の対象としても良いかもしれません。

クライアント側のプログラミングモデルは慣れていければプログラム的にJavaScriptを書くことも宣言的にXMLスクリプトも書くことはできると思いますが、開発ツールのサポートが必須ではないかと思います。反面サーバー側のタグによる宣言的モデルは、マークアップビューでの自動補完の機能が効いていますし、デザインビューでのプロパティグリッドやスマートタグも使えるので、Webページを開発なされる方は英語であってもそれなりに、お試しいただけるのではないかと思います。もちろんサーバー側のコントロールですので、動的な動作も現在のASP.NETのサーバー側のプログラミングの延長で行えます。

以前のblogではUIの改善のためにという形でご紹介をさせていただいたのですが、さらに興味深いのは、サーバー側にBridgeと呼ばれる他のサービスやデータを集約、橋渡しを行う箇所があることです。これらのことを考えていくと、使用者に対してWebでの体験を統括的に改善する術を提供できるのではないかと思います。

さて、以前に懸念している事項としていくつかの日本の使用シナリオを挙げ、トラックバックにて貴重なフィードバックをいただいたのですが、国際化のモデルはASP.NET 1.xから継続してあるカルチャを使うGlobalizationのモデルを使い、ブラウザのリクエストに拠って適当なカルチャをSys.CultureInfoに返すというスタイルです。多言語化は翻訳やコンテンツのみならず、照合順序なども考えないといけませんが、クライアント側のJavaScriptの機能で制限を受けてしまうことは考えられるかもしれません。他に、JSONのエンコーディングはUnicodeのいずれかのものでUTF-8が既定と先日IETFのドラフトで方向性が示されましたし、他のXMLなどによるデータのやりとりもそれに準拠することになると思いますが、これが現在のASP.NETのresponseEncodingなどで返されるコンテンツとうまく整合性がとれるのかなど、調査作業は山積しております。

懸念事項のうちの２番目として挙げさせていただいたIMEとの動作ですが、弊社のツールであるFiddlerなどを経由してHTTPの中身を覗いてみると、テキストボックスなどでは変換前の入力文字ごとにサーバーへ要求が送られているようです。しかし、AutoCompleteで別なコントロール(たとえば隣にあるボタン)をクリックすると、未確定候補が選択項目を上書きしてしまったりしますね。

Go-Liveとはいえ現状は、まだ開発途上であります。ぜひ、お使いいただいた中で、これ以外にも日本語を扱う上でお気づきになられたことがありましたら、トラックバックにてご意見やご要望をお聞かせください。

ナオキさん、フィードバックをありがとうございます。Fiddlerに加えてWeb Development Helperなどもお使いいただけますね。Fiddlerがなかったころは、文字化けの調査などにはWindows Serverのネットワークモニタ (NetMon)を使っていました。こちらであれば、Windows Serverのユーティリティとして日本語化もされていますので、使いよいかもしれませんね。

[2006/7/13: 更新] フィードバックへの返信を追加

ひらがなやカタカナの取り扱い

ディベロッパー製品開発統括部 — Tue, 20 Dec 2005 07:44:00 GMT

まだ一部残ってはいますが、Visual Studio 2005や .NET Framework 2.0も生産過程に入って開発も一段落しました。先日のMSCのラウンチイベントをはじめとして、立ち上げに際してお客様の話を聞かせていただく機会が幾度とありましたが、もう間もなく稼動に入られるほど準備が整っているかたから、これから評価検討をなされる方まで、様々な方がいらっしゃるようです。今回もすべてのお客様のすべてのご要望を組み入れることは残念ながらできませんでしたが、これまでにお寄せいただいた沢山のご要望や、これからお聞かせいただくご要望に関しては、また今後の製品計画で検討して役に立てていかなければと思います。

閑話休題。さて、そんな中で、最近Unicodeも新しいバージョン5.0のベータが始まりました。Unicodeも弊社のOS製品に採用されて、もう、何年も使い込まれた枯れた技術になった感がありまが、最近では日本語以外の少数派の言語の充実ぶりが目立っています。しかし、意外と今でもひらがなやカタカナのような基本的な日本語の要素に目を向けてみると思わぬ発見があります。 UnicodeではひらがなはU+3040から始まりU+309Fまで、カタカナはU+30A0からU+30FFまでといったブロックとよばれる領域に割り当てられています。この中で、なかなか興味ことがらが4つほどあります。

必ずしもひらがなとカタカナの文字が一対一に割り当てられているわけではない。
必ずしもブロック名でカタカナやひらがなと指定されている文字が、五十音でいうところのそれらであるとは限らない。
ひらがなの小さな「か」「け」やカタカナの「ワ」に濁点のや「ヰ」に濁点といった見慣れない文字がある。
複合用の濁点（U+3099）や半濁点（U+309A）がある

1.はひらがなの領域にReserved（予約）という形式で文字が割り振られていないものがあることが、端的にあらわしています。これらはU+3040、 U+3097、 U+3098ですが、カタカナでは記号やひらがなにない文字が割り振られています。 2.に関しては濁音や半濁音、または長音記号など、がカタカナやひらがなと認識されるブロックに存在しています。 3.は、ひらがなに小さいカタカナの「ヵ」や「ヶ」が対応するものというもののようですが、日常見るものではありません。また、「ヷ」や「ヸ」といった旧仮名遣いのために使うカタカナ固有の文字はありますが、それらのひらがなバージョンはありません。ひらがなの「う」に濁点を打ったものはありますから、なにか規則的にこうなっているのかは不明です。 4.ですが、上記の3の状態を補うためなのかはよく分かりませんが、Unicode固有の概念の複合用の文字のための濁点や半濁点があります。

これらのことを踏まえて考えると、ひらがなやカタカナの判別やその相互変換、Unicode以外のエンコーディングや全角半角といった文字幅への変換は、意外と一筋縄ではいかないのかもしれません。試しにRegExのIsMatchによるIsHiraganaやIsKatakanaの文字クラスを使った正規表現の照合判別や、Visual BasicのStrConv関数、Win32 APIであるLCMapString関数などを使って動作を試してみるのも面白いのかもしれません。

なにか「この動作にはやられた」といったようなお話があれば、トラックバックなどでお聞かせいただければ幸いです。

[2005/12/29: 更新] 一部の言い回しの修正とリンクの追加、文字化けの修正をしました。
[2006/01/05: 更新] 文字化けが修正されていないのをエンティティ参照に変更しました。

Code-named "Atlas" と Visual Studio 2005

ディベロッパー製品開発統括部 — Wed, 30 Nov 2005 09:38:00 GMT

日本語版 Visual Studio 2005 もいよいよ完成間近です。
そこで今回は、RTM 直前の日本語版 VS2005 に、一部で話題となりつつある（？） Atlas をインストールしてみようと思います。
ご存知の方も多いと思いますので、Atlas (これは、開発コードネームです）に関する細かい説明は省きますが、
簡単に言えば、Ajax （これも説明は省きます）アプリケーションを ASP.NET ベースで開発するためのライブラリということになります。

それではインストールを始めましょう。
始めは Visual Studio のインストールです。
今回は完成直前の RC ビルド、日本語版 VS 2005 Professional Edition をインストールします。無論ここで問題は起こらないはずです。
なお、Web?アプリケーションの開発には、Beta 2 または、それ以降の Visual Web Developer 2005 Express Edition、または、それ以上の Edition が必要です。
詳細は、こちらをご覧下さい。http://www.microsoft.com/japan/msdn/vstudio/productinfo/productline/

次に、 Atlas をインストールします。
こちらのページから、http://msdn.microsoft.com/asp.net/info/future/
ASP.NET "Atlas" Home のページを開き、http://atlas.asp.net/
画面右側の Atlas October 2005 Release から、下の３つのファイルをダウンロードし実行します。

Atlas Blank Project VSI
Atlas Hands-On-Lab VSI
Atlas Wiki VSI

まだ製品版ではないので、コンポーネントに署名がされていなかったりしますが、気にせずに進めます。

これで、VS から Atlas Web Site プロジェクトを作成できるようになりました。
では、上から順番に見ていきましょう。
VS のメニューから [ファイル] [新規作成] [Web サイト] を選び、ASP.NET 'Atlas' Web Site を作ります。
テンプレートから作成された、空の Atlas プロジェクトが出来上がりました。
何をすればいいのか分からないので、次に進みます。

次は、ASP.NET 'Atlas' Hands-on Lab Web Site を作ってみます。
.doc ファイルの読み込み時にエラーが出た場合は、
こちらから Word Viewer 2003 をインストールしてみて下さい。
Word Viewer 2003: http://www.microsoft.com/downloads/details.aspx?FamilyID=95e24c87-8732-48d5-8689-ab826e7b8fdf&displaylang=ja
ここでは、Atlas アプリケーションを作りながら、基本的な仕組みを理解します。
残念ながら、ドキュメントは英語ですが、サンプルコードをプロジェクトにコピーするだけで動くようになっています。

次は、Wiki ASP.NET 'Atlas' Web Site を作ってみます。言語は Visual C# を選びます。
これは、Wiki Web Site の実例サンプルです。
少し複雑なサンプルなので、始めは [F5] を押して、実行してみるのが良いと思います。

Atlas の仕組みが分かってきたところで、次は、Visual Studio の機能も一緒に使ってみましょう。
もう一度、新しい ASP.NET 'Atlas' Web Site を作ります。
次に、VS のツールボックスに Atlas のコントロールを追加します。

ソリューションエクスプローラから、Default.aspx を右クリックし、[デザイナを表示] を選択
ツールボックスを右クリックし、[タブの追加] を選択。タブには Atlas という名前を付けます
次に、そのタブの中を右クリックし、 [アイテムの選択] をクリック
ツールボックスアイテムの選択ダイアログの、[参照] ボタンをクリック
ここで Microsoft.Web.Atlas.dll というファイルを読み込みます。Atlas October 2005 Release の場合、[マイプロジェクト] フォルダの、1つ上のフォルダから見て、.\WebSites\[プロジェクト名]\Bin の下にコピーされています

これで、VS で Atlas アプリケーションをデザインできるようになりました。
コードを書かずに使えるサンプルコントロールがあるので、試してみましょう。

ツールボックスから Script Manager を Default.aspx へドラック＆ドロップします。
続けて、VirtualEarthMap をドラック＆ドロップします
デザイナ上で VirtualEarthMap を右クリックし、プロパティを開きます
プロパティウィンドウで、以下のプロパティに値を設定します
Latitude : 35.5
Longitude : 140

Pushpin コレクションや、Binding、Web Service との連携なども試してみたいところですが、今回はここまでにしておきます。
では、[F5] を押して実行してみましょう。マウスのホイールで拡大縮小、マウスで地図をドラック、方向キー、[+] [-] キー等も使えます。

いかがだったでしょうか？ Atlas と Visual Studio 2005 を連携させることで、Ajax アプリケーションの開発がより簡単になり、普及していけばとささやかながら願っています。
最後に、以後の開発の参考までにこちらを紹介しておきます、MSN Virtual Earth http://virtualearth.msn.com/

Windows Workflow Foundation とは?

ディベロッパー製品開発統括部 — Thu, 22 Sep 2005 04:34:00 GMT

ご存知の方も多いと思いますが、先週ロサンゼルスで Microsoft Professional Developer Conference 2005 (PDC05) が開催されました。概要は日本の MSDN のWeb でも紹介されています。ただし日本の開発部隊は、調布のオフィスに籠もって Visual Studio 2005 開発の最終的な仕上げ作業の最中なので、残念ながら、PDC05 の観客の熱気を直接感じる機会はありませんでした。

それでも Web や社内のメールを通して入ってくる PDC05 の話題として、Windows Vista 関連、LINQ などの「VS2005 の次」をにらんだ技術の紹介、Expression、Project Atlas そのほか、これでもかというくらいいろいろな新技術が紹介されているのを見ると、開発担当の一人としては、「これからたんへんだ～」と思うと同時に意味もなくワクワクしてしまいます。

その中で今回 Windows Vista 関連のプラットフォーム技術として、以下の３つについての詳細が語られました:

Windows Presentation Foundation (Avalon)
Window Communication Foundation (Indigo)
Windows Workflow Foundation (WWF)

(余談: 1 の Windows Presentation.. とタイプして、次にどうしても Manager と打ちたくなる私はだいぶ古いかもしれません..)

上の 1 と 2 はずいぶん前から社外にも紹介されています。しかし 3 については (日本の) MS 社内でも今まであまり語られていなかった部分です。

それでもちょっと調べてみると、すでに英語版としては WWF の Developer Center (英語)やコミュニティサイト (英語)まで立ち上がっており、サンプルのダウンロードもあったりで、なかなか良いスタートを切っているようです。

PDC ではちょっと地味な WWF ですが、せっかくなので米国本社 WWF アーキテクトである Dave Green の最近の Blog を、本人の承諾を得た上で日本語に翻訳してご紹介したいと思います。私自身は翻訳が専門でない上、Blog というかなりラフな原文を元にしているため、多少の不備はお許しください。

http://blogs.msdn.com/davegreen/archive/2005/09/17/470704.aspx (原文)

What is Workflow, and why bother?

ワークフローとは? そしてなぜそうなのか?

ワークフロー、この使い古された言葉は、その説明にもなり、またその説明の妨げにもなってきました。ですからワークフローという言葉について、私が意味するところを始めに説明した方がよいと思います。

ワークフローは、最終的に二つのアイディアに行き着きます。一つは「ワーク(仕事)」としての存在です。ワークフロー的には、各々の仕事内容ごとのざっくりとした単位として考えられます。もう一つは「流れ(フロー)」で、こちらはどの仕事をいつ処理するかということを意味します。
だとしたら、下のコードはワークフローでしょうか?

public void HandleLoanRequest (string customerID, Application app)
{
    if (CheckCredit(customerId, app.Amount))
    {
    MakeOffer (customerId, app);
    }
}

私はこれもワークフローだと考えます。この仕事は顧客の預金残高を確認したのち、何らかのサービスの提供を行います。そして HandleLoanRequest はこの作業が可能か、またどのようなときに実施されるのかについて定義します。

しかし、ワークフローツールの開発会社としては、完璧にその仕事を成し遂げるために、ここに示したコード以上の何かが必要であると、ずいぶん以前から感じているという事実があります。これは、私たちがワークフローのためのキーとなる概念を、未だ見つけていないということを示しています。

私としては、これは私たちが単にフローを記述できるだけではなく、記述したフローを精査し、推論し、操作できるようにする必要があるということだと思います。単純に言って、ワークフローにはモデルというものが必要なのです。

C# (などでコードを書くこと) はそのための一つの方法です。例えば私たちは、ワークフローのために書いたコードをスキャンして、それを基にフローのグラフを描くためのコーディング標準を定義することはできます。

または開発者のために属性を定義して、それを使って開発者の既存コードの特定の部分を呼び出し、モデルを形成するようにできたかもしれません。ただし、これは私たちがWindows Workflow Foundation のために選択したことではありませんでした。詳細は今後お話しすることになると思いますが、ここでは私たちが行った様々な選択について、その理由を説明しようと思います。

まずは、なぜモデルが必要かというところまで戻ってみましょう。私たちはモデルを作るために手間隙をかけなければいけないとして、なぜそうなのでしょうか? またその見返りとして何が手に入るのでしょう? (or the beef, as this Englishman abroad is learning to call it)

その見返りはモデルが可能にすることから来るのではないかと思います。

可視化 - 開発者にとって可視化は、開発時およびメンテ時に役に立ちます。また同時に利用者にとっても、なぜワークフローが決められたとおりに動作するのか知りたい場合、またIT プロにとっては、どのアプリの挙動がおかしいか、またはおかしいと思われるかを知りたい時などにも便利です。

表現性 - ワークフローモデルは、ある特徴的な問題に対処することに特化したドメイン特化言語(DSL)です。一つの例として、あるドキュメントレビュープロセスを考えてみます。このプロセスでは、5 人のうち 3 人がレビュー結果に OK したら合格とし、それ以降のレビューを不要とします。このプロセスの場合、コーディングするにはいささか退屈ですが、Windows Workflow Foundation では、このような問題に対応する機能も持っています。

実行 - Windows Workflow Foundation のランタイムは、モデルを利用することで、同じ問題を何度も何度も解決する手間を省くことができます。状態管理と補正などの長期運用されるワークフローの難しい問題に対処するため、私たちはWindows Workflow Foundation の中に、シンプルかつ表現性の高いモデル要素によってコントロールされたサポート機能を組み込みました。

モニタリング - モデルの存在は、特定の意味情報を持ったイベントの流れの生成を、開発者の追加作業なく行うことを可能にします。これはワークフローまたはその集合体のインスタンスをモニターするために利用可能です。Windows Workflow Foundation は、ワークフローの状態から取得したアプリケーションデータを使ってイベントの宣言的修飾を可能にし、それによって、例えば預金の確認がオーダー #14532 のために開始されたことを伝えることができます。

変換 - モデルはモデルを生みます。例としては、あるワークフローモデルのメッセージ交換形式への変換は、PDC で Dharma と Don が行った素晴らしいデモのように、それとのコミュニケーションを必要とします。もう一方の変換はカスタマイズです。ISV がワークフロー製品を出荷すると、それを VAR がカスタマイズし、そして顧客がまたカスタマイズします。しかる後その ISV が新しいバージョンの製品を出荷します。ワークフローにとって、共有され正しく理解されたモデルの利用は、結果として生まれた3重のカスタマイズをより扱いやすくします。

構成 - もしアプリケーションが「ワーク」と「フロー」に分解できるならば、それぞれの「ワーク」の最小単位の要素は、正しく理解されたインターフェースを通して他のワークフローに再利用可能になるはずです。ワークフロー自体は「ワーク」の有効な定義の集合体であり、他のワークフローによっても利用可能なのです。

カスタマイズと変換を組み合わせることで、「ワーク」と「フロー」のそれぞれの定義を共有可能、または相互にやりとり可能となるエコシステムを実現できます。

操作 - ワークフローを実行中に生成したり、変更する必要が生じることは珍しいことではありません。それがコード変更であるならば、たとえユーザーが対処方法を理解していたとしても、セキュリティ担当者にとっては問題となるでしょう。モデルを利用することで、動的な操作が可能となり、それはコントロール可能かつ容易です。Windows Workflow Foundation はワークフローの型とインスタンスに対し、動的な変更を行うことをサポートしています。

私の説明はこれで終わりです(少なくともこれが、この土曜の午後に思い浮かんだことのすべてです)。上記の理由により、モデルというものが良いアイディアだと私たちが考え、優れた ROI (投資利益率) をもたらすと確信しているのです。しかし、これらがあなたのシナリオに恩恵をもたらさないと考える場合は、(Windows Workflow Foundation に頼ることなく) あなた自身がコードを書くことが最良の方法となるでしょう。

posted on Saturday, September 17, 2005 4:04 PM by Dave Green

VS 2005 Web プロジェクトシステム: Web プロジェクトシステムとは。そして、なぜこうしたのか。（後半）

ディベロッパー製品開発統括部 — Mon, 05 Sep 2005 07:59:00 GMT

前回お届けした、VS 2005のWebプロジェクトシステムがなぜこのようになったかの理由のご説明の前半部分の内容はいかがでしたでしょうか。今回の後半部分は、前回の部分より踏み込んだ形で、デバッグのシナリオやMSBuild、Visual Studio Team Systemとのテスト機能の統合と、OrcasにおけるSharepointのすり合わせの部分まで書かれています。

深くより正確なビルド時のエラーチェックと検証

コンパイルやビルド時に発見されたエラーを認識し修正することは、実行時のものより遥かに簡単です。VS 2005とASP.NET 2.0のひとつのゴールは、VS 2005のビルド時のチェックをより深くすることでした。そして、VS 2005でビルド時に提供される検証の深度を深くし、VS 2003で構築されたアプリケーションの実行時に起きることをより正確に把握できる情報を提供することでです。

現在VS 2003とASP.NET V1.1の開発者は、気がつかないうちに、２つの異なったビルド環境を使っています。ひとつは、Webプロジェクト内でコードビハインドファイルをコンパイルおよびビルドするVS 2003です。これは.projファイルに格納される設定によって\binディレクトリへ格納される.dllを生成します。もうひとつのビルドシステムとは、ASP.NET V1.1です。こちらは実行時に違うビルドシステムを使い、.aspxファイル内のコントロール、マークアップやコード（コンパイルされたコードビハインドクラスから導かれています）が、サーバーの別な一時フォルダにコンパイルの出力を保存しています。ASP.NETのコンパイルシステムのビルド設定と、それに続いてVSが生成するコードビハインドのDLL読み込み時の動作はアプリケーションのルートにあるweb.configファイルに格納されています。

これらの２つのシステムが全く違うことは混乱の元であり、コンパイル時にVSが検知できないエラー－すなわち実行時にWebアプリケーションが壊れる原因にもなります。よく問題として聞かれるのが:

1) 開発時に.aspxファイルの名前を変更してしまったが、コードビハインドでフィールドの参照を更新しなかった。VS 2003でビルドを行った際にはコンパイル時のエラーは見つからなかった－－しかし、実行時にNull参照の例外が出た（.aspxとコードビハインドの整合性が取れていないからです。）

2) 開発時に.aspxのサーバーコントロールの定義を打ち間違え（属性の指定間違い、間違った属性値の指定、サーバーコントロールのタグを閉じなかった、データ連結式の間違い、テンプレートの間違いなど）てしまった。VS 2003でビルドを行ったが、コンパイルエラーを見つけることができなかった－－しかし、実行時に解析時エラーが出てしまった。

3) 開発時にweb.configにエラーを入れてしまった（構文の間違いや不適切な値など）。VS 2003でビルドを行ったが、コンパイルエラーが見つからなかった－－しかし実行時には構成エラーが出てしまった。

4) 開発時にwebプロジェクトをビルド。テストを行い終了したと思い、プロジェクトをデバッグからリリースモードに切り替え、配置するプロジェクトの最適化が行われたと仮定した。Web.configで<COMPILATION debug="true"> セクションがアプリケーションをデバッグモードで実行するための実際のスイッチであることをうっかり忘れてしまった（VSは既定でこの値をtrueに設定しますが、変更はしません）。アプリケーションの実行が遅く、期待した動作と違う（エラー処理のパスが違い、.aspxのコンパイルが遅く非効率的であるなど）。

5) Web.config中の <ASSEMBLIES>セクションの値とVSの参照の違いによって、アセンブリが間違って読み込まれ、見つからない。

VS 2005とASP.NET 2.0では、ASP.NETとVSのWebプロジェクトのビルドシステムを合併し、コンパイル設定の格納先が共通の場所のひとつの統一されたコンパイルアーキテクチャにすることにしました。これによって、VS（IDE経由およびコマンドラインのMSBuild経由）でWebをビルドしている場合、上記の５つの問題は、実行時のテストでのみ捕まえることしかできなかったものですが、コンパイル時エラーを生じることになります。

また、VS内部でもデザイン時のより深い統合が可能になりました。以前はASP.NETによって実行時にのみ動的にコンパイルされていたマスタページ、ユーザーコントロール、テーマやそのほかのリソースがVS内でコンパイルされ、使うことができるようになりました(例えばこれによってユーザーコントロール、マスタページ、スキンリソースのWYSIWYGとIntellisenseサポートができます）。また、各.aspxページ内からのコードとコンテンツの完全なIntellisense機能を可能にします。 <SCRIPT runat="server">ブロック、<%# %>データ連結ブロック、そのほかのASP.NETページ内の構文要素はVSのエディタから完全にサポートされます。

この統合されたコンパイルとビルド設定（リリース／デバッグ、アセンブリ参照、名前空間インポート、警告レベルなど）アプリケーションのweb.configにおける<compilation> セクション内部に格納することにしました（これらの設定はすでにASP.NET 1.1で存在します）。このファイルはWebプロジェクトのルートに対して相対的であるため、VSでこのWebプロジェクトが複数の.slnソリューションに含まれることを簡単に可能にします。

さらに、Webプロジェクトにおいてよりリッチなコンパイルと実行時の検証が可能になったことに加えて、新しいアクセシビリティ準拠の検証をVS 2005に追加しました（Section 508とWCAG準拠のものをチェックできます）。このアクセシビリティのチェックは手動で実行することができます（ツールバーにボタンがありますし構成と実行がメニュー項目としてあります）。また、開発者はWebプロジェクトでビルドが起きる度に、自動的にアクセシビリティチェック機能を実行するかの構成をすることができます。

さらに柔軟性のある反復的なWeb開発の体験

反復的で柔軟性に富んだWeb編集モデルを可能にするために、VS 2005でのワークフローの動作を最適化しようと試みました。この最適化はWebプロジェクトシステムの変更の直接の結果得られるものです。

1) VS 2005でWebプロジェクトに対して早急で戦術的な変更を可能にし"保存と更新"によって直ぐに変更を確認できること。VS 2002とVS 2003では、Webアプリケーションでのどのような変更でも、変更を確認するには、開発者はプロジェクトの再コンパイルとリビルドをおこなうことが必要とされていました。VS 2005はこれも完全にサポートしています（すでに書きましたが、"ソリューションのビルド", "Webのビルド" と "ページのビルド"でコンパイルし、各粒度でエラーがないか検証できます）。

ユーザーが編集中のコードビハインドやクラスファイルを保存し、ブラウザで更新（明示的な再コンパイルやリビルドが不要）を行った時点での、"必要に応じた" コンパイルのワークフローもサポートしています。ASP.NET は必要に応じて変更があったリソースに対して再コンパイルを行い、要求に対して適用します。これによって、違いを即座に確認することができます。これは急な施術的変更（1、2行の修正を正しく行った自信がある箇所で、直ぐに変更を確認したい箇所です）を行うのに適しています。これは動的言語／スクリプト（すばやい開発）の最高の機能面と、厳密な型付けのコンパイル言語（よりよいエラーチェックとパフォーマンス）最高の機能面を併せ持つものと考えます。

2) デバッガがアタッチされた状態でのコードの編集と追加機能。VS 2002とVS 2003で、デバッガをアタッチやデタッチすることは面倒な場合があります（とくにデタッチ時にプロセスを落としてしまうような場合）。デバッガがアタッチされると、実行しているWebアプリケーションやWebプロジェクトに対して、開発者は変更を許可されません。

VS 2005では、開発者はデバッガの元でWebプロジェクトを起動することができ、問題を見つけるために、要求に対してステップスルーを試すことができます。そして、デバッガをデタッチし閉じることなくメソッド、クラス、ページの追加、プロジェクト内のコードを変更し保存を行い、ブラウザで更新を押して、直ぐにデバッガでステップスルーができます。これはVBとC# の双方でサポートされ、クライアントプロジェクトの"エディットコンティニュ" サポート（メソッド内のみが変更可能です。メソッド、パラメータ、クラスのシグナチャの変更はできません）より、さらにリッチな編集を体験できます。1 ～ 2時間の間デバッガをアタッチしておいて、ページ、クラスそしてWeb全体を開発しながら、いつでもステップスルーが可能なことは、個人的にとても有効でした。

よりリッチなWeb開発オプション

VS 2003まではなかったWeb プロジェクトのためのオプションがVS 2005とASP.NET 2.0で追加されています。－－ .aspx, .ascx, .master ファイルといったコンテンツの全てをWebプロジェクトとして完全にコンパイルすることができます。コンパイル後にHTML、ASP.NETサーバーコントロールマークアップコード、また任意で.aspxと.ascxファイル自体さえも削除することができ、.dllアセンブリだけを出荷できます。この機能における利点を何点か挙げますと 1) エンタープライズ開発環境向けに完全に"固定" した配置パッケージを出荷することができます。2) マークアップの内容の覗き見や変更を防ぎ、よりよい知的財産の保護ができます。3) 実行時のASP.NETのコンパイルステップが省け、最初にページにアクセスされた際の.aspxマークアップがコンパイルされる最初のパフォーマンスの落ち込みを避けることができ、より短時間のアプリケーションのスタートアップ、効率的なワークセットの使用ができます。この最後の利点は、大きなアプリケーションで極めて顕著な効果を示し、VS 2003でビルドされたアプリケーションと比べると、非常に大きなパフォーマンスの改善を提供します。

－－サイトに配置したアセンブリの"パッチ処理"のサポートができ、一部の（全てではありません）コンパイルされたコードビハインドのバイナリを、全てのDLLを変更する必要なく、上書きすることができます。これは、新しいビルドシステムの"固定名"オプションによって可能になります。そして、それら全てのもので使われているコードビハインドDLLを更新することなく、ライブラリ内のユーザーコントロールライブラリをアップデートするためにバイナリを再発行するのに有効です。

完全なコンパイルをサポートするだけでなく、コードビハインドだけがコンパイルされ.aspxマークアップが後日のカスタム化のために取り残されるモデルも、もちろんサポートしています。また、さらに、全て（コードビハインドもクラスも）のものが完全に動的にコンパイルされる、動的コンパイルモデルもサポートしています。これは趣味でやっていらっしゃる方や、小さなサイトで役に立ちます。

Webプロジェクトのビルド自動化サポート

VS 2005とASP.NET 2.0はコマンドラインによるビルドの自動化をよりリッチにサポートしています。そして、VS 2005より新規に採用になったMSBuildのシステムを使うことによって、統合と自動化することができます。

ASP.NET 2.0は、ASP.NET プロジェクト（VS がインストールされているいないに関わらず）のコンパイルとビルドを完全にサポートする新規のコマンドラインコンパイラ（aspnet_compiler.exe) と共に出荷されます。Webプロジェクトですでにご紹介した新規のビルドと配置のオプション（.aspxコンテンツ、更新可能なアセンブリなどのコンパイルのオプション）オプションのを全てサポートし、Webアプリケーションをコンパイルした際の深いエラー警告と検知を行います。

Aspnet_compiler.exeユーティリティは単独で起動することもできますし、MSBuildのプロジェクトファイルのコンテキストで使用することもできます。MSBuildは、自動化とビルドと環境ルールを構築するのに向いた非常にリッチなフレームワークです。Webプロジェクトでどのように使うかのシナリオを挙げますと: ビルドのサポートをし、ビルド前のステップとして、ユーザーコントロールのライブラリを複数のWebプロジェクトからひとつのWebサイトへコピーし、出力コードを署名、各々の実行する自動化されたビルドに対してリリースとデバッグのビルドを別々なディレクトリに出力、自動単体テストの起動、コードカバレッジのレポートの配信などができます。

MSBuildはコマンドラインから起動できます(.NET Frameworkの再頒布のセットアップの一部として出荷され、VSはビルド用サーバーには必要ありません)。Webプロジェクトを含む .sln ファイルを渡すと、ソリューションの一部としてMSBuildによってビルドと配置が行われ、基本的なビルドオプションのサポートがなされます。

残念ながら、WebプロジェクトのIDEでは、MSBuildのワークフローを起動するIDEサポートを直にすることはできませんでした。したがって、単一のWebプロジェクトでMSBuildファイルをソリューションに追加し、IDEから直に起動することはできません（VS 2005ではC++プロジェクトも同様にこれをサポートしていません）。

VS 2005のWebプロジェクトでできる同様な機能は、同じVSソリューションのWebプロジェクトとの"ヘルパープロジェクトのビルド"の追加です。この"ヘルパープロジェクトのビルド"とは、単なる空のクラスライブラリプロジェクトですが、Webプロジェクトとソリューション全体双方単一のスクリプトのカスタムビルド動作を記述できるカスタムビルド／構成されたMSBuildスクリプトのことです。たとえば、複数のユーザーコントロールライブラリのプロジェクトのコンパイルし、Webアプリケーションプロジェクトとしてマージ、コンパイルし発行、そして、grepユーティリティの実行をしてweb.config中の運用配置の接続文字列が使用されているかを確認し、必要なweb.configファイルが暗号化されているかなどなどです。そして、"ヘルパープロジェクトのビルド"をIDEもしくはコマンドラインから直接ビルドすることによって、これらのビルドアクションを起動することができるでしょう。これは、ビルドスクリプトをWebプロジェクトに直接付けるよりはエレガントではありませんが、機能的には同様です－－しかも、VS 2003よりも強力です。

先の話をすると、MSBuildによるさらなる統合サポートを追加する予定です。これによってさらに多くの面白いことができることになるでしょう。いまのうちはMSBuildに対する追加のサンプルをWebに投稿する予定にしています（ソースコード付きですので、変更が可能でしょう）。このサンプルでWebプロジェクトに対する全般的なものと詳細なものの双方のシナリオをお見せします。

Visual Studio Team System 統合

VS 2005の大きなもののひとつにVisual Studio Team Systemの導入とそれがサポートする高度な開発があります。これらの機能はWebプロジェクトシステムと完全に統合され、新しい機能の利点を享受できるようになっています。多くの新機能の中で、Webプロジェクトに関連するものとして:

1) Webプロジェクト内からのクラスとWeb UIに対する単体テストの開発機能（テストプロジェクトからの機能的なASP.NETのUIの検証）。ブラウザとサーバーの相互作用をキャプチャするビルトインのWeb応答ツールがVSTSにはあり、簡便に動作の自動化と検証を可能にします。

2) テストによって行使されたコードの割合を正確に数値化し計測する機能（コードカバレッジと呼びますが）。Web開発者はWebプロジェクトをビルドし、沢山のテストを作成し機能を実行させ、これらのテストを実行して"Webプロジェクトの74%の行はこのテストによって実行された"といったような詳細なレポートを取ることができます。また、同様に、コードのどの部分が、境界や使用ケースの制限で行使されなかったかも正確にレポートを取ることができます。

3) Webプロジェクトに対してのRPS（Request per second: 要求／秒) 処理能力、平均待ち時間、メモリー使用など様々な評価値の計測をロードテストで行う機能。

4) Webプロジェクトのコード実行をプロファイルしWebプロジェクトの内部での時間の使われ方やメモリーの割り当てと使用などを解析する機能。

5) 新しいビルドサーバの機能を使って毎夜のビルドを起動を自動化する機能。テストがこれの一部として自動に実行され、ビルドの品質を検証することができます。

そしてほかにも沢山のものがあります。 http://lab.msdn.microsoft.com/teamsystem/default.aspx （英語）へお越しいただいて、Visual Studio Team Systemの詳細をご覧下さい。

Sharepoint Server サポート

来年Office 12と共に出荷される次期リリースのSharepointと統合するためにASP.NET 2.0では多くの作業をしました。この新しいバージョンではASP.NET 2.0の新機能（WebParts、Master Pages、Themes、SiteNavigation, Membership, Roles, Personalization, Localization, Data Controlsなど）をひたすら使って作られています。Visual StudioのゴールのひとつはSharepointソリューションを作るための大きなサポートツールとして機能させることです。今日VS 2003 では限定的（Webパーツのコントロールをクラスライブラリとして作ることができるだけです）。新しいVS 2005 のWebプロジェクトのデザインゴールのひとつは、Sharepointをよりよくサポートし、Sharepointソリューションを直接開いてデバッグ可能にすることでした。将来的には稼動しているSharepointサーバー内で新規ページの作成と編集、コードビハインドロジックをページに追加し、アプリケーションロジックの作成、ワークフローのカスタム化、新規のWebパーツコントロールの追加、そしてデバッグをしてソリューションの終了させることのサポートを可能にする予定です。

終わりに（ここまでお読みいただきましてありがとうございます）

上記のセクションでお分かりいただけたかと思いますが、非常に多くの機能がVS 2005のWebプロジェクトによって提供されています。我々はこの機能性は新しい機能を追加しただけでなく、いままでVS 2003をお使いになられたお客様からフィードバックとしていただいた多くの不満点を解決すると思います。

失敗した点は？と聞かれるかもしれませんが、多くないと思いたいです。何人かのひとからBeta 1とBeta 2において重要な機能が欠けている点を指摘いただきました。以前のblogへの投稿（英語）で書きましたが、これらの機能は最終リリースには入ります。

現在のVS 2003の機能でVS 2005のWebプロジェクトシステムでサポートされていないものは、Webプロジェクト自身でのビルド前／後のイベントだと思います。上の"Webプロジェクトビルド自動化サポート" のセクションで書きましたが、"ビルドヘルパープロジェクト" のソリューションへの追加によって、同等の機能が追加でき、VS 2003が提供していたよりさらにリッチなビルドのカスタム化のサポートがMSBuildによって手に入ります。しかし、この追加ステップはWebプロジェクトに直接埋め込むより少し不便です。最終リリースでは、設定と使用方法と利点をより見つけやすくするために、ホワイトペーパーを出そうと思います。

WebプロジェクトシステムとVisual Studioのほかの部分の双方に多くの変更があったので、現在お使いになっている開発者は多くの新しい機能、その利便性の完全な使いこなし、現在の解決方法（または回避策）の新機能への割り当てのやり方を学ぶには少しだけ時間がかかるでしょう。「××はどうやってやるの？」「××のもっとやり易い方法は？」といった質問や、追加のblog、MSDNのホワイトペーパーの要望や提案の投稿は大歓迎です。新しいblogで返答するか、詳細を書いたホワイトペーパーで追跡調査します。

以下がすでにお問い合わせがあって、計画をしているものです。

1) VS 2005でユーザーコントロールライブラリの複数のWebアプリケーションでの再利用のテクニック

2) VS 2005で複数に入れ子、分離されたVdir、またはアプリケーションでの単一Webサイトを構築するテクニック

3) VS 2005におけるMSBuildとビルドヘルパープロジェクトを使うテクニック

4) VS 2003からVS 2005にアップグレードしプロジェクトシステムで考慮しなくてはいけないことのテクニック

いかがでしたでしょうか。この内容によって，あたらしいプロジェクトシステムに対してのさらなる情報の提供と、これで何であるかといったことが明確にできていれば幸いです。

繰り返しになりますが、さらなる詳細や明らかでない点ががありましたら、お聞かせください。

Thanks,

Scott

後日追加: いくつかのWebプロジェクトシステムに関する詳細を書いたblogの内容を投稿しました。ご覧下さい。

Using IIS with VS 2005 and the new Web Project system （英語）

Building Re-Usable ASP.NET User Control and Page Libraries with VS 2005 （英語）

Some techniques for better managing files in VS 2005 Web Projects （英語）

さて、２回に渡って新しいWeb プロジェクトシステムに関してご覧いただきましたが、いかがだったでしょうか。

作業のやり方など、たぶんプロジェクトを開始するにあたって、最初に考慮しないといけない部分ではないかと思いますし、ワークフローなどWeb開発における共同作業の適化にメスが入った部分でもあります。元の投稿は、すでに沢山の質疑応答が行われています。これまで慣れ親しんだ手法からの移行に関してご批判もありますし、その中にもBeta 2以降のアップデートの話など、興味深い内容も加わっていますね。

追加のリンクなどもありますが、もし、ご要望や問い合わせが多いようでしたら、後日、そちらの方の翻訳も考えてみたいと思っています。日本語でのご要望などは、トラックバックかMSDN Product Feedback Centerへお寄せ下さい。

[2005/09/06 更新] 数箇所の変換ミスや改行などの修正。

[2005/09/07 更新] 前回の更新で表示されなくなった部分を修復。

VS 2005 Web プロジェクトシステム: Web プロジェクトシステムとは。そして、なぜこうしたのか。（前半）

ディベロッパー製品開発統括部 — Fri, 26 Aug 2005 04:54:00 GMT

最近、お客様からお問い合わせが多くなってきているのが、VS 2005のWeb プロジェクトに関してです。すでにお使いいただいて開発が進んでいるのを聞いて嬉しく思いつつ、頂いた質問に関して即答するだけのシナリオを調査しきれていないことも多くて申し訳なく思うこともあります。

変更があった部分なので、お客様のシナリオが十分に網羅されているかについては、非常に気にかかる部分です。Redmond側の開発と、このプロジェクトシステムに関して質問とシナリオの確認をしていたのですが、タイムリーな形でScott Guthrieからblogとして情報が出てきましたので、日本語のものを参考訳としてこちらに書いておきたいと思います。

極めて長文なので、２回に分けますが、もしご意見などがございましたら、トラックバックにてお寄せ下さい。

VS 2005 Web プロジェクトシステム: Web プロジェクトシステムとは。そして、なぜこうしたのか。

VS 2005から導入された新しいWebのプロジェクトシステムに関して、最近オンラインで多くの議論が行われています。いったいWeb プロジェクトシステムとは何かということについて、若干のご説明をこの投稿によっていたしたいと思います。

Web プロジェクトとは？

Web プロジェクトとはVisual Studio 2005 中でASP.NETアプリケーションを構築するために使われます。単一のプロジェクト中にアプリケーションが存在するようなスタンドアロンのもの、クラスライブラリ、データ、Webサービス、単体テストやその他のVisual Studioのソリューションの一部のプロジェクトとしてのもの、どちらでもありえます。VSソリューション内の参照とプロジェクトのビルド順序が完全にサポートされています。今日VS 2003を使って行うのと同様に、プロジェクト間の関係を.slnソリューションファイルによって、それらを設定し管理します。（例えば、３～４のクラスライブラリプロジェクトによって構築するクラスライブラリアセンブリがWebプロジェクトで使われるような場合です）。

Webソリューションの発行の準備が整ったら、新しい"発行"のオプションを使い、Webサーバーへ配置可能なディレクトリ構造を生成します。これは、VS2005でWinFormsクライアントのアプリケーションプロジェクトの場合に取られるワークフローの手順と論理的な違いはありません（発行のオプションが、Webサイトの代わりに、クライアントの"Click-Once"のパッケージを生成します）。コマンドラインや自動化されたビルドサーバーのシナリオ用に新しいMSBuildのシステム（後述）によってWebプロジェクトのビルド操作を自動化することができます。

VS 2005 Webプロジェクトの新機能とは？

VS 2005の新しいWeb プロジェクトサポートはVS 2002とVS 2003からの数々の新しい機能拡張をしています。開発者に適した大きな改善点は:

FrontPage サーバー拡張の要件が不要

これまでリリースされたVisual Studioとは違い、VS 2005は、Webプロジェクトの作成、ビルドのために、FPSE （FrontPageサーバー拡張）をインストールする必要がありません。

FPSEがなくてもローカルのIISアプリケーションやvdirを参照、作成、開くことができます。VS 2005はIISのメタベース構成ストアをサポートし、サイト、アプリケーション、仮想ディレクトリと関連付けられた物理パスへの連結を認識、接続することができます。また、ファイルシステムからWeb プロジェクトを編集、または開いたり、FTPを使って遠隔地からアクセスすることができます。

FPSEも必要な方のためにサポートされています。しかし、これまでのフィードバックによると95%超の方が必要ではないようですし、_vti_ ディレクトリはもう必要なくなるでしょう。

開発用Webサーバーを備える（IISが不要 & 標準ユーザーとしてデバッグ可能）

IISによるWebプロジェクトの開発とテストの提供に加えて、開発用のWebサーバーが付きました。このテスト用WebサーバーはIISがインストールされていない、またはITポリシーがデスクトップでの配置を限定しているような場合に適しています。

このWebサーバーは、セキュリティ上の理由（開発中のアプリケーションに、他の場所からのアクセスをさせません）からローカルの要求のみをハンドルし、Webプロジェクトを閉じたときに自動的にシャットダウンします。また、開発者に非管理者権限である標準ユーザーのアカウントとして実行していてる状況でのアプリケーションのデバックを可能にします。一旦アプリケーションの構築ができた後、ローカルのIISで実行するか、リモートのサーバーにアプリケーションを配置しテストと検証を行います。また、Webサイトをリモートサーバーにコピーする、組み込みの"Web コピー" ウィザードがあり、FTPとFPSEをコピーのためのプロトコルとしてサポートします。

当然ながらIISディレクトリに対してのWebプロジェクトのビルドを完全にサポートしています。（メモ: 入れ子のvdirとサブアプリケーションをソリューションとしてビルドする場合、必要となります。）

柔軟性のあるファイル管理とツール間のコラボレーションのサポート

他の種類のアプリケーションプロジェクトと比較して、Web プロジェクトには以下の特徴があります。

１）ほぼ常にといっていいほど、他のまったく別なツールと併用してWeb プロジェクトは作られます。イメージの編集には他社の有名なツールが使われますし、CSSやASPX/.HTMのコンテンツのレイアウトはまた別な製品やFrontPageといったものが使われます。コードにはVSが使われます。これらの違う種類のリソースの統合や共同作業に多大なコストがかかっています。ひとりの担当者が上記の全ての作業をおこなうこともありますが、一般的に大きなプロジェクトでは複数の担当者に分担されます。

VS2002/2003に対してよく聞く不満として、このようなツール間のワークフローを管理することが大変であるということがありました。特に、VS以外のツールでFPSEを使うことができなかったり、VSのプロジェクトファイルとの統合ができない点がありました。例えば、デザイン担当が新しい背景イメージを使うためにCSSファイルをWeb プロジェクトでアップデートしたとします。仮に、VS 2003を使うWeb開発者が、古いイメージを削除し新しいイメージを追加することをプロジェクトファイルのマニフェストに書く変更を怠った場合、開発時には大丈夫だったものが、新しい場所で構築した際、新しいイメージがコピー／配置されないため運用に失敗します。

2) Webプロジェクトは、Web アプリケーションからページ、イメージ、CSS スタイルシートや他の項目のレイアウトが直接エンドユーザーにWebブラウザを通して提供される点でもまた特徴的です。ファイルのレイアウトは、ほぼ常に階層的であり、作業の大半や注目はここに集まります。典型的なWebサイトでは、ファイル数は簡単に数百、もしくは数千にも上ります。VS 2002/2003でよく聞かれた不満が、IDEからこの管理が非常に難しいことでした。とりわけ、ソース管理を使った際に共通のプロジェクトファイルをチェックアウトしチェックインする作業を、レイアウトが変更になったりファイルの追加、名前の変更、削除が行われる度に行わなくてはなりませんでした。

この双方のシナリオをより良くサポートするために、VS 2005のWeb プロジェクトでは、一元的なWebプロジェクトのマニフェストファイルに全てのファイルの一覧を保存することを止めました。その代わりに、Webプロジェクトのコンテンツやレイアウトは、Webプロジェクトフォルダのファイルレイアウトとファイルのコンテンツから導かれます。 Webプロジェクトでのファイルの追加、削除、移動作業は、競合の元となる一元的なプロジェクトファイルを必要としません。これによって、ファイルシステムを使って作業をするVS以外のどのようなツールでも容易に使うことができます。また、ソース管理下で使う場合でも、移動や変更をする際に、プロジェクトファイルをロックしてから更新する必要がありません。

Webプロジェクトにおけるソリューションエクスプローラ下のプロジェクトレイアウトも、Webプロジェクトのファイルシステムの表示をするように変更しました。このことによって、開発者は、実際にWebプロジェクトのファイルレイアウトとコンテンツがどのように見えるかを、常に100%正確な形で見ることになります（VS 2003では違います）。メモ: "参照"のツリーは、ファイルシステムで表現できないため、Webプロジェクトのルートノードのところで表示されません。代わりに、プロジェクトの参照リストをプロジェクトのプロパティページ（ソリューションエクスプローラ内でプロジェクトを右クリックすると、早くたどり着けます）から呼び出し、"参照の追加"メニューかコンテキストメニューによって新規の参照をプロジェクトに直に追加することができます。

Webプロジェクトはソース管理も当然サポートしています。ソース管理下でプロジェクト内のファイルを移動、もしくは名前の変更をした場合、VS 2005は移動、名前の変更をソース管理貯蔵所で（履歴を残しながら）適宜行います。プロジェクトのマニフェストをチェックインとチェックアウトし明示的に更新する必要はありません。

大きなWebプロジェクトのよりよいサポート

大きなWebプロジェクトをVS 2003で作業している開発者の方々から、多量なファイルとコンテンツを扱う環境ではIDEとワークフロー環境は上手くスケールしないというご不満を聞いていました。大きなWebサイトを開くには数分、変更を行ってリビルドを行い実行するまでに、非常に長い時間がかかります。

VS 2005では、この何百、何千といった項目をWebプロジェクトで扱うスケーラビリティの問題に対して目覚しい改善があります。例えとして、ローカルのデスクトップコンピュータ（P4 3Ghz)で、9,000のファイル（250の項目を含む36のディレクトリに分散された5,000の.aspxページと4,000のイメージ）を開くテストをしてみました。VS 2005で開くのに３秒以下です。そして任意のディレクトリの任意の.aspx ページを、一旦停止も遅れることもなく、すぐに編集開始することができました。これは、以前のどのVS（このサイズのプロジェクトを開くのに数分かかります）のバージョンと比較しても極めて高速です。

この9,000の項目があるWebサイトを初めてクリーンな状態からビルドするのに約42秒ほど私のコンピュータでかかります。VS 2003もほぼ同じです。Webプロジェクトをビルドした後、この5,000のうちの任意のページを開き、ページに変更を加え、リビルドを行い、Ctrl-F5で実行とテストを行うのに2秒以下です。

こういったことを容易にするために、若干アーキテクチャの変更を行いました。もっとも大きなものは、Webプロジェクト内のものを全て１つのDLLにコンパイルする（VS 2002とVS 2003でサポートしている唯一のモードです）ことを止めました。代わりにWebプロジェクトを複数の細かなアセンブリに区切っています。

Webプロジェクト中にある、すべてのコードビハインドではないクラス、データセット、WebサービスとそのほかのUIではないコードは、共通のアセンブリに今回コンパイルされます。ページ、ユーザーコントロールは別々の細かなアセンブリにコンパイルされます。Webプロジェクトの各ディレクトリは既定で別々なアセンブリにコンパイルされます。Webプロジェクトはソリューションの一部として他のクラスライブラリプロジェクトを参照もできます。この場合は今日と同様に、プロジェクトのアセンブリとしてコンパイルします。

このさらに細かくしたモデルの最大の利点は、変更が行われる度に、Webサイト全体を再コンパイルする必要が無いことです。何を変更したか、変更によるダウンレベルのビルド依存関係は何か、リビルドに対して影響を受ける部分によって、コンパイルの範囲が簡単に計算できるようになりました。

VS 2005の開発者は"ビルド"メニュー中に今回より多くの選択があります。ソリューション全体を強制的にビルドすることができたり（現在のWebプロジェクトとソリューション中の他のプロジェクト全てを含みます）、Webプロジェクトのみをビルドまたはリビルドできたり、また新しい"ページのビルド" の選択をし作業編集している現在のページをビルドまたはリビルドしたりできます（そして変更された使用しているユーザーコントロールといった任意の依存するリソースも）。完全ビルドとは関係ないローカルで行っている数個のファイルに対する変更を簡単に検証するのに有効です。これによって、VBのような背景でのコンパイルする機能がないC#を使っている開発者にとっては、完全なリビルドをせずに、IntelliSenseの更新がかかる方法を提供します。

開発者はF5とCtrl-F5の実行オプションによってどのレベルのコンパイルエラーチェックを行うかを構成することができ、このキーによるWebアプリケーションの立ち上げの際にエラーのチェックがなされます。既定では今までどおりWebサイトの変更されたページに全て関してコンパイルされます。大きなWebアプリケーションを取り扱っている際には、効果的な構成オプションは現在作業しているページやリソースに対してコンパイルすることです。これによって、最初に全ての他のものもコンパイルすることを避け、9,000ものファイルがあるWebアプリケーションを３秒で開いて、任意のページを２秒でコンパイルし実行するといったことが可能になります。

今回は、ここまでです。後半はできるかぎり早くお届けしたいと思っていますのが、少々お待ち下さい。なにしろ長いもので・・・。

皆様、コメントをいただきまして、ありがとうございます。

Moo さん、補足いただきましてありがとうございます。基礎部分の知識やスキルは継続的に応用ができますし、ゴールとしてASP.NET 1.x 向けに作られたWeb アプリケーションとの互換性100%を目指しています。新製品の常として、より良くお客様の実使用シナリオをサポートできることを考慮し、さらに快適にお使いいただくために、改善を継続的に行っています。

どっとねっとふぁんさん、ご要望をありがとうございます。blogの翻訳のご要望は一般的に多いのですが、開発作業と並行して行うのは大変難しくなります。日本の開発チームとしては、開発作業の一環として、日本でBetaに取り組まれて問題にぶつかっていらっしゃるお客様からの問い合わせへの全般的な回答に当たるものに関して、できる限り行いたいと思っています。ぜひ、ご遠慮なく MSDN Product Feedback Center などでBetaでの開発中に見つかるBugやSuggestionをお寄せ下さい。

[2005/08/27 更新] HTMLの貼り付けの際に下線の付いた部分が重複していたのを修正。若干の用語の修正。

[2005/08/29 更新] コメントへの返信の追加。

[2005/09/09 更新] MSDN Product Feedback CenterのURLを直接のものから日本語の解説のものに変更。