Welcome to MSDN Blogs Sign in | Join | Help

[Info] PDC 09 (Los Angeles) の発表内容

こんにちは。

注目の Professional Developers Conference (PDC 09) もそろそろ終了の時間でしょう。既にご存じの方も多いかと思いますが、この PDC 09 では、非常に多くの内容が発表されています。(このブログでもご連絡した Office / SharePoint の Beta 提供も、そんな数多くの発表内容の 1 つです。)

各メディアなどでも取り上げられていますが、発表内容については、次号の MSDN Flash (ニュースレター) の中でもヘッドライン情報 (箇条書き) として総括したいと思います。(購読は こちら から)

なお、PDC 09 の内容については、以下でキーノートや一部セッションの情報を視聴・ダウンロードすることができますので、あらかじめ内容を抑えておきたい方は是非ご視聴ください。(基調講演 (1日目、2日目) だけでも全部で相当な時間がありますが。。。)

Microsoft PDC 09 :
http://microsoftpdc.com/

 

 

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] Office 2010 Public Beta / SharePoint 2010 Public Beta のダウンロード提供を開始しました

こんにちは。

Office 2010 Beta 2 / SharePoint 2010 Beta 2 のダウンロード提供が開始されました。(日本語版もあります)

http://www.microsoft.com/2010/ja/

Office クライアント (Visio、Access 等々) との連携を楽しみたい方は ECAL (Enterprise Client Access License) 版を、また開発だけを楽しみたい方は SharePoint Foundation 2010 (旧 WSS) もダウンロード提供されています。

既にダウンロード公開されている Visual Studio 2010 Beta 2 には SharePoint 2010 開発用のツールが含まれていますので、開発者の方は、先日このブログでもご紹介した開発用のハンズオンラボをお試しいただくこともできますし、Microsoft Developer Forum 2009 でお見せした "楽しい" デモなども試していただくことができます。(ただし、REST の機能を使用するには、現 Beta では、ADO.NET Data Services v1.5 CTP2 を追加でインストールしてください。)
その他も開発に関する新機能はまだまだ多く、Beta が故の留意点などもいくつかありますが、この辺りの内容は、SharePoint Conference Japan 2009 でご紹介したいと思います。

SharePoint のことばかり書いていますが、Office クライアントそのものもかなり魅力的です。Excel 2010、PowerPoint 2010 等々エンドユーザー視点でも非常に魅力的ですが (すみません、書ききれないので省略します)、Office Web App、さらに、開発系の InfoPath 2010 などもリボンになったおかげでブロック単位にデザインテンプレートからデザインが選択できますし、Visio 2010 も、まあ使っていただくとわかります (マウスを上に横にと持っていかなくても その場でさくさく図面作成、などなど。。。)。

「百聞は一見に如かず」、新体験 (Experience) を手にとってお試しください。

 

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] プログラマーにとっての「型」にはまらない情報発信 (「技術」を もっと楽しく . . .)

こんにちは。

マイクロソフトからの開発者向けのニュースレターである MSDN Flash (2 週間に 1 度配信) ですが、今週号から、"プログラマー" の方にとって必要な情報を中心とした内容になっています。(以降はこのスタイルで継続されます。)

今週号の MSDN Flash :
http://msdn.microsoft.com/ja-jp/cc524082.aspx

ご存じの通り、マイクロソフトのテクノロジーは今や多種多様に存在しており、ある情報はエンドユーザーにとって、またある情報はシステム管理者の方にとって、など、さまざまな種類の情報が存在しますが、その中から、"開発者" にとって "真に必要になりそうな話題" や、プログラミングに関する情報をお届けする目的で、今月号より、リニューアル致しました。プログラミングを中心としたネタの充実もおこない、かつ 「開発者向けヘッドライン」もその週 (前回配信されて以降) のホットトピックを開発者目線で厳選していますので、ここ 1、2 週間のホットトピックも総括してみて頂くことができます。(無論、「Windows 7 リリース」などの万人にとって興味ある話題はちゃんと含めています。) また、いままで掲載していた社員の写真なども、"開発者にとって不要" な雑多な情報として今回から削除しました。
皆さんも多くのニュースレターを購読されているかもしれませんが、ここでは、"マイクロソフト技術をキャッチアップしたい開発者" にとって本来必要な情報を厳選して発信していきます。

また、このリニューアルとあわせ、プログラマーにとっての Code Sample を中心とした情報サイトも公開しました。

MSDN Code Recipe :
http://msdn.microsoft.com/ja-jp/samplecode.recipe.aspx

以前好評であった「300 秒 10 行でスバリ !!」シリーズも Visual Studio 2008 版として復活。現状はサービス開発、Web 開発を中心とした内容ですが、今後もデータアクセス技術、デスクトップアプリケーション開発、Azure 開発などさまざまな観点での300 秒 X 10 行の内容の追加や、「300 秒 10 行でスバリ !!」シリーズ以外のプログラミングトピックも含め、今後も "必要な情報" を厳選して、"情報氾濫" にならないように注意しつつ、充実させていきます。(今後の Visual Studio 2010 リリースにあわせて更新も予定しています。)

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] 「インストールマニアックス 3」応募開始

こんにちは。

Install Maniax 3 の応募が開始されました。
今回は、「Hyper-V 祭り」です。

Install Maniax 3 (Impress Business Media Corp.)
http://www.thinkit.co.jp/maniax/3/index.html

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] 11/28 CLR/H 札幌

こんにちは。

11/28 (土) に、コミュニティ「CLR/H 勉強会」 (in 札幌) にお邪魔させて頂きます。

第44回 CLR/H 勉強会 :
http://clr-h.jp/content/NextCLRH.aspx

同セミナーでは、 IT Pro エバンジェリスト高添による、"開発者に贈る" インフラセッション (勿論、テーマは 仮想化 ! です) や、砂金による PDC 発表直後の Windows Azure 最新情報など、非常に魅力的なセッションを北海道の開発者の方に向けて予定していますので、お時間ご都合のつく方は、是非、ご参加ください。

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] SharePoint 2010 Development Getting Started

こんにちは。

11 月に公開が予定されている SharePoint 2010 Beta 2 ですが、SharePoint 2010 による "開発" の各機能と実装テクノロジーをいち早く理解したい方に、Getting Started が公開されました。

MSDN : Get Started Developing on SharePoint 2010 :
http://msdn.microsoft.com/en-us/sharepoint/ee513147.aspx

この Get Started では、ハンズオン形式のステップバイステップのラボマニュアルや、先日このブログでもご紹介 した Paul Andrew のブログへのコードサンプルのリンクなどが含まれています。 

注意して頂きたい点は、SharePoint 2010 の "開発" のハンズオンラボであるという点です。SharePoint 2010 そのものの威力は、ご想像の通り、エンドユーザー / 業務管理者レベルのものも豊富に存在します。(圧倒的に広いビジネスシナリオに対応しています。)

これら開発者向けのラボですが、それぞれの機能の "意味"、"ビジネスインパクト" などを理解して頂いた上で見て頂くと、さらに実感を持って動かして頂くことができるかと思いますので、今後の SharePoint 2010 関連のイベント、セミナーなどご期待ください。

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

SharePoint 2010 における LINQ を使ったデータアクセス

環境 :
Windows 7 (x64)
SharePoint Server 2010 Beta 2
Visual Studio 2010 Beta 2

こんにちは。 

本日の Microsoft Develper Forum 2009 で紹介したデモのコード (の一部) を掲載しておきます。

今回お見せしたデモは、SharePoint Conference (in Las Vegas) のセッション "The Overview of the SharePoint 2010 Developer Platform" (スピーカー : Paul Andrew) のうちの一部を抜粋してご紹介しました。SharePoint 2010 は、開発関連も、魅力いっぱいの機能がたくさんありますので、ご興味がある方は、SharePoint 2010 のサイト や、Paul Andrew のブログ なども是非参照してみてください。
本日デモでお見せした他のコード (Data Services を使用したアクセス、など) をはじめ、その他のさまざまな開発トピック (まだまだ山ほどあります) については、11 月末に開催される日本でのイベント「Sharepoint Conference 2009 Japan」など、是非ご期待ください。

SharePoint 2010 を使用した LINQ を使ったデータアクセス

本日のデモの手順は、以下の通りです。SharePoint Server 2010 Beta 2 はまもなく公開されますので、是非、Visual Studio 2010 Beta 2 と共に、その進化した開発の世界を実感してください。

  1. Visual Studio 2010 を起動し、プロジェクトの新規作成で、[Visual C#] - [SharePoint] - [2010] から、[Visual Web Part] を選択します。 



    従来、SharePoint の Web パーツの開発は、ボタンなどのコントロールを配置なども含めコードを使用して作成するのが一般的でしたが、この [Visual Web Part] のプロジェクトでは、.ascx を使用してビジュアルな開発をおこなうことができます。.ascx ファイルも、SharePoint サーバー上の適切なフォルダ (mapped folder) に配置されます。

  2. 今回、この Web パーツでは、下図のように GridView と Button の各コントロールを配置してみましょう。ボタンを押した際に、データを検索して GridView 上に表示します。



  3. プロジェクトで [Add reference ...] (参照の追加) メニューを選択し、以下の Linq 用のライブラリ (.dll) を追加します。

    %programfiles%\common files\microsoft shared\web server extensions\14\isapi\microsoft.sharepoint.linq.dll

  4. Linq to SQL の sqlmetal コマンドと同様に、特定の SharePoint サイトに接続する専用のデータコンテキスト (DataContext) のコードを生成します。SharePoint 2010 Management Shell (SharePoint 用の PowerShell コマンド環境) を起動し、以下の通り、spmetal コマンドを実行します。(実は、今回から SharePoint の管理に PowerShell もバリバリ使えます。ここでは説明を省略します。)

    spmetal /web:http://localhost /namespace:Projects /code:Projects.cs

    今回は、http://localhost のSharePoint サイトを使用し、「Projects」の名前空間のクラスとして、Projects.cs の C# のコードファイルを生成しています。(このサイトで使用されているリスト、列などの情報がデータコンテキストとして抽出されます。)

      
  5. 上記で生成されたコード (Projects.cs) をプロジェクトに既存のアイテムとして追加します。

  6. ボタンクリック時のイベント処理として、今回、以下のようなコードを記述してみましょう。ここでは、SharePoint サイトの Employees リストから必要なデータを抽出して、GridView にバインドしています。(今回、GridView に何の設定もおこなっていませんので、GridView の列の自動生成がおこなわれます。)

    . . .
    using Projects;
    using System.Linq;
    using System.Text;

    protected void Button1_Click(object sender, EventArgs e)
    {
        ProjectsDataContext dc = new ProjectsDataContext("http://localhost/");
        IQueryable q = from c in dc.Employees
                       where c.Project.DueDate < DateTime.Now.AddMonths(6)
                       select new
                       {
                           Name = c.Title,
                           Job = c.JobTitle,
                           Team = c.Team
                       };
        GridView1.DataSource = q;
        GridView1.DataBind();    
    }

以上で完了です。このプロジェクトを SharePoint に配置してみましょう。
SharePoint の UI 上でこの作成した Web パーツを配置すると、下図のようにデータを検索して GridView にデータが表示されるのが確認できます。

ここでご紹介した手法は、前述したように SharePoint 2010 における進化のほんの一例です。(デモでは REST などもご紹介しました。)
今回ご紹介したデータアクセスまわりや、進化したワークフロー、バックエンドビジネスデータとの連携 (Business Connectivity Services = BCS) などを中心に、SharePoint 2010 を使用した開発では、これまでの難解な開発と異なり、一般のデータストアを扱う感覚で開発をおこなうことができます。(無論、まずは、"コードを書かずに" そのまま機能を理解し、その進化を実感して頂くことをお勧めします。エンドユーザーレベルで、かなりの範囲のソリューション構築が可能です。)
これまで 「SharePoint の開発は敷居が高い」、「むずかしい」 と思っていた方も、2010 からの SharePoint ではこのように一般的な手法を使用して簡単にソリューションを構築できるという点をまずは実感してください。(続きは、SharePoint Conference 2009 Japan で。。。)

 

Posted by tsmatsuz | 0 Comments
Filed under: , ,

[Info] 12 月号は、Windows 7 の省電力プログラミング

こんにちは。

日経ソフトウェアでの Windows 7 の連載記事ですが、今月号から、エバンジェリスト 岩田 と共に順次掲載していきます。12 月号は、Window 7 の省電力プログラミング (岩田の執筆) です。

http://itpro.nikkeibp.co.jp/article/MAG/20091022/339253/

省電力とプログラミングって、何か関係があるのでしょうか ? 勿論、オオアリです。
プログラミングテクニックを学ぶと共に、省電力に配慮しないプログラムがどんな弊害をもたらすか、など、内部の仕組みや概念などをご理解頂けると幸いです。

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] Visual Studio 2010, SharePoint 2010, そして . . .

こんにちは。

ブログの更新が滞ってしまい申し訳ありません。

訳あって出張しておりましたが、ここ 1 週間で開発者の方にとって大変いろいろと動きがあったと思います。以下に、この動きを整理して記載します。(セミナー、LT などを通して、皆さんに "オブラートに包んで表現していたこと" のいくつかも、以下の通りクリアになりました。スッキリ しない表現が多く、申し訳ありませんでした。。。)

Visual Studio 2010 Beta 2 がダウンロード開始 !

Visual Studio 2010 と .NET Framework 4.0 の Beta 2 の ダウンロード が開始されました。 
Beta 2 では、これまで Windows 7 の API Code Pack や COM 相互運用などでしかできなかった、.NET Framework での Windows 7 開発 (タスクバー、ジャンプリスト、ライブラリ等の開発) が標準でサポートされています。(エバンジェリスト 岩田がコードを紹介 していますので、是非参考にしてみてください。)

Visual Studio 2010 については、今後、イベント、セミナーなどを通し最新情報が紹介されてきますので、米国でまもなく開催予定の Professional Developer Conference 2009 (PDC 09)、日本で来年開催予定の Tech・Days 2010 など、今後のイベントに是非ご期待ください。

SharePoint 2010 Public Beta (Beta 2)、まもなく公開

SharePoint 2010 Beta 2 (Public Beta) も、まもなく公開予定です。(ラスベガスで開催されていた SharePoint Conference 2009 (10/19 - 10/22) で発表されました。)

新しい SharePoint では、フィーチャーマニフェストやソリューションマニフェストなどもビジュアル編集が可能で (従来は、XML の直接編集のみ)、Client API の提供や、LINQ での接続の提供 (LINQ to SharePoint)、Web パーツのビジュアル開発などなど、これまで開発者が "不自由" を感じていた多くの改善事項に加え、スケーラビリティ/アベイラビリティの向上 (「リスト」も含め)、REST 方式でのデータアクセスや連携、FAST 連携、Sandbox ソリューションの提供など、インターネット Facing やクラウド上のサーバー活用も意識した数多くの機能が追加されています。(先日、.NET ラボで現状報告をさせて頂いた「Web パーツのクライアント接続」なども、SharePoint 2010 からは、気にせず、柔軟に対応できます。)
発表された機能については、SharePoint チームブログ をはじめ、SharePoint MVP の山崎さんのブログクリエイルミネート・ブログ などでも記載されていますので、さわってみる前にいち早く知っておきたい方は、是非 Watch してみてください。

SharePoint 2010 についても、今後、イベント、セミナーなどを通し最新情報が紹介されてきますので、日本で開催予定の SharePoint Conference 2009 (日本) など、今後のイベント、セミナーに是非ご期待ください。

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

スケーラブルで "強い" WCF サービスの開発

こんにちは。

本投稿のテーマは、WCF サービスの開発で、"スケーラブルなサービス"、"ミッションクリティカルなサービス"、"結構大きなサービス" を作りはじめると、「いろいろと問題に遭遇する」という話題です。ここ数日で、実はこの話題が何度か取り上げられることがありましたので記載しておきます。

この内容は、実は 一昨年の Tech Ed (2 回前の Tech Ed) でお話したものですが、月日が経ち、皆さんも "本格的なサービス開発" に取り組まれてきて、同様の問題で "はまる" ケースも多くなってきているでしょう。Microsoft の開発ツールは常にそうですが、ウィザードなどで簡単に構成してくれますが、一方で、こうしたツールが構成するものは "初期開発を簡素化するための雛型" であって、トランザクション数の多い本格的なサービスを構築する場合にはチューニングが必要になってきます。よくある問題としては、先日ユーザーの方 (WCF サービスのノウハウをお持ちの開発者の方) も言われていましたが、「サービス (IIS) が応答しなくなる」とか、「異常に遅くなる」などのトラブルに遭遇することがあります。

ここで、一昨年前の Tech Ed でご紹介した 「WCF / WF を活用した実践的アプリケーションの開発」 の内容をあえて 今 おさらいしておきたいと思います。

必要最小限度の構成を

ここは、もっとも大切なポイントです。 (いろいろあるので、少し長くなりますが。。。)

Visual Studio が自動で作成する WCF サービスは、既定では WsHttpBinding を使用した構成になっています。この WsHttpBinding ですが、メッセージレベルのセキュリティ、分散アトミックトランザクションへの対応、などなど、数々の非機能要件に対処できる優れたバインディングですが、その一方で、「本来必要ない余計な処理」をおこなって重くなっている場合もあるので注意してください。

まず「バインディング」について正しく理解しておきましょう。WCF の通信メカニズムは、OSI のプロトコルスタックのように、「認証をおこなう」→「暗号化する」→「MTOM でエンコードする」→「HTTP で通信する」 といった各手順の組み合わせになっています。メッセージを受信した際には、この逆の処理がおこなわれます。(実際には、OSI とはまったくレイヤが異なります。あくまでも例として記載していますのでご注意を。) この各ステップを組み合わせたものが「バインディング」です。つまり、既定で存在している BasicHttpBinding、WsHttpBinding、NetTcpBinding などは、この各ステップが既に組み込まれた状態になっています。
もし皆さんが、「そろそろ WCF の仕組みもわかってきて、いろいろチューニングを」と思われるならば、CustomBinding もお勧めです。CustomBinding は、この各ステップを自分で組み合わせて通信する方法で、ある意味、上述のような「既定の余計な設定」を含んでおらず、必要なもののみを組み合わせることができます (勿論、自分で組み合わせる必要があるので、相応の知識が必要です)。例えば、以下は、バイナリでデータを渡し、HTTP で通信をするだけの、軽量な「myLightWeightBinding」という名前の独自のバインディングを構成しています。

<bindings>
  <customBinding>
    <binding name="myLightWeightBinding">
      <binaryMessageEncoding />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>

このカスタムバインディングを使わずに上述した既存のバインディング (WsHttpBinding など) を使って構成した場合には、チューニングの際に、既定で「オン」になっている数多くのプロパティなどを順番に「オフ」にしていく必要がありますが、カスタムバインディングを使えば、カスタムバインディングでは逆に、「必要なもののみをくみ上げていく」ことになるためチューニングもしやすく、かつ「何が使われているか」といった理解性もよくなります。

カスタムバインディングを使用せずに既定の構成を使用する場合は、不要な既定値はオフにしておいてください。例えば、各バインディングでは、接続 (Connection) の最適化のために、以下の既定値が設定されていますので、このあたりもチューニングに際してよく問題にされるポイントです。

  • 例えば BasicHttpBinding では、既定で HTTP の KeepAlive の設定がおこなわれており、一定のルールで接続されたままの状態になっています (つまり、これが原因で余計なサーバーリソースを消費している場合があります)。処理のスタイルを考慮し、断続的で頻繁な接続などが不要な場合には、この設定はかえって重くなりますので、keepAliveEnabled = false としてこの既定値をオフにしておいてください。
  • また WsHttpBinding では、上記の KeepAlive と同様に、セキュリティコンテキストと呼ばれるセッションのコンテキストが既定で保持されていて、セッション (状態を維持した処理) などで活用されています。これも不要な場合には、EstablishSecurityContext = false として「オフ」にしておきましょう (ただし false にすると、当然、「セッション」を保持した処理ができなくなります)
  • NetTcpBinding では、最適化のため、内部でコネクションが Pool  されていおり、既定では 5 分間保持されています。このプールが不要な場合も、カスタムバインディングを作成し、leaseTimeout でこのリリース時間をカスタムに設定する必要があります。

また、例えば、netTcpBinding では、認証として、既定で「Windows 認証」が使用されているなど、 「接続」(Connection)という観点以外にも認証、セキュリティ設定などの配慮が必要になります。

パフォーマンスだけに注目するならば、トランスポートレベルのバインド要素としては tcpTransport が最も高速で (注 : 同一ノード内なら namedPipeTransport がもっとも早そうに思われるかもしれませんが、必ずしもそうではありません)、エンコーディングについては、無論、BinaryMessageEncoding が早くなります。 

また、こうした WCF の構成以外にも、.config 内のその他の余計な構成 (例えば、よくあるケースは、使ってもいないのに Windows 認証がそのまま入っている、とか) は、パフォーマンス劣化という観点以外に、可読性という観点でもちゃんと削除しておきましょう。

クライアントサイドも必要最小限度に

クライアントサイドも似た留意点があてはまります。WCF をこれからはじめる多くの方が、下図のように [サービス参照の追加] によってクライアントプロキシを構成し、プログラミングをおこなうことでしょう。(私も、初学者の方向けの Web キャストではこの方法を紹介しています。)

この方法は無論、「いけないこと」ではありませんが、もし、クライアントからも呼び出しが頻繁におこなわれ、この点での最適化 (チューニング) も必要になりそうな大規模なアプリケーションの場合には、ChannelFactory を使用して自身で .config を構成して接続する方法をお勧めします。
パフォーマンスの面でも ChannelFactory を使用したほうが高速に処理されますが、よく陥る問題としては、複数のサービスへの接続や、頻繁な [サービス参照の更新] (サービス側のコントラクトが変更され、クライアント側でプロキシを作り直し) によって、.config がぐちゃぐちゃになってしまう (使っていない構成などが大量に残り、最終的に可読性が低下する) ことがあり、最悪なケースでは、そうしたぐちゃぐちゃな構成をそのまま本番用に適用する結果となり、メンテナンスやチューニングに際して大きなオーバーヘッドが発生するためです。

まめなテストと現象の解析

さらに、"大きなサービス" を構成する場合には、負荷テスト (及び、必要に応じ解析) も欠かさないようにしてください。構成が大きくなって原因が特定しづらい状況になってからでは遅い場合があります。以下でもご紹介しているように、Visual Studio のロードテストを使用すると、この一見「大変そうな」負荷テストも、プログラマーがいつでも簡単に実施することができます。

IT Pro 道場自主トレシリーズ : 負荷テストの実施
http://technet.microsoft.com/ja-jp/events/dd696124.aspx

普段からまめにテストを実施することで、「・・・の構成を入れたら動かなくなった」など、問題の特定もピンポイントになりますので、是非大きな開発ではこまめなテストを実施してプロジェクトを進めてください。

また、現象を解析する際に、WCF 内の細かな動き (上述したような、WCF 内のスタックの動き、など) を解析する必要がある場合には、トレースを出力して、Visual Studio (.NET Framework SDK) に付属しているサービストレースビューアツール (svctraceviewer.exe) を使用すると、内部の呼び出しのスタックや処理時刻などが確認できます。(メッセージのトレースも出力すると、どこでどの内容のメッセージが飛んだか確認することもできます。) 問題なく動作しているケースなどと比較して、「認証関連でやたらと時間がかかっている」など、どの処理がオーバーヘッドになっているか細かに確認できます。

さらに慣れてきたら、WCF Load Test Tool なども活用して、より効率的なテスト計画と反復テストをおこなうこともできます。

ワーカープロセスの最適化

WCF サービスでは、.svc を使って IIS にホストするケースも多いでしょう。この場合、ロードテスト (負荷テスト) により、前述したように、ワーカープロセスが肥大化して、応答しなくなってしまうケースがたまに発生することがあります。
こうした場合には、まず、ワーカープロセスの状態を確認してください。IIS 7 を使用されている場合には、インターネットインフォメーションサービスマネージャ (IIS 管理マネージャ) を起動して、下図の通り、ワーカープロセス内で実行されているスレッドや、それぞれのスレッドの状態などを確認できますので、この方法で問題を特定できる場合があります。(例えば、認証処理で止まっている、とか。) 

問題を特定したら、上述のように構成 (.config) を編集するなどして可能な最適化を実施し、それでもスレッドが追いつかない (スレッドが蓄積されて要求を処理しきれない) 場合には、負荷分散などを考慮する必要があります。

負荷の分散 (ロードバランス) 

要求が大量な場合、サービスに処理が蓄積され、要求をさばききれないケースがあります。この場合には、負荷の分散を検討する必要があります。

IIS ホストの場合には、非常に簡単にできる負荷分散の方法として、上述のワーカープロセス数を変更する手法があります。インターネットインフォメーションサービスマネージャ (IIS 管理マネージャ) のアプリケーションプールの詳細設定画面で、簡単にワーカープロセスの最大数を変更することが可能であり、既定ではこの値は「1」 になっています。(最大数を変更すると、要求が増えていくと、ワーカープロセス (w3wp.exe) が増加し、複数のプロセスで要求が処理されるようになります。)

一方、セルフホストの場合などには、下記の通り、スロットルを構成して処理のスループットを向上させる手法も可能です。

<behavior name="Throttled">
<serviceThrottling maxConcurrentCalls="1"
    maxConcurrentSessions="1"
    maxConcurrentInstances="1" />
</behavior>

また、ハードウェアロードバランシングや、NLB を構成するなどして、マシンをスケールアウトさせて処理を分散させることも、勿論、可能です。(StockTrader と呼ばれる WCF を使用した著名なサンプルでは、アプリケーション自身が要求を別のマシンに委譲させるような仕組みを独自に構築していますが、一般の負荷分散の仕組みを使用することも可能です。)

ただし、こうした負荷の分散をおこなうと、ステートを保持しているサービス (前の処理の結果によって次の結果が変わるようなサービス) では、要求ごとにプロセスが変わってしまい、期待しない結果を招く場合があるため、この制御をちゃんとおこなう必要が生じます。

ロードバランスされた状況での、状態 (ステート) の保持

そこで、"ロードバランスされた環境" でかつ、"ステート (状態) を効率的に維持" したいというケースが出てきますが、WCF には、こうした処理をおこなういくつかの手法があります。これについては、講演で解説の時間が充分とれなかったため "怪我の功名" と言いますか、一昨年前の Tech Ed セッションのフォローブログで記載していましたので、以下を参照してください。

http://blogs.msdn.com/tsmatsuz/archive/2008/08/27/t2-302-follow-up-wcf-asp-net-compatibility-model-stateful-n-tier-wcf-load-balancing.aspx

結論だけを述べると、いくつか手法が存在し、用途に応じて (例:永続化が必要、WF と一緒に使う、などなど) 使い分けることができますが、単にステートを維持する目的であれば、ASP.NET 互換モード (ASP.NET Compatibility Mode) の手法がもっとも "軽量" に動作します。

なお、"簡易な WCF サービス" で単に状態 (ステート) を維持したいだけであれば、Session を使用した WCF サービスを構築 (PerSession で WCF を構成) できますので、上記のような面倒な考察は不要です。("ロードバランスされた環境 (かつ、スティッキーでないケース)" という前提で記載しています。なお、「WCF のセッション」では、Web アプリケーションの Session オブジェクトは使用されていないため注意してください。Web アプリケーションの Session オブジェクトなどを使用したい場合に、上記の ASP.NET 互換モードを使用します。)

RESTful サービスの考慮

さて、話がどんどん面倒なほうに行ってしまいましたが、パフォーマンスや最適化を柔軟に構成する上で、REST による WCF サービスも視野に入れておくと良いでしょう。REST は、無論、 パフォーマンスをあげるために存在するアーキテクチャスタイルではありませんが、例えば、以下のような観点で、上述のような考察も "簡素化" してくれるというメリットがあります。特に商用サービスを提供するケースなどでは、他アプリからの接続性という観点など、さまざまなメリットもあわせて享受できる場合があります。

  • REST スタイルでは、処理のスタイルが明快です。例えば、上述したようなステート (状態) の維持といった観点は、実は、アーキテクチャスタイルを再設計すれば本来は不要かもしれません。 
  • このため、チューニングも容易です。例えば、IIS の設定を変更するなどして、"キャッシュ" (Cache) を有効活用できます。

 

上記は「チューニングのすべて」ではありませんが、いくつか代表的な手法をピックアップして紹介しました。一昨年前の Tech Ed でもお話しましたが、WCF は、実は、高速に処理できるように過去のテクノロジーよりもさまざまな観点で最適化されています。データの受け渡しも、XmlDocument を使用しないストリームによるパース、接続情報のキャッシュ、など、さまざまな最適化を内部で実施しています。しかし、上述した構成の話など、条件によっては、過去のテクノロジーより遅くなってしまうケースがあるので注意してください。(例えば、DataSet などの型定義がゆるい情報の受け渡しでは、こうしたメリットが損なわれてしまいます。バインディング構成によっても遅くなります。)

 

 

Posted by tsmatsuz | 1 Comments
Filed under: ,

SharePoint : クライアントサイドでの Web パーツ接続

環境 :
Office SharePoint Server 2007
Visual Studio 2008
Visual Studio extension for Windows SharePoint Services (VSeWSS) 1.2

[Download Sample : SampleClientWebPartConnection.zip ]

こんにちは。

以下、仕事の関連で話題になりましたので、方法をメモとして記載しておきます。。。

ここでは、Client サイドの Web パーツ接続 (WebParts Connection) について説明します。現在、Web パーツを AJAX, Silverlight などを使用して構築しているケースも多いと思いますが、こうした場合に有効な手段となるでしょう。

事前知識

まず、セミナーなどでもご説明しているように、Windows SharePoint Services 3.0 (Office SharePoint Server 2007) 以降の SharePoint テクノロジーは、従来の SharePoint テクノロジーとの互換性を意識しつつ、.NET の Web 開発テクノロジーである "ASP.NET" とさまざまな面で "美しく" 統合されています。「Web パーツ」もこうした ASP.NET と "美しく" 統合されたテクノロジー・コンポーネントの 1 つであり、この辺りの知識については、下記のテックフィールダーズコラムで簡単に説明していますので参考にしてください。

Web パーツとフィーチャーフレームワーク :
http://www.microsoft.com/japan/powerpro/TF/column/tm_03_2.mspx

このため、MOSS 2007 (WSS 3.0) の Web パーツでは、ASP.NET の WebPart クラスを継承して、SharePoint の Web パーツとして開発・配置をおこなうことが可能です。こう書くと、もはや、あの面倒な "SharePoint の WebPart" はレガシー対応でしか存在していないと言った感じですが、"SharePoint の WebPart クラス" を使用すると、実は、SharePoint でしか使えない幾つかの機能を使用することができるため、こうした目的でこのクラスを使用することができます。(ただし、こうした開発は必要最小限度に留めておきましょう。。。)
そうした機能の 1 つが、今回ご紹介する Web パーツのクライアント側での接続 (Client Connection) です。

なお、"ASP.NET の WebPart クラス" を継承した標準的な Web パーツ作成と、Web パーツどうしの接続のプログラミング方法は、以前、下記の投稿で方法とコードを掲載しています。この投稿で記載している「プロバイダー」と「コンシューマ」の概念などは、"SharePoint の WebPart クラス" でも同様に必要な概念ですので基本をおさえておいてください。

SharePoint における実用的なカスタム Web パーツ (WebPart) の開発 :
http://blogs.msdn.com/tsmatsuz/archive/2007/09/12/sharepoint-web.aspx

では、本題に入っていきましょう。まず、"SharePoint の WebPart クラス" を継承したプログラミング方法ですが、これについては、以下の MSDN の記事が参考になります。

[ウォークスルー] 接続可能な Windows SharePoint Services の Web パーツを作成する
http://msdn.microsoft.com/ja-jp/library/ms469765.aspx

コードの細かな点はとりあえず置いておき、ポイントのみを記載すると、このサンプル (上記のウォークスルーのサンプル) では、ICellProvider, ICellConsumer インタフェースを実装して、相互に接続可能な「プロバイダー Web パーツ」と「コンシューマー Web パーツ」を開発していますが、これら ICellProvider、ICellConsumer 以外の他のインタフェースを使用すると、前述の投稿 (SharePoint における実用的なカスタム Web パーツの開発) でも説明しているように、さまざまなタイプのプロパティ (例 : リストそのものや、リストの行、リストの特定の列の値、フィルターの値、など) と接続可能なさまざまな Web パーツをプログラミングすることができます。
実は、この ICellProvider、ICellConsumer は、"古いインタフェース" であり、標準的な ASP.NET の Web パーツ開発では、 前述の投稿 (SharePoint における実用的なカスタム Web パーツの開発) の中でも記載しているように、IWebPartField などの ASP.NET のインタフェースを使用しますので注意してください。

クライアント接続のプログラミング (Programming)

さて、上記のウォークスルーのサンプルの中でも、実は、既にクライアント接続用のコードが記載 (サーバー接続用のコードと混在) されていますが、今回は話を簡単にするため、このクライアント接続の部分のコードのみにフォーカスを当て、より簡単なサンプルで説明します。

まずは、いきなりですが、プロバイダー (Provider) Web パーツ側のサンプルコードを以下に記載します。

. . . . .
using Microsoft.SharePoint.WebPartPages.Communication;

namespace ClientConnectionWebPart
{
  [Guid("9ddf3991-37ad-49db-9993-e874b65893b6")]
  public class SampleProviderWebPart : Microsoft.SharePoint.WebPartPages.WebPart, ICellProvider
  {
    [Obsolete]
    public override void EnsureInterfaces()
    {
      RegisterInterface("MyCellProvider_WPQ_",
         InterfaceTypes.ICellProvider,
         Microsoft.SharePoint.WebPartPages.WebPart.LimitOneConnection,
         ConnectionRunAt.Client,
         this,
         "CellProvider_WPQ_",
         "Send to MyCellConsumer",
         "this is test");
    }

    [Obsolete]
    public override ConnectionRunAt CanRunAt()
    {
      return ConnectionRunAt.Client;
    }

    [Obsolete]
    public override void PartCommunicationConnect(string interfaceName, Microsoft.SharePoint.WebPartPages.WebPart connectedPart, string connectedInterfaceName, ConnectionRunAt runAt)
    {
      if (runAt == ConnectionRunAt.Client)
      {
        // 接続時に呼ばれるため、接続時の処理はここに書きます。
        // 今回は、何もしない . . .
      }
      EnsureChildControls(); // <-- 今回は、なくても良い
    }

    [Obsolete]
    public override void PartCommunicationInit()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    [Obsolete]
    public override void PartCommunicationMain()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    protected override void RenderWebPart(HtmlTextWriter output)
    {
      EnsureChildControls(); // <-- 今回は、なくても良い

      output.Write(ReplaceTokens(
        "<select id='MySelect_WPQ_' onchange='MenuChange_WPQ_()'>\n" +
        "<option value='1'>1番選択</option>\n" +
        "<option value='2'>2番選択</option>\n" +
        "</select>"));

      output.Write(ReplaceTokens(
        "<script language='javascript'>\n" +

        "var CellProvider_WPQ_ = new funcCellProvider_WPQ_();\n" +
        "function funcCellProvider_WPQ_() {\n" +

        "  this.PartCommunicationInit = myInit;\n" +
        "  this.PartCommunicationMain = myMain;\n" +
        "  this.CellConsumerInit = myCellConsumerInit;\n" +

        "  function myInit() {\n" +
        "  var cellProviderInitArgs = new Object();\n" +
        "  cellProviderInitArgs.FieldName = 'CellName';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellProviderInit', cellProviderInitArgs);\n" +
        "  }\n" +

        "  function myMain() {\n" +
        "  var cellReadyArgs = new Object();\n" +
        "  cellReadyArgs.Cell = '';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellReady', cellReadyArgs);\n" +
        "  }\n" +

        "  function myCellConsumerInit(sender, cellConsumerInitArgs) { }\n" +

        "}\n" +

        "function MenuChange_WPQ_() {\n" +
        "  var cellReadyArgs = new Object();" +
        "  cellReadyArgs.Cell = document.all('MySelect_WPQ_').value;\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellReady', cellReadyArgs);\n" +
        "}\n" +

        "</script>\n"));
    }

    #region ICellProvider メンバ

    // 以下はいずれも、クライアント側の接続では呼ばれません
    // (サーバー側の接続の場合のみ、実装)
    public void CellConsumerInit(object sender, CellConsumerInitEventArgs cellConsumerInitEventArgs)
    {
    }
    public event CellProviderInitEventHandler CellProviderInit;
    public event CellReadyEventHandler CellReady;

    #endregion
  }
}

上記のコードを説明します。

まず、"SharePoint の Web パーツ" ですから、SharePoint の WebPart クラスを継承し、今回は、ICellProvider インタフェース (特定の列の値と接続可能なインタフェース) を実装しています。

EnsureInterfaces オーバーライドメソッドでは、この Web パーツがいったい何者であるかを返しています。EnsureInterfaces の 6 番目の引数の "CellProvider_WPQ_" は、イベントが発生した場合に処理されるクライアント側 (JavaScript 側) のクラスを示しており、今回は、コンシューマ側がイベントを投げると、このプロバイダーの CellProvider_WPQ_ のクラス (JavaScript のオブジェクト) でイベントが処理されることになります。

上記で、_WPQ_ は、非常に重要なキーワードです。このキーワードは、SharePoint により一意な ID に書き換えられます。これにより、同一の Web パーツが複数存在しているケースなど、さまざまなケースで矛盾がなく処理されるようになりますので、関数名、オブジェクト名など、一意性が求められる箇所にはこのキーワードを入れておきましょう。(上記の RenderWebPart オーバーライドメソッドにおける ReplaceTokens では、この書き換えを明示的に指定しています。)

Obsolete 属性は、"古いメソッド" などを使用している場合に警告を表示しないために使用しているオマジナイだと思ってください。前述したように、ICellProvider 自体も古いインタフェースであり、Obsolete でビルドメッセージを指定しないと、ビルド時に、"廃棄予定のメソッドである" などのメッセージが表示されることになるでしょう。

RenderWebPart オーバーライドメソッドに記載されているコードは最も重要です。(というか、今回はクライアント側の処理のため、ここに処理のほとんどが書かれています。) 通常のサーバー側の Web パーツでは、Web パーツの初期化がおこなわれた際に呼ばれる PartCommunicationInit メソッドや、選択項目が変更された際などに呼ばれるメイン処理の PartCommunicationMain メソッドなどのオーバーライドメソッドをプログラミングしますが、クライアントサイドの接続では、こうした処理はすべて JavaScript で記述することになります (このフレームワークの JavaScript ライブラリが SharePoint によって内部で提供されます)。このため、このフレームワークと連携して動作する処理を  "JavaScript として"  RenderWebPart メソッドで出力しています。

この JavaScript の処理についてですが、this.PartCommunicationInit は Web パーツの初期化がおこなわれた際に呼ばれる処理で、this.PartCommunicationMain は初期化後の状態の変更通知などで呼ばれるメイン処理です。いずれのメソッドも、それをコンシューマー Web パーツに通知するため、WPSC.RaiseConnectionEvent (SharePoint の組み込みの JavaScript 関数) を呼び出しています。
また、CellConsumerInit メソッドは、逆に、コンシューマ側から通知されるイベント処理で、今回、ここでは特に処理はおこなっていません。
メニュー (select タグの項目) が変更されると、RadioOnClick_WPQ_ 関数により、PartCommunicationMain の処理と同様、CellReady のイベントをコンシューマ Web パーツに通知し、この際、引数としてメニューで選択された値を送信しています。
(なお、ここではクライアントのコードで説明していますが、サーバー側の実装でも、上記と同様の概念で、PartCommunicationInit、PartCommunicationMain などを使用するので、この動作概念はおぼえておくと良いでしょう。サーバー側の実装の場合、コントロールの再描画時などに自動的に PartCommunicationMain が呼ばれるので、コントロール側では、単にポストバックをおこなうように実装すれば良いでしょう。。。)

つぎに、コンシューマ (Consumer) 側のコードを記載してみましょう。

. . . . .
using Microsoft.SharePoint.WebPartPages.Communication;

namespace ClientConnectionSample
{
  [Guid("0bab1085-f5f8-42ba-a406-9c6f8619121e")]
  public class SampleConsumerWebPart : Microsoft.SharePoint.WebPartPages.WebPart, ICellConsumer
  {
    [Obsolete]
    public override void EnsureInterfaces()
    {
      RegisterInterface("MyCellConsumer_WPQ_",
        InterfaceTypes.ICellConsumer,
        Microsoft.SharePoint.WebPartPages.WebPart.LimitOneConnection,
        ConnectionRunAt.Client,
        this,
        "CellConsumer_WPQ_",
        "Receive from MyCellProvider",
        "this is test");
    }

    [Obsolete]
    public override ConnectionRunAt CanRunAt()
    {
      return ConnectionRunAt.Client;
    }

    [Obsolete]
    public override void PartCommunicationConnect(string interfaceName, Microsoft.SharePoint.WebPartPages.WebPart connectedPart, string connectedInterfaceName, ConnectionRunAt runAt)
    {
      if (runAt == ConnectionRunAt.Client)
      {
        // 接続時に呼ばれるため、接続時の処理はここに書きます。
        // 今回は、何もしない . . .
      }
      EnsureChildControls(); // <-- 今回は、なくても良い
    }

    [Obsolete]
    public override void PartCommunicationInit()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    protected override void RenderWebPart(HtmlTextWriter output)
    {
      EnsureChildControls(); // <-- 今回は、なくても良い

      output.Write(ReplaceTokens("<input type='text' id='MyText_WPQ_' />\n"));

      output.Write(ReplaceTokens(
        "<script language='javascript'>\n" +

        "var CellConsumer_WPQ_ = new funcCellConsumer_WPQ_();\n" +
        "function funcCellConsumer_WPQ_() {\n" +

        "  this.PartCommunicationInit = myInit;\n" +
        "  this.CellProviderInit = myCellProviderInit;\n" +
        "  this.CellReady = myCellReady;\n" +

        "  function myInit() {\n" +
        "  var cellConsumerInitArgs = new Object();\n" +
        "  cellConsumerInitArgs.FieldName = 'CellName';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellConsumer_WPQ_', 'CellConsumerInit', cellConsumerInitArgs);\n" +
        "  }\n" +

        "  function myCellProviderInit(sender, cellProviderInitArgs) { }\n" +

        "  function myCellReady(sender, cellReadyArgs) {\n" +
        "  document.all('MyText_WPQ_').value = cellReadyArgs.Cell;\n" +
        "  }\n" +

        "}\n" +

        "</script>\n"));
    }

    #region ICellConsumer メンバ

    // 以下はいずれも、クライアント側の接続では呼ばれません
    // (サーバー側の接続の場合のみ、実装)
    public event CellConsumerInitEventHandler CellConsumerInit;
    public void CellProviderInit(object sender, CellProviderInitEventArgs cellProviderInitArgs)
    {
    }
    public void CellReady(object sender, CellReadyEventArgs cellReadyArgs)
    {
    }

    #endregion
  }
}

コンシューマ側も、考え方はまったく同様です。プロバイダー側のコードを理解できた方は、こちらのコードも簡単に理解できたのではないでしょうか。

コンシューマ側では、上述したプロバイダー側からの初期化のイベント処理 (PartCommunicationInit 関数が渡した CellProviderInit イベント) とメインのイベント処理 (PartCommunicationMain 関数が渡した CellReady イベント) が呼び出されますので、これらのイベント処理を JavaScript で記述しています。今回は、CellReady のイベント処理で、テキストボックスに、渡された値 (引数) をそのまま設定するように記載しています。

このプロバイダー Web パーツとコンシューマ Web パーツを SharePoint に配置し、相互の接続をおこなって動作をさせると、下図の通り、選択欄 (メニュー) が変更された際に、テキストボックスに選択した値が入力されます。(ページのポストバックはおこなわれません。)

なお、既存のリストビュー Web パーツ (ListViewWebPart) では、残念ながら、サーバー側での Web パーツ接続しかサポートしていないようですので (ConnectionRunAt.Server または、ConnectionRunAt.ServerAndClient のみ対応)、
この自作のクライアントサイドの Web パーツと接続することはできませんので注意してください。

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

[記事紹介] Windows 7、アプリケーション互換性の Tips ! Tips ! Tips !

こんにちは。

Windows 7 のアプリケーション開発の視点での「互換性」情報について、「マニフェスト編集」、「セッション 0 の分離」、などなど、既に、"概要レベル" のドキュメントは多くの方が目を通されたかと思います。

今回ご紹介する記事は、現実のアプリケーション開発をおこなう上で実際にどのような点に遭遇し、それぞれをどのように考えていくか、という Tips を列記したものです。

Windows 7 : 製品ソフト開発者から出た "その疑問" にズバリお答えします !
http://www.microsoft.com/japan/powerpro/TF/column/ro2_01_1.mspx

マイクロソフトでは、新しい OS のリリースに際して、リリースのかなり前の段階から早期導入と検証のためのプログラムがおこなわれています。日本の多くのベンダの方、ソフトウェア開発者の方も参加されており、皆さんがお持ちの実際のアプリケーションを使用して、検証や、窓口での Q & A がおこなわれ、この段階での Q & A の多くは、実際に開発に関与している (マイクロソフトの) 開発部門が多く対応しています。上記の記事は、こうした多くのソフトウェア開発者の皆さんからフィードバックのあった "現実の課題" のうちの代表的なものを各回にわけて連載しています。
第1回は、Windows Vista から変更された Tips 系の話について、「セットアップ関連での注意点」、「削除された細かな機能群」、帳票文化の日本のお客さんにとっては重要な 「フォントの話」 にわけて、記載されています。(Windows Vista で追加・変更された機能ではありません。。。)

「もう知ってる、そんなこと」、「知らなかった、そんなこと!」など、いろいろな内容が含まれているかと思いますが、単なる変更点の列挙ではなく、「実際にどのような場合に、どんな問題に遭遇するのか」といった視点で記載されています。これから Window 7 対応のアプリケーション開発をお考えの方は、是非参考にしてみてください。

 

Posted by tsmatsuz | 0 Comments
Filed under:

[ブログ紹介] Scott Gu の VS 2010 and .NET 4.0 シリーズ

こんにちは。

特に新しい技術をキャッチアップされている方にとっては、次期 Visual Studio 2010、.NET Framework 4.0 について、いろいろと待望の機能なども多いことでしょう。日本のイベントでもいくつかご紹介をしてきましたが (Tech Ed 2009 では、新村 の 「Visual Studio 2010 & .NET Framework 4 概要」 のセッションでまとめて紹介させました)、「仕事が忙しくてイベントに出ていられない。。。」という方、「気になるけど、イベントに通うほどマイクロソフトにハマっているわけでは。。。」 という方も居られるでしょう。MSDN の記事を端から端まで読むわけにも。。。

そんな方は、Scott Gu が、自身のブログの中で、新しくなった Visual Studio 2010、.NET Framework 4.0 の新機能を中心に、いち早く、シリーズを掲載してくれています。

ScottGu's Blog : VS 2010 and .NET 4 Series
http://weblogs.asp.net/scottgu/archive/2009/08/25/vs-2010-and-net-4-series.aspx

次期 Visual Studio 2010、.NET Framework 4.0 については今後も日本のイベントなどで順次 情報発信がおこなわれると思いますが、先行でキャッチアップしたい方、机の上で "自分のペースで" "ポイントにしぼって" 読みたい方には、ためになる投稿がどんどん出てくると思います。

 

Posted by tsmatsuz | 2 Comments
Filed under:

技術を理解して、正しく判断 . . .

こんにちは。

本日、Tech Ed 「IT ヒーローラウンジ」でご紹介した本は以下になります。

.NET 開発テクノロジ入門 (日経BPソフトプレス)
http://astore.amazon.co.jp/press096-22/detail/4891006609

こちら、本日は Tech Ed ということで、.NET な開発者向けの紹介でしたが、Java, PHP (Zend) など、他のテクノロジに周知されている方も、ASP.NET MVC, ADO.NET Data Services は勿論、その他のテクノロジも、是非新鮮な感覚で内容に接して頂ければと思います。(これイケてる ! 時代遅れ ? など、セミナーなどを通し、さまざまなフィードバックをお待ちしています。)

昨今、言語を問わず、多くのテクノロジやアイデアがあり翻弄されてしまいそうですが (大変な時代ですね。。。)、まわりの技術やアイデアを理解せず (触れず) に殻に籠ってしまうことと、それぞれの技術 (良い点、悪い点) を理解した上で最適なものを選択する (もしくは、選択しない) ことには大きな差異があります。著者陣の一人として、皆さんにも、是非、そうした "広い視点" を持って技術と接して頂ければと思います。(これは、OS、データベース、など分野を問いません。)

ご参考 : 「中堅企業向け オラクル都市伝説シーズン2: 其の一」への反論
http://blogs.technet.com/sqlpm-j/archive/2009/08/27/3277427.aspx

 

Posted by tsmatsuz | 0 Comments
Filed under:

【T2-311補足】 msi ファイル (Windows Installer) の 64 bit 向けカスタマイズ

こんにちは。

Tech Ed 2009 セッション T2-311 で紹介が途中となった 64 ビット環境向けの msi のカスタマイズ手順、および紹介できなかったその他の要素について補足します。

msi ファイルの超概要

セッションでもご紹介したように、Windows インストーラの msi ファイルは、テーブルなどが多数含まれたデータベースファイルの構造になっています。
Visual Studio では、こうしたインストーラで必要となるテーブルの内容やプロパティなどの設定を簡素化しているため意識しませんが、msi ファイルの内容を細かくカスタマイズする必要が生じた場合にはこうしたテーブルの内容などをカスタマイズできるツールを使用して構成しなければならないケースがあります。

こうしたカスタマイズをおこなえるツールはいくつか存在しますが、ここでは、Windows SDK に付属の「Orca」というツールを使用して例示します。

カスタマイズの概要 (インストールファイルの例)

では、実際に例をみてみましょう。(下記の例は、一見、64 bit とは無関係ですが、64 bit 環境のためのカスタマイズでも必要になる場合があります。)

例えば、ファイルのインストール先ディレクトリを変更する方法を考えてみましょう。この設定には、msi の中の File テーブル、Component テーブル、Directory テーブルなどを使用します。ここでは、インストールされるモジュール (.exe など) を c:\work のディレクトリにインストールするように変更してみましょう。

まず、Orca を起動して、Visual Studio などで作成された .msi ファイルを開いてください。
そして、File テーブルを参照すると、インストールされるモジュールの Component 名が Component_ 列 (下記) に記載されているのがわかります。

このコンポーネント名は Component テーブルで参照できます。さらに、Component テーブルの Directory_ 列にディレクトリ名が記載されていますので、つぎに、このディレクトリの情報を Directory テーブルで参照します。

Directory テーブルには、Directory 列、Directory_Parent 列、DefaultDir 列を持っており、それぞれ以下の内容が記載されています。

  • Directory 列 :
    その Directory の名前が入っています。
  • Directory_Parent 列 :
    親のディレクトリの名前 (上記) が入っています。ここをブランクにすると、親を持たないルートディレクトリであることを示します。
  • DefaultDir 列 :
    ここにディレクトリを指定します。一般に Directory_Parent に対するサブディレクトリを指定しますが、ターゲットディレクトリ (インストール先) とソースディレクトリ (インストール元) があり、それぞれをコロン (:) を使用して  targetpath:sourcepath の形式で指定します。(コロンを入れない場合には、双方のサブディレクトリになります。)

例えば、Visual Studio で作成したばかりの .msi ファイルは以下のような感じになっているでしょう。


上図で、パイプ文字 ( | ) で区切られている箇所は、short name と actual name を指しています。

上図では、約束語がたくさん含まれていますので注意してください。
まず、TARGETDIR ですが、ここには、インストーラ実行時に外部 (コマンドラインのオプションや、インストーラの画面) から指定するインストール先のターゲットディレクトリが設定されることを意味しています。また、SourceDir も、インストーラのソースディレクトリのパスで上書きされます。さらに、ショートカットの作成などで使用するプログラムメニュー (ProgramMenuFolder) やデスクトップ (DesktopFolder) のディレクトリなども上記で指定されていますが、これらもそれぞれの環境にあわせて書き換えられます。(なお、作成されるショートカットは、上記の File テーブルでなく、Shortcut テーブル内で指定されています。)

これらの詳細については、以下に記載されています。

Using the Directory Table :
http://msdn.microsoft.com/en-us/library/aa372452(VS.85).aspx

今回は、c:\work にインストールするため、この Directory テーブルに [Add Row] メニューで行を追加し、以下の 2 行を追加してみましょう。

Direcrory Directory_Parent DefaultDir
root (ブランク) SourceDir
work root work:.

1 行目は、ルートドライブ (この場合、C:\ と仮定) がターゲットとして設定され、2 行目で c:\work がターゲットに指定されます。

あとは、この「work」を Component テーブルの Directory_ 列に設定して終了です。

上記は 64 bit とは何ら関係のないサンプルでしたが、例えば、x86 用と x64 用でインストールするモジュールを変える場合には、Directory テーブルで x86 用と x64 用の両方のソースの指定を用意しておき (さらに、それぞれを同じターゲットにインストールするように設定し)、Component テーブルの Condition 列を使用してコンポーネントのインストール条件を設定することで、環境にあわせてそれぞれ別のソースからコピーをおこなうように指定することになるでしょう。

64 bit 用のカスタム動作の設定 (マネージコードの場合)

では、デモでさらりと流した「64 bit 環境用のカスタム動作の設定手順」を復習し、紹介できなかった他の設定方法などもご紹介します。

カスタム動作 (カスタムアクション) は、ご紹介したように CustomAction テーブルに記載されており、インストール時、アンインストール時などの各アクションと、アクションで使用するソース (Source) が下記の通り指定されています。

そして、上記の Source の情報は Binary テーブルに記述されており (下図)、下記の Data 列に、実行されるバイナリデータが入っています。

セッション(デモ)で見ていただいたように、マネージコードのアクションの場合、既定では、このバイナリデータとして、

%windir%\Microsoft.NET\Framework\v2.0.50727\InstallUtilLib.dll

が設定されています。このため、カスタム動作を動かすと、ファイルはリダイレクトされたり、32 bit 用の ngen.exe が実行されるなど、64 ビット環境にあわない動きをすることになるでしょう。(ご紹介したように、Visual Studio のコマンドプロンプトも 32 bit 用の Framework にパスが通っていますので混乱しないよう注意してください。Visual Studio 2010 がどうなるかは、現時点では未定です。)

従って、Orca を使用して、この Binary Data を 64 bit 用の

%windir%\Microsoft.NET\Framework64\v2.0.50727\InstallUtilLib.dll

に変更することでこれらは解決されます。

セッションのデモでは上記の方法を紹介しましたが、例えば、アクションによって 32 bit, 64 bit をわけて実行したい場合などには Binary テーブルの行を追加して、CustomAction テーブルで使用する Binary を用途にわけて設定すれば双方のアクションを実行することもできます。

 

Posted by tsmatsuz | 2 Comments
Filed under:
More Posts Next page »
 
Page view tracker