Windows Workflow Foundation 4.5

[アーティクル]
09/30/2015

Windows Workflow Foundation 4.5 の新機能

コードサンプルのダウンロード

昨年 9 月に開催された BUILD カンファレンス (buildwindows.com、英語) で、マイクロソフトは次期バージョンの Windows Workflow Foundation (WF 4.5) を発表し、Windows 8 Developer Preview の一部としてパブリックプレビューを公開しました (msdn.microsoft.com/windows/apps/br229516、英語)。この記事では、WF 4.5 で追加された主な新機能を紹介します。ここでは全般的な機能を取り上げます。機能セットの大きさの関係上各機能を簡単にしか説明できませんが、この記事を楽しまれ、Windows 8 Developer Preview をダウンロードして WF 4.5 を試していただければさいわいです。

WF の過去、現在、そして未来

2010 年にリリースされた WF 4 は、開発者コミュニティからすばらしい歓迎を受けました。WF 4 は、前のバージョン (WF 3.5) に比べて大幅に機能が強化されていました。たとえば、ランタイムの機能強化、全体的なパフォーマンスの向上、アクティビティ作成の簡略化、Windows Communication Foundation (WCF) との全面統合、宣言による作成、デザイナーの再ホストの大幅な簡略化などです。2011 年には、Microsoft .NET Framework 4 Platform Update 1 で完全な機能を備えた StateMachine を公開し、現在はフレームワーク内の他のコンポーネントと変わらない品質とサポート保証体制で提供しています。WF 4.5 では、ユーザーから寄せられた大きな問題点の解決を目標としています。また、クラウドで WF がフル活用されるようにすることにも取り組んできました。開発チームによるこれまでの成果については、BUILD で行われた優れたプレゼンテーションをご覧ください (bit.ly/rbJROw、英語)。

今回の記事をお読みになると、きっと WF 4 と WF 4.5 との互換性について気になることと思います。ご安心ください。これらのバージョンは同じコードベース上で構築され、完全に互換性があります。WF 4 に対するすべての投資は WF 4.5 でも無駄にならず、変更する必要もありません。

WF 4 の公開後多数のフィードバックが寄せられたため、マイクロソフトではこれらのフィードバックを基に次期リリースの計画を立てました。WF 4.5 では、フィードバックで特に懸念されていた問題に対処し、ワークフローアプリケーションの構築に最適なフレームワークを提供する機能を追加しています。図 1 は、ユーザーから寄せられた要望と、マイクロソフトが要望に応えて作成した機能を示しています。

図 1 ユーザーからの要望とWF 4.5 の新機能

テーマ	要望	機能
作成機能の強化	プロジェクトの言語に応じた式	C# 式
	既存のコントラクトに基づくワークフローサービスの作成	コントラクトファースト
	デザイナー画面でのアクティビティへのコメントの追加	注釈
	WF デザイナーのより効率的な使用 (特に、大規模ワークフローの移動)	Auto-connect (自動接続)、Auto-insert (自動挿入)、Pan (パン)、ツリービュー、Auto-surround with sequence (シーケンスへの自動挿入)
	ワークフローデザイナーでの検索統合	検索
	デザイナーのワークフローにエラーが存在する場合のビルドの中断	ビルドの統合
	StateMachine ワークフローの作成	StateMachine
バージョン管理	バージョン管理用の基本構成要素	WorkflowIdentity
	サイドバイサイドでの複数バージョンのワークフローのホスト	WFSH によるバージョン管理のサポート
	ワークフローの実行中のインスタンスの新しい定義への更新	Dynamic Update (動的更新)
ランタイムの機能強化	部分的な信頼でのワークフロー実行	部分的な信頼のサポート
	独自の式編集方法の実現	式の拡張性
	ランタイムのパフォーマンス向上	Visual Basic 式のパフォーマンス向上

この表はテーマごとに分類しています。ここからはこの表のテーマに沿って特に重要な機能を紹介します。

作成機能の強化

C# 式: WF 4 では、Visual Basic を使用して式を記述でき、Visual Studio で Visual Basic 式を使用する場合は、式エディターでオートコンプリートや IntelliSense など通常使用可能なすべての言語サービスを利用できました。しかし、WF 4 のユーザーから「Visual Basic よりも C# で記述したい」という要望が寄せられたため、C# 式のサポートを追加しました。WF 4.5 では、C# プロジェクトを作成するとワークフローに C# 式が表示されます。ただし、このバージョンでも Visual Basic プロジェクトを作成した場合は Visual Basic 式になるので、ご安心ください。C# のサポートには、通常の言語サービスも含まれます (図 2 参照)。IntelliSense のボックスに、string.Format に対する 2 つ目の C# オーバーロードが表示されているのがわかります。

C# Expressions in a Workflow 図 2 ワークフローでの C# 式

C# 式を試すのであれば、C# のワークフロープロジェクトを作成するだけです。この記事に付属しているコードの CSharpExpressions プロジェクトを開いても C# 式を試すことができます。

コントラクトファーストによるサービス作成: WF 4 は、WCF と密接に統合されています。1 行もコードを記述しなくても、WF の全機能 (長時間の実行、永続性のある状態、宣言による作成、および実行の可視化) を利用する WCF サービスを作成できます (「WCF と WF 4 によるワークフローのビジュアルデザイン」(msdn.microsoft.com/magazine/ff646977) を参照してください)。WF 4 でワークフローサービスを作成する場合、ワークフロー定義からサービスコントラクトが推論されます。ホストを起動すると、ホストによってワークフロー定義内のメッセージングアクティビティが検索され、対応するコントラクトが公開されます (たとえば、Receive アクティビティはサービス操作に変換されます)。

多くのユーザーから、ワークフローサービスを既存の WCF サービスコントラクトから作成したい (ワークフローはそのコントラクトを実装する方法の 1 つに過ぎない) という要望が寄せられたことから、WF 4.5 では、"コントラクトファースト" によるサービス作成を追加しました。WF 4.5 では、WCF サービスコントラクト定義をワークフロープロジェクトにインポートすると、そのコントラクトが 1 つ以上のワークフローサービスに実装されるようにすることができます。この新しいワークフローサービス作成手法は、ワークフローファーストの手法に代わるものではありません。

WF のコントラクトファーストは、次の 2 つの手順で構成されます。前半で、コントラクト (通常の WCF サービスコントラクト) への参照をプロジェクトに追加し、後半でサービスでコントラクトを実装します。

コントラクトをインポートするには、プロジェクトを右クリックして [Import Service Contract] (サービスコントラクトのインポート) を選択し、コントラクトの種類を選択します。コントラクトをインポートしてプロジェクトをビルドすると、各操作を表す一連のアクティビティがツールボックスに追加されます (図 3 参照)。

The Generated Activities Are Added to the Toolbox 図 3 ツールボックスに追加される生成されたアクティビティ

図 4 に示すように、Receive と SendReply の間にアクティビティを追加できます。追加したアクティビティは、操作の本体を表します。

A Simple Service Method That Computes a Value 図 4 値を計算する単純なサービスメソッド

後半の手順では、特定のサービスでコントラクトを実装するよう指定します。そのためには、デザイナーでワークフローサービスを開き、コントラクトを WorkflowService ルートの ImplementedContracts コレクションに追加します。

サービスでコントラクトを実装すると、デザイナーによって新しい一連の検証規則が実行され、サービスがコントラクトに従っていることが確認されます。検証の結果、コントラクトの実装が不完全な場合は警告やエラーが表示されます。

コントラクトファーストの動作を確認するには、付属コードの ContractFirst プロジェクトを参照してください。実際に作業してみる場合は、先ほど説明した手順を実行してください。

WF デザイナーのより効率的な使用: WF ビジュアルデザイナーでは、ワークフローがグラフィカルに表現されるため、ワークフローの作成と共有が簡単になります。デザイナーは WF の重要な機能であり、最も使用されている作成ツールです。WF 4.5 では、使用時の生産性を向上できるよう、非常に要望の多かった機能を追加しました。

注釈: WF 4 では、デザイナーでテキストを追加できる場所は、アクティビティの DisplayName セクションだけです。これは、アクティビティの上部にある 1 行のテキスト領域です。構造化されていない説明情報をワークフローに追加する方法は、これ以外にありません。しかし、アクティビティデザイナーでコメントやテキストを追加してワークフロー定義を補足する (プロセスステップの動作に関する説明を追加するなど) 機能を追加するよう要望が寄せられました。

WF 4.5 では、注釈を追加しました。この機能により、デザイナーでテキスト形式のコメントや説明をアクティビティに追加できます。図 5 に注釈のあるワークフローとないワークフローを示します。任意のアクティビティに説明情報を追加できるようになっていることに注目してください。注釈を使用すると、デザイナーを見るだけでワークフローの処理内容を把握できます。

A Workflow with and Without Annotations 図 5 注釈のあるワークフローとないワークフロー

常に注釈を表示することも、アクティビティの DisplayName を表示するバーに付箋として表示することもできます。

注釈は任意で有効にする機能で、実行時間には影響しません。次のコードに示すように、注釈はワークフローの XAML ファイルに添付プロパティとして追加されます。

<Activity mc:Ignorable="sap2010" 
  x:Class="DesignerImprovements.Annotations" 
  xmlns="https://schemas.microsoft.com/netfx/2009/xaml/activities"
  xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
  xmlns:sap2010="https://schemas.microsoft.com/netfx/2010/xaml/activities/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Sequence sap2010:Annotation.AnnotationText="This is an example annotation">
    <WriteLine Text="Hello Dev11"/>
  </Sequence>
</Activity>

注釈の動作を確認するには、付属コードに含まれている Annotations プロジェクトを参照してください。実際に作業してみる場合は、WF 4.5 のワークフロープロジェクトを開き、デザイナーにアクティビティを追加して、アクティビティのコンテキストメニューで [Add annotation] (注釈の追加) を選択します。

Flowchart デザイナーと StateMachine デザイナーの強化: 生産性、特に、新しいアクティビティを Flowchart または StateMachine (.NET Framework Platform Update 1で入手可能) に追加する際の生産性を向上するために、デザインエクスペリエンスの強化を求める意見が寄せられ、これに対応しました。

auto-connect (自動接続) を追加しました。この機能により、デザイナーでは新しいアクティビティが既存のアクティビティと自動的に接続されます。また、auto-insert (自動挿入) という、接続線上に新しいアクティビティをドロップすると 2 つの既存のアクティビティ間にアクティビティを挿入できる機能も追加しました。図 6 に、これらの機能を示します。

Auto-Connect and Auto-Insert
図 6 自動接続と自動挿入

この機能を試すには、WF プロジェクトを作成して Flowchart または StateMachine を追加するだけです。新しいアクティビティを追加すると、自動接続のドロップ先が表示されます。2 つのアクティビティを接続したら、3 つ目のアクティビティを接続線上にドロップして追加できます。

大きなワークフローでの移動: WF 4 では、ワークフローが画面よりも大きい場合、垂直スクロールバーや水平スクロールバーを使用して移動することになります。このような方法で大きなワークフローを移動すると手間がかかり、生産性が下がるとの意見が寄せられました。

WF 4.5 では、panning (パン) という、マウスを使用してデザイナーキャンバスを移動できる機能を追加しました。デザイナーの [Pan] (パン) ボタンをクリックすると、Pan (パン) モードを有効にできます。パンはデザイナーの汎用機能として使用できるため、既存のアクティビティでも使用できます。

パンを試すには、デザイナーで任意のワークフローを開き、[Pan] (パン) ボタンをクリックして周囲にパンします。

WF 4.5 には、ワークフローのドキュメントアウトラインを表示するツリービューも用意されています。ツリービューでは、ワークフローを簡潔で構造的に表示できるため、大きなワークフローをより簡単に移動できます。このビューでアクティビティをクリックすると、そのアクティビティがワークフロー定義で選択されます (図 7 参照)。

Document Outline View of a Workflow
図 7 ワークフローのドキュメントアウトラインビュー

この機能を試すには、デザイナーでワークフローを開き、[View] (表示) メニューの [Other Windows] (その他のウィンドウ) を選択して、[Document Outline] (ドキュメントアウトライン) を選択します。

デザイナーでの検索の統合: WF 4 では、WF デザイナーの使用時に Visual Studio の検索機能を使用できますが、検索結果が WF デザイナーに統合されません。検索結果をクリックしても、ワークフローの該当する場所に移動できません。この問題が生産性に及ぼす影響の大きさとマイクロソフトがこの機能を提供することの重要性について、指摘がありました。

WF 4.5 では、WF デザイナーと Visual Studio の検索機能を統合しました。このバージョンでは、検索結果をクリックすると、ワークフロー内のアクティビティに移動します。アクティビティが複数のレベルにネストされていても移動可能です。

この機能を試すには、ワークフロープロジェクトを作成し、デザイナーでワークフローの編集を開始します。続いて、アクティビティを追加し、プロパティを構成します。ここで、Visual Studio の検索機能を使用してキーワードを検索してみてください。検索結果から、キーワードに一致するアクティビティに移動できます。

Auto-Surround with Sequence (シーケンスへの自動挿入): WF 4 のアクティビティモデルでは、根本からの構成がサポートされていました。つまり、アクティビティを自由に構成できました。たとえば、While アクティビティの Body プロパティには、Sequence、Parallel、Flowchart、StateMachine、WriteLine、Delay、または他の既存のアクティビティを指定できます。多くの場合、複合アクティビティには、アクティビティを (アクティビティのセットではなく) 1 つだけ受け取る Body プロパティがあり、これには他のリーフアクティビティや複合アクティビティを指定できます。

Body のアクティビティでよく使用されるアクティビティが Sequence です。特に、While、ForEach などの制御フローアクティビティでよく使用されます。これらのアクティビティでは、子を 1 つ追加した後で、要素のシーケンスに方針を変更する場合、Body の子を切り取って Sequence を Body に追加してから、切り取った子を貼り付ける必要があります。これは面倒で間違いやすい作業です。

WF 4.5 では、Auto-surround with Sequence (シーケンスへの自動挿入) 機能を追加しました。たとえば、While の Body が WriteLine の場合、アクティビティをドロップすると、既存のアクティビティと新しいアクティビティの両方が含まれる Sequence が自動的に作成されます (図 8 参照)。

Auto-Surround with Sequence
図 8 シーケンスへの自動挿入

この機能を試すには、図 8 の手順を実行します。

ビルドの統合: WF 4 では、デザイナーで新しいアクティビティを宣言によって作成できます。このとき実際に定義しているのは、プロジェクトのコンパイル時に生成されるアセンブリに配置される新しい型です。しかし、WF 4 プロジェクトのビルド時に XAML のエラーが存在する場合、ビルドは成功しますが、ワークフローは生成されるアセンブリに含まれません。

WF 4.5 ではこの問題を修正しました。エラーが存在するワークフローをビルドすると、予想どおりにビルドが中断します。

この解決策を実装するために、マイクロソフトでは XamlBuildTask に拡張性を加え XAML アクティビティのコンパイル時にアクセスできるようにし、XAML ワークフローファイルにエラーが存在する場合はビルドが中断するようにしました。

この機能を試すには、新しい WF アプリケーションを作成して、不適切な構成のアクティビティをワークフローに追加します。この結果、ビルドエラーが発生します。また、付属コードの ErrorBreaksTheBuild プロジェクトでも試すことができます。

既定で使用できるステートマシン: StateMachine は、非常に重要な制御フローアクティビティですが、WF 4 の時点では導入できませんでした。そのためにこのアクティビティの重要性に関するフィードバックが多数寄せられた結果、.NET Framework Platform Update 1 をインストールすると WF 4 で StateMachine を使用できるようにしました。WF 4.5 では、StateMachine を使用するために更新プログラムをインストールする必要はありません。既定で組み込まれています。

この機能を試すには、ワークフロープロジェクトを作成して StateMachine アクティビティを追加するか、この記事に付属しているコードの StateMachine サンプルプロジェクトを開きます。

バージョン管理のサポート

WF 4 ではワークフローのバージョン管理がサポートされていませんでした。バージョンを管理する場合は、すべて自分で行う必要があり、回避が難しい問題が頻繁に発生しました。WF 4.5 には、バージョン管理を実現する新機能が含まれています。

WorkflowIdentity: WF 4 では、ホストによって定義とインスタンスが関連付けられます。インスタンスが永続化されてメモリからアンロードされると、ホストは、インスタンスの実行を継続するための適切な定義を提供する必要があります。大きな問題の 1 つは、インスタンスの作成に使用された定義をホストが特定できる、永続化されるインスタンスの状態に関する情報がないことです。さらに、インスタンスの読み込み時にホストが不適切な定義で構成された場合、厄介な例外が返されます。これは、実際にバージョンが一致しないのではなく、インスタンスの状態が定義と一致しない状況の副作用として、エラーが発生するためです。

WF 4.5 では、WorkflowIdentity という新しい型が導入されました。この型は、完全に構成されたワークフロー定義を表し、インスタンスのランタイム状態に含まれています。WorkflowIdentity には、Name (string)、Version (System.Version)、および Package (string) の各プロパティがあります。Name と Version については説明不要でしょう。Package は、あいまいさをなくすために使用する省略可能な文字列です。Package は、ワークフロー定義のコンテナー (アセンブリ名、サービス URI、または任意の文字列) を表します。WorkflowIdentity は、WF のあらゆるバージョン管理機能の基盤です。

WorkflowIdentity の特に便利な点は、これがワークフローインスタンスの状態に含まれ、アクティビティのライフサイクル全体で保持されることです。WorkflowIdentity は永続化時に保存され、インスタンスストアから照会でき、ワークフローインスタンスの追跡情報と共に生成されます。

WorkflowIdentity を使用するのは簡単です。次のコードは、WorkflowIdentity を WorkflowApplication という、インスタンスと定義が 1 つだけのプロセス内ホストと併用する方法を示しています (WorkflowIdentity のインスタンスを WorkflowApplication のコンストラクターに渡すだけで使用できます)。

WorkflowIdentity identity = new WorkflowIdentity("Sample", new Version(1, 0, 0, 0),
  "MyPackage");
WorkflowApplication application = new WorkflowApplication(new MyActivity(), identityV1);

これで WorkflowApplication を WorkflowIdentity を使用して構成しましたが、有用な処理をまだ何も実行していません。次のコードサンプルは、ID を使用してバージョンの不一致を検出し、実用的なエラーメッセージを表示する方法を示しています。インスタンスを読み込もうとする場合にバージョンが一致しないときは、問題の原因を示し、指定した ID と想定される ID が含まれた VersionMismatchException を返します。この情報は、エラーをログ記録してエラーから回復するために使用できます。

try
{                
  WorkflowIdentity wrongIdentity = new WorkflowIdentity("Sample", new Version(2, 0, 0, 0), 
    "MyPackage");

  WorkflowApplication application = new WorkflowApplication(new WrongActivity(), 
    identityV2);

  application.Load(instanceId);
}
catch (VersionMismatchException ex)
{
  Console.WriteLine("Version Mismatch! {0}", ex.Message); 
  Console.WriteLine("Expected: {0}; Provided: {1}", ex.ExpectedVersion, ex.ActualVersion); 

}

最後に、特定のワークフローの ID をインスタンスストアから読み込む前に確認できます。ID をクエリするには、WorkflowApplicationInstance という WF 4.5 で導入された新しい型を取得する必要があります。この型は、定義に関連付けられていないインスタンスを表します。WorkflowApplicationInstance は、インスタンスに関するメタデータ (ここでは ID) を取得するために使用します。詳細については、bit.ly/ssAYDn (英語) を参照してください。

WorkflowIdentity は、WorkflowApplication とだけでなく WorkflowServiceHost とも連携することに注意してください。

この機能を試すには、付属コードの WorkflowIdentity プロジェクトを開きます。

WorkflowServiceHost: WorkflowServiceHost (WFSH) は、既定で使用でき、定義が 1 つでインスタンスが複数の、WF 4 で提供されるワークフロー用ホストです。しかし、WF 4 には制限があり、既に永続化したインスタンスを WFSH に読み込もうとするときにワークフロー定義が変わっていると、例外が発生します。これは、ホストでは新しい定義を使用してこれらのインスタンスを実行できないためです (これは WorkflowIdentity で挙げた問題です)。一部のユーザーは、複数の WFSH と WCF のルーティングサービスをクライアントアプリケーションとワークフローの仲介役として使用して、WF 4 に欠けているバージョン管理のサポートを補完しました。クライアントはメッセージをルーターに送信し、ルーターが正しいバージョンの定義で構成された対応する WFSH にメッセージをルーティングします。この手法の短所は、メッセージを正しくサービスインスタンスに送信するには、クライアントアプリケーションをバージョン対応にする必要があることです。

WF 4.5 では、WFSH が複数バージョンのホストになります。同じ WFSH に複数バージョンのワークフローサービスを配置でき、WFSH によって受信メッセージが正しいバージョンに配信されます。

セマンティクスは非常に単純です。新しいインスタンスは最新バージョンのサービスで開始され、実行中のインスタンスは開始時に使用したバージョンで引き続き実行されます。バージョンの変更には制限があり、サービス操作 (Receive) を削除できませんが、新しいサービス操作は追加できます (この規則は、CLR の派生インターフェイスの作成と似ています)。

この機能の実現に欠かせないのが WorkflowIdentity です。サービス定義のバージョンを特定するには、サービス定義の ID を構成する必要があります。以前のバージョンのサービスは、"サポート対象のバージョン" のフォルダーに配置する必要があります。これは、App_Code にあるワークフローサービスと同じ名前のフォルダーです（図 9 参照)。また、ホストを開く前に以前のバージョンを SupportedVersions コレクションに追加すると、以前のバージョンを明示的に WorkflowServiceHost に読み込むことができます。

WorkflowServiceHost Side-by-Side Versioning
図 9 WorkflowServiceHost によるサイドバイサイドでのバージョン管理

この新機能により、ルーターが不要になり、クライアントアプリケーションをバージョン対応にする必要がなくなります。クライアントアプリケーションはメッセージを送信するだけです。通常の関連付けメカニズムでメッセージが正しいインスタンスに解決され、対応する定義がホストによって使用されます (永続化されたインスタンスの状態に、インスタンスの読み込みに必要な定義の ID が含まれているため)。XCopy による配置のセマンティクスは保持されるため、コードを 1 行も書かずに使用できます。この機能は、自己ホストのシナリオ (WFSH をアプリケーションでホストするシナリオ) でも使用できます。

この機能を試すには、付属コードの WFSH_SxS プロジェクトを開きます。

Dynamic Update (動的更新): WF 4 では、ワークフローインスタンスの開始後にワークフロー定義を変更する方法がサポートされていません。これは、バグの修正や要件の変更のためにプログラムを更新する必要がある場合に問題になります。

企業ユーザーは、この機能の重要性について 1 歩も譲りませんでした。これは、実行時間の長いワークフローの特定のワークフローインスタンスを変更する必要にしばしば迫られるためです。たとえば、面接プロセスをモデル化するワークフローに 4 人の面接官が含まれている場合に、新しい企業ポリシーに従って、5 人目の面接官を追加しなければならなくなったとします。WF 4 では、このような変更は不可能です。

WF 4.5 なら可能です。Dynamic Update (動的更新) を使用すると、新しいワークフロー定義に合わせてワークフローの実行中のインスタンスを変更できます。このような変更は、デザイン時の手抜かり、ワークフローのバグ、新しい要件などの理由から必要になることが考えられます。動的更新は、元の設計とは大きく異なるワークフローにする、大規模な変更が必要な状況を目的とはしていません。このような場合は、実行中のインスタンスを変更するのではなく、新しいワークフローを設計すべきです。

動的更新は、一般に次の 2 つの手順から構成されます。ワークフロー定義を変更するときには、更新マップ、つまり変更に関する情報が含まれた構造も作成する必要があります。新しいバージョンを配置するときには、マップを使用して実行中のインスタンスを新しい定義に更新できます。実行中のインスタンスを更新できるのは、インスタンスがアイドル状態で永続化されている場合だけです。

動的更新は WorkflowApplication と WorkflowServiceHost の両方で使用でき、高度で複雑な機能で、ここで述べたよりもはるかに多くの機能が用意されています。動的更新では、アクティビティの更新、カスタム更新セマンティクスの提供、追跡情報の生成などがサポートされています。また、アプリケーションで使用すると実行中のインスタンス用の更新機能を実現できる、機能豊富な API もあります。

ランタイムの機能強化

WF 4.5 におけるランタイムの機能強化について、簡単に説明しておきましょう。スペースの関係上、ここまで説明してきた他の機能ほど詳しくは説明しません。これらの機能はより範囲が限られた高度な機能です。

部分的な信頼: WF 4 を実行するには完全信頼が必要でした。WF 4.5 は、部分的に信頼された AppDomain でも実行できます。

式の拡張性: 文字列ではなくオブジェクトにバインドするように ExpressionTextBox を変更しました。この結果、独自の方法で式を編集でき、テキスト以外でも式を表現できます。また、コードアクティビティで使用すると高いパフォーマンスで式アクティビティを作成できる、高速パス機能も追加しました。

Visual Basic のパフォーマンス向上: 内部実装を変更することで、VisualBasicValue/VisualBasicReference のパフォーマンスを大きく向上しました。

WF 3 の廃止: WF 4.5 では、WF 3 の型は古い形式としてマークされています。

まとめ

マイクロソフトは、ユーザーからのフィードバックを基に WF 4 を強化しました。.NET アプリケーションに最適なワークフローフレームワークを提供するために、要望の多かった機能を追加し、主な問題を修正しました。

WF 4.5 は、WF 4 からそのまま置き換わるバージョンであり、WF 4 と完全に互換性があります。マイクロソフトは、WF 4.5 によって WF 4 のシナリオに問題が発生しないことに関して徹底したテストを行っています。WF 4 に対するすべての投資は WF 4.5 でも無駄にならず、変更する必要もありません。

WF 4 アプリケーションを作成中の方は、作成を続行してください。WF 4.5 にいよいよ移行する場合、コードはそのままで機能し、皆さんと皆さんの顧客は、ここで説明したすべての機能強化を利用できます。

Leon Welicki は、WF チームのシニアプログラムマネージャーで、WF プログラミングモデルとランタイムを担当しています。

この記事のレビューに協力してくれた技術スタッフの Joe Clancy、Dave Cliffe、Dan Glick、Hani Khoshdel Nikkhoo、および Isaac Yuen に心より感謝いたします。

Share via