好消息是，WPF团队已经修正了这个bug并且发布了一个hotfix。所以，如果你也面临类似的问题，我建议你去安装一下这个hotfix然后再试试看。虽然不敢保证它能解决你的问题（因为造成问题的原因可能不尽相同），不过我觉得也很值得一试。

你可以使用如下任意一个连接下载这个hotfix。

https://archive.msdn.microsoft.com/KB2484841

https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=35604

同时，我也强烈建议安装下面这个.NET更新。因为它包含了额外一些WPF和WF 4.0的bug fix。

https://www.microsoft.com/download/en/details.aspx?id=3556

赶快去安装试试看吧！

举例来说，很多工作流系统中都有如下所述的典型应用场景：

1. 业务人员使用工作定义一套业务流程，当然是以图形化的方式
2. 在使用这套业务流程的过程中，用户需要在系统的界面上（可能是桌面程序或网页）看到这个工作流的定义图，以便理解流程的逻辑。

为了实现这一应用场景，一个比较典型的做法是把工作流定义图保存成图片并显示给最终用户。最近在看MSDN WF 4论坛的时候，发现有一些开发人员不知道如何编程把WF 4工作流定义保存到图片，而有些客户也通过邮件向我提出同样的问题。今天我就来跟大家分享一下如何实现这个功能。

什么？难道WF 4默认不提供这一功能吗？还需要我自己写代码？有些朋友（特别是使用过WF 3.x的人）可能会发出这样的疑问。的确，WF 3.x中有一个很方便的API供你使用，而在WF 4中没有。主要原因是WF 3.x在图形方面使用的是WinForm而WF 4使用的WPF。WinForm支持在界面控件还没有被创建出来的时候生成图片，因此我们可以提供一个API来保存流程图。但是WPF却不支持这一点，也就是说，在WF 4中，你一定要先打开设计器（Workflow Designer），然后才能保存图片。正是由于这个约束，我们才无法实现保存图片的API。不过好在自己实现这一功能也比较简单，只不过有一些tricky的地方需要注意。我保证读完这篇文章，你就会觉得是小菜一碟儿了。

基本想法

实现保存图片功能的基本想法很简单：

1. 新建一个工作流设计器（Workflow Designer）
2. 打开需要保存图片的工作流定义
3. 保存图片
4. 关闭工作流设计器

其中第一、二步是必要的，因为就像我之前提到的WPF要求在创建出界面控件之后才能保存图片。当然我们不需要打开Visual Studio，还记得WF 4提供一个rehostable workflow designer吗？对，我们就用它。关于如何创建一个rehostable workflow designer，请参考我们在MSDN上提供的示例代码。你也可以在这里下载到整套的WF 4示例。

写代码试试看

那么让我们写代码试试看。先来看看rehostable workflow designer的基本代码

namespace Microsoft.Samples.DesignerRehosting
{
    public partial class RehostingWfDesigner : Window
    {
        private WorkflowDesigner workflowDesigner;

        public RehostingWfDesigner()
        {
            InitializeComponent();
        }

        protected override void OnInitialized(EventArgs e)
        {
            base.OnInitialized(e);

            // register metadata
            (new DesignerMetadata()).Register();
            // create a big workflow for saving image
            Activity workflow = new Sequence
            {
                Activities = { 
                    new Sequence(), new Sequence(), new Sequence(),
                    new Sequence(), new Sequence(), new Sequence(),
                    new Sequence(), new Sequence(), new Sequence()
                }
            };
            // create the workflow designer and load the workflow
            workflowDesigner = new WorkflowDesigner();
            workflowDesigner.Load(workflow);
            DesignerBorder.Child = workflowDesigner.View;
        }
    }
}

接着我们来看看如何在WPF中为界面控件生成一张图片：

BitmapFrame CreateWorkflowDefinitionImage()
{
    const double DPI = 96.0;
    // this is the designer area we want to save
    Visual areaToSave = ((DesignerView)VisualTreeHelper.GetChild(
        this.workflowDesigner.View, 0)).RootDesigner;
    // get the size of the targeting area
    Rect size = VisualTreeHelper.GetDescendantBounds(areaToSave);
    RenderTargetBitmap bitmap = new RenderTargetBitmap((int)size.Width, (int)size.Height,
        DPI, DPI, PixelFormats.Pbgra32);
    bitmap.Render(areaToSave);
    return BitmapFrame.Create(bitmap);
}

这段代码比较直观，就是得到workflow designer中工作流图形的部分，然后使用WPF的一些API在内存中创建一张图片。接下来如果需要保存的一个文件的话，就比较简单了：

void SaveImageToFile(string fileName, BitmapFrame image)
{
    using (FileStream fs = new FileStream(fileName, FileMode.Create))
    {
        BitmapEncoder encoder = new JpegBitmapEncoder();
        encoder.Frames.Add(BitmapFrame.Create(image));
        encoder.Save(fs);
        fs.Close();
    }
}

最后我们尝试在protected override void OnInitialized(EventArgs e)的最后调用以上两个函数保存图片：

protected override void OnInitialized(EventArgs e)
{
    ...
    this.SaveImageToFile("test.jpg", this.CreateWorkflowDefinitionImage());
    Application.Current.Shutdown();

}

怎么会抛异常？

好，我们来运行以上代码！等等，为什么会有抛异常？

稍微debug一下不难发现，原因是我们想要保存图片的区域的大小是负数。这是为什么呢？原来虽然我们是在打开workflow designer之后才保存的图片，但是在保存图片是，相应的界面控件并没有创建完毕，因此才得到了负数。这个问题要怎么解决呢？WPF中的每个控件都有一个LayoutUpdated事件，意思是控件已经创建并布局好了。然而仅仅简单的监听这个事件还不够，因为在完全创建好工作流定义图之前，控件会被布局很多次。因此，我们还要用一个计时器（Timer）：

private System.Timers.Timer timer;
private delegate void TimerDelegate();

protected override void OnInitialized(EventArgs e)
{
    this.timer = new System.Timers.Timer(1000);
    this.timer.AutoReset = false;
    this.timer.Elapsed += new ElapsedEventHandler(CaptureTimer_Elapsed);
    this.timer.Start();
    workflowDesigner.View.LayoutUpdated += new EventHandler(View_LayoutUpdated);
}

void CaptureTimer_Elapsed(object sender, ElapsedEventArgs e)
{
    this.timer.Stop();
    this.timer = null;
    this.workflowDesigner.View.Dispatcher.BeginInvoke(
        System.Windows.Threading.DispatcherPriority.ApplicationIdle,
        (TimerDelegate)delegate()
        {
            this.SaveImageToFile("test.jpg", this.CreateWorkflowDefinitionImage());
            Application.Current.Shutdown();
        });
}

void View_LayoutUpdated(object sender, EventArgs e)
{
    if (this.timer != null)
    {
        this.timer.Stop();
        this.timer.Start();
    }
}

怎么保存不全？

好，我们再来运行试试。好！没有异常了！快去\bin\Debug下面看看保存的图片！哎？怎么有几个活动设计器不对呢？没有具体的活动设计器，只有个框而已。（为了节省版面，这里我把图片旋转了一下，实际上是垂直的没错，只是最后两个Sequence保存的有问题）

想要知道产生这个现象的原因，我们就需要讨论一下workflow designer中的一个高级机制叫做虚拟化（Virtualization）。在这里，虚拟化的作用是：如果某些活动还没有出现在workflow designer中的可视区域内，我们就不去创建相关的活动设计器。这样做主要是为了提高workflow designer的性能。想象一下你的工作流中有上百个活动，但是在你的屏幕中一次只能看到其中十个。如果没有虚拟化，我们就不得不把所有上百个活动的设计器创建出来，这就会大大降低整个设计器的性能。而这里有问题的两个Sequence恰恰是被虚拟化的、还有没被创建出设计器的活动。

好了，原因说清楚了。那么怎么解决呢？道理是明摆着的，就是要让所有活动都出现在可视区域内。不过要怎么做呢？别急，我们的workflow designer提供了一个Fit to Screen功能，就是把整个工作流定义的图形缩放到在可视区域内完全显示。我们可以利用这一功能显示所有的活动。相应的代码加在哪里呢？对，void View_LayoutUpdated(object sender, EventArgs e)

private bool IsVirtualized = false;

void View_LayoutUpdated(object sender, EventArgs e)
{
    if (!IsVirtualized)
    {
        ((RoutedCommand)DesignerView.FitToScreenCommand).Execute(null,
            this.workflowDesigner.Context.Services.GetService<DesignerView>());
        IsVirtualized = true;
    }
    if (this.timer != null)
    {
        this.timer.Stop();
        this.timer.Start();
    }
}

搞定！

最后我们再来运行一下。OK，这回图片正确啦！（同样，为了节省版面，这里我把图片旋转了一下）

最终版的代码可以在这里下载。希望以上讲解和示例能够给给我带来一些帮助。

主题

今年Tech.Ed北京的主题毫无疑问是云计算（Windows Azure）和Windows Phone 7，这一点但凡是关注一点儿业界新闻的同志们都不会觉得奇怪。云计算依然是IT领域的未来发展趋势，而我个人认为，Microsoft毫无疑问是这一领域投入最多、技术最成熟、推广力度最大的公司。Windows Phone 7是在11月份刚刚发布的新东西，目前市场业绩非常不错，是Microsoft在消费品及移动终端领域的重要战略。这也难怪这次大会会这两个重量级的家伙为主题。更重要的是，Microsoft一直以来都在强调云+端的威力，而Windows Azure + Windows Phone 7恰恰是展现这一策略的最佳组合。

所以我们看到，在Simon老大跟Enwei老大的主题演讲中，Windows Azure与Windows Phone 7占了很大的比重。而在随后由4个总经理level的老大分别给出的4门基础课程中，Windows Azure跟Windows Phone 7也当仁不让的拿下了3席。

这意味着什么？很显然Windows Azure和Windows Phone 7将成为明年的绝对潮流。还没开始跟进吗？当心落伍哦~

课程

有了以上两个主题，我们作为产品团队，当然也要向之靠拢。今年我们的参与阵容可谓庞大，浩浩荡荡10余人。一共开展了3项课程，4个动手实验室，同时还有一个展台。下面帮大家回顾一下课程的大致内容。没有参加Tech.Ed的同志们要注意了，这里有课程讲义下哦！

课程一：使用WCF开发REST服务 ── 在Windows Server AppFabric 上，在云端

• 简单介绍REST以及其与HTTP的关系
• 如何使用WCF创建REST服务
• WCF 4中对REST服务支持的增强，包括简化的配置、更好的缓存、更灵活的格式选择等
• 隆重推出https://wcf.codeplex.com
• 对下一代WCF的展望

使用WF 4实现您的流程 ── 在Windows Server AppFabric上，在云端

• 简单介绍什么是WF 4，三个关键字：活动（Activity）、运行时（Runtime）、工具（Tooling）
• WF 4适用于哪些典型的应用场景：长时间运行的任务、流程的二次定制，以及协调复杂的业务逻辑
• 以一个典型的审批流程详细的演示了：
  • 如何创建简单的活动、如何创建一个工作流服务、如何在WF 4中访问数据库，以及如何把WF 4整合到ASP.NET中
  • 如何实现复杂的业务逻辑，例如审批的驳回以及会签
  • 如何部署并管理工作流实例到Windows Server AppFabric和Windows Azure上
• 下一代WF会有哪些激动人心的新特性

下一代中间件平台AppFabric纵览

• AppFabric的总体架构，包括Windows Server AppFabric和Windows Azure AppFabric
• 演示如何在Windows Server AppFabric中部署、配置、监测WCF/WF服务并管理工作流实例
• 展望未来，下一代AppFabric特别是在云端的特性以及AppFabric云端管理平台的演示

Channel 9

严肃的内容就到这里，Tech.Ed也有轻松有趣的一面。这一次我很幸运接受了Channel 9中文频道的采访，跟Tech.Ed的现场观众以及网络上的朋友分享WF的一些知识以及最新动态。各位可以在这里找到我的采访视频：WF的场景和未来特性。

说到这次采访，就不得不提Channel 9了。Channel 9是Microsoft MSDN上的一个主要面向广大技术爱好者的视频频道，其英文网站上包含了非常多的高质量视频帮助你了解Microsoft的产品和技术。最酷的是连像Mark Russinovich这样的大牛（Microsoft的Technical Fellow之一）都会在上面有视频分享。那针对WCF、WF和AppFabric，我们也在Channel 9的英文网站上面有endpoint.tv这样一个连载，到目前为止已经有133集啦！我在Redmond总部出差的时候还做过一期，在这里endpoint.tv – WF State Machine and ADO.NET Activity Packs.

这次Tech.Ed的采访是Channel 9中文频道，所以对国内的朋友也更加友好一些。虽然这个中文频道发展时间不长，但是势头很猛，相信在不久的将来可以有更多机会利用这个平台跟各位交流。顺便提一下，我还顺了间Channel 9的衣服和一个公仔，非常可爱！

其他及照片

这次Tech.Ed期间，北京出奇的暖和。我们在会场上见到了很多熟悉的身影，有的是Microsoft的MVP，有的是之前就有过交流的朋友，有的是正在使用WF的客户。能再次见到大家真是非常的开心。值得一提的是，这一次神州数码作为使用WF 4的合作伙伴，还跟我们一起做了一堂课程，跟大家分享他们是如何在实际项目中使用WF 4。当时500多人的会场座无虚席，场面非常火爆。最后不多说了，以照片结束这篇博文，同时期待下次Tech.Ed盛会的到来！

这一Activity Pack包含一系列的基于ADO.NET Data Providers的WF 4活动。这些活动可以帮助你非常容易地在工作流中使用SQL语句或存储过程（stored procedure）访问数据库。下载并安装这一Activity Pack后，你就可以轻松地通过设计器或自行编码把其中提供的ADO.NET活动加到你的工作流中了。

除了安装文件外，我们还提供了用户手册帮助你快速了解这一Activity Pack中所包含活动的特性及使用方法。你还可以下载响应的源代码来研究研究，其中包括从活动到设计器的所有代码哦！

同样，你的反馈对我们至关重要。我们希望能够了了解更多你如何在工作流中访问数据库的信息。这一我们才会在将来实现提供更多更强大的数据访问功能。请一定要让我们听见你的声音！

这个预览版本包含了一个完整的State Machine运行时和图形化设计器。你将会感受到，我们对事件驱动的场景做了很大的优化。最明显的感觉是，我们简化了State Machine的运行时模型并提供了很棒的工具支持。相比WF 3中的State Machine而言，创建State及Transition变得额外简单，只需要简单拖放及连线即可。

一直期待State Machine在WF 4中出现的朋友们，赶快去下载并安装这个Activity Pack吧！如果你想要快速了解State Machine的功能及如何使用它，绝对不能错过我们专门编写的用户手册。如果你用过WF 3及其中的State Machine并想知道它们有什么不同，没问题，用户手册中有非常详细的对比。这还不是全部，如果你对我们是如何实现这一State Machine感兴趣的话，我们还提供从运行时到设计器的所有源代码！而且，你还将会看到越来越多的文章介绍如何使用State Machine中的各种特性以及我们设计并实现State Machine背后的故事。

最后请切记，你的反馈对我们至关重要！我们希望能够了解更多关于你如何使用State Machine的信息，这样我们才会在未来实现一个能够满足你需求的State Machine。你的任何关于State Machine的想法都会非常有价值，例如你希望State Machine有什么功能，你觉得目前的实现有什么问题或缺陷，你希望设计器的用户体验有什么改进，等等等等。请一定要让我们听见你的声音！

PS。我们还同时发布了WF ADO.NET Activity Pack CTP1哦！

接续上一篇,我们会允许有多个Activity同时被Schedule,换句话说,就是某程度上的并行处理。这情况其实很普遍，比如说多人需要审批一份文档。上一次我们发现ScheduleActivity只能被调用一次，那麽明显的解决方桉就是允许一个States上可以有很多的Delegates。看着states.Frames，我们过往的实现都只会盯着最上层的一个Frames，但是在并行的情况下这样就不成了。我们需要一个像Stack一样，但是有很多个顶的一个数据结构，想一想，这不就是一颗反过来的树吗？我们会在数据结构上放这个棵树所有的叶，然后用父指针去找它的Parent Frame。当我们有很多的叶的时候，只有States就不够了。Activity.Execute将无法知道它应该是在那一个Frame上跑，所以我们要把Execute的参数从States改成Frame，这样的话其它就会变得简单了。

代碼示例：Version 8

我们还是在使用以前的Activity，这只不过是为了安全起见，我们没有使用并行。现在我们使用并行了，最简单的就是Parallel，它只会Schedule两个Read。

代碼示例：Version 9

留意工作还是单线程的在执行。Parallel只不过允许多份工作同时在等着而已。当这些工作实际上是在等外界输入，那它们就是在同时等待。在上一个版本，我们每一个Delegate的先决条件都是Frame，但是很多时候有些工作不能完成不是因为其它工作还没完成，而只不过是它所需要的资料还没到而已。这些资料到最终还是从主程序中获得。我们可以通过States去通知主程序去接收资料，到资料收到的时候，主程序便能执行正在等待数据的工作了。WF3使用Queue的方式去等待数据，但我们发现很多时候我们只需要一个数据项，所以WF4使用了Bookmark。

代碼示例：Version １０

到这里我们就结束我们这旅程了。当然，要做到像今天的WF4还有很漫长的路，但是我希望通过这几篇，大家可以瞭解WF的使计，并可以好好的把它运用到实际场景里，谢谢。

HomeMadeWF.zip

同样的道理也可以使用在Workflow上。我们做这样的比喻，Sequence就是程序，但是sequenceCounter只不过是执行资料而已。sequenceCounter这个成员定义在Sequence上使它们不可区分。想像同样的一个Sequence有很多个进程在跑，那么sequenceCounter就会乱掉。

读一下Activity这个类的代码，States定义在Activity上其实是个更大的问题。与其让States通过activity去读取，我们会把它变成一个Execute的参数。同样地,NextDelegate也不应该放在Activity上。不过这个问题更麻烦一点，因为Sequence需要同时有两个NextDelegate。去解决这个问题，我们会使用一个Stack<Frame>去存这些NextDelegate物件。勤快的读者们，请你们亲手试一试，因为我们在下一个版本会有很多的改动如下

代碼示例: Version 6

我尝试把Version 6和Version 5的改动减到最少了，在把delegate的存取方式改动的同时，我们也优化了Sequence的执行。现在执行Sequence下的Activity再也不会通过Sequence。现在的代码能跑了，我们就该重构。这次我希望States把它的Stack<Frame>给封装起来。这样这个Stack的逻辑就不会四处分散。说也不是很难，只要把Frame变成private就可以驱动这些重构了，我做的不过就是给操作一个合适的名字而已。

Version 7 没有甚麽实质改动，只是封装一下而已。
代碼示例: Version 7

现在我们已经很接近了，在这个版本里我们只对States做序列化。我们问一下自己，到底我们做完程序和资料的分离没有？答桉是没有，因为States里有Delegate，而delegate又回到Activity物件，即程序。我们可以通过序列化MethodInfo，而非delegate，去达到这一点。我们在序列化MethodInfo的同时，也需要存ActivityID。ActivityID是一个Activity的唯一身份码，我们可以通过深度搜寻去找出来。由于这些代码比较複杂，也没有甚麽太大的技术难点，在这里我们就轻轻带过了。另外一个问题就是我们没有保证程序是唯读的。这问题有多种解决的办法。在WF3中它採取了先拷贝一份，永远拷贝来执行的方法，而WF4则选择做一个拷贝（只拷贝对执行有作用的资料），跑原来的一份，而在跑的时候保证跑的确实是原来的拷贝。我们也可以选择当用户更新程序时让它出错。同样地，这些都比较明显，就略过不写了。

还有另外一个问题，就是一行的程序(比喻为一个Activity)可以被多次执行。最简单的例子就是迴圈。这时候，它们的储存必须定义在Frame上，实际上，所有的资料都应该存在Frame上，这就没有States的全局性了，这是WF4比它前一个版本优胜的地方。

看着States的实现，我们不难发现ScheduleActivity只能被调用一次，因为Frame上只有一个NextDelegate成员。下一篇我们会去改进ScheduleActivity,允许多个未完成的Activity，我们也会讲一讲如何让Workflow和主程序如何使用Bookmark通讯。

HomeMadeWF.zip

首先我们先看一下CLR里对Continuation的支持吧。Continuation是一个程序执行中一个可以保存的时间点，所以它必须保存一个对执行代码的指针，而delegate就是一种这样的指针。Delegate最棒的地方就是它可以被序列化，反序列化，然后继续执行。我们可以看一下以下的代码：

代碼示例: SerializableDelegate

可序列化delegate给了我们一个方法去暂停一个线程，然后让它在另外一个进程中继续，这个进程甚至可以是在另外一台电脑上。这样做的好处很多，而最重要的就是我们除掉了所有的「亲和度」，代码再不依赖于进程，甚至不依赖于电脑。这样的话我们就可以很好的扩展我们的系统，只需要多买电脑，也任务分派到不同的机器就可以，关键是代码可以随时停下来。同时，我们有了控制。我们可以把序列化了的delegate删掉，这样就可以取消了这个进程。工作可以暂停很长的时间，而不用担心系统会佔用了内存资源。接下来我们看一下以下的代码示例，看看我们如何使用可序列化delegate把一个程序拆成不同的进程：

代碼示例: Version 1

执行这程序三遍，你会发现在控制台上会显示出“Hello world to homemade workflow foundation!”。在以上的代码，我们就简单的创建了一个简单的工作流程序了。不用说，这个范例有很多问题，我们有很多可以改善它的地方。第一步我们就先把对可扩展性的支持和业务逻辑分离出来。我们会提炼一个名为ReadReadWrite的类，然后把业务逻辑集中在它上面，这样我们就写了Version 2

代碼示例: Version 2

首先，留意我在主程序中写了一个while循环，这个只是一个方便的捷径而已。对于我们来说，知道这些程序能够分开就好，实在没有必要真的分开执行。这次的重构其实很简单直接，不过有一点值的留意的就是我把NextDelegate变成一个ReadReadWrite的一个成员。这样做的原因是为了让每一个delegate都有一样的signature.

到了这个时候，主程序和业务逻辑已经是分离了。我们还是有一些耦合点，例如主程序需要知道程序的起点是RunStep1，而储存接续点的成员是NextDelegate,这样我们的主程序就不能是一个普遍而适用于任何程序的主程序。去掉这些耦合的方法说也简单，就是定义一个父类，让主程序与父类耦合而不会和业务逻辑耦合，这个父类我们命名成Activity.

代碼示例: Version 3

这次的重构也是非常的简单。读一下ReadReadWrite的代码，这样的代码已经不难写。其中有一点我们不喜欢的地方就是Execute和RunStep2里面做的事情几乎一模一样，从代码的角度去看最好我们可以重用。我们试着提炼，然后发现两个问题。一个是它们是在更新不同的状态变量，而另外一个是它们返回不同的delegate。它们返回不同delegate的这问题尤其严重，因为读文件和程序执行顺序是两件垂直的事情。我们把程序控制和实际工作混合在一起会破坏了代码的内聚性。接下来我们试着把它们区分出来。

代碼示例: Version 4

Sequence activity 的实现一点也不简单，而且它也不是最优化的。下一篇我们会讨如何优化Sequence。现在我们先专注于除掉Read1和Read2之间的重覆。到这里Read1和Read2都是在读文件了，所以我们可以通过名字去找状态变量，这样就可以完全的把重覆除掉了。

代碼示例: Version 5

走到这里，我们已经可以写能重用的Activity，而且这些Activity都不用管有关序列化的细节。不去读Main的代码，我们甚至不知道序列化有实际进行。看看Read和Write，是不是开始有点像WF4里Activity的API呢？下一篇，我们会继续这个例子，去探讨为甚麽Activity.Execute会有一个参数，和这个参数如何把程序兴资料区分出来。

HomeMadeWF.zip

在3.0/3.5中，我们需要先初始化WorkflowRuntime，并通过CreateInstance函数来建立工作流实例（WorkflowInstance）。4.0中的WorkflowApplication类和WorkflowInstance类对应，但是不需要通过WorkflowRuntime来实例化，可以通过new来实例化。

虽然WorkflowApplication和WorkflowInstance的对应，但是他们的构造方法也存在区别。3.0/3.5中我们通过传入一个System.Type类，由WorkflowRuntime来负责进行模板的实例化。而在4.0中我们是传入一个System.Activities.Activity实例来建立工作流实例。

除此之外，4.0中还提供提供了一种调用Workflow的快速通道WorkflowInvoker。可以直接通过调用静态方法Invoke来执行一个工作流。

Workflow 4.0另一个重大的特点在于WCF和Workflow的密切结合。和3.5一样，4.0中存在一个用于管理Workflow服务的类System.ServiceModel.Activities.WorkflowServiceHost。需要注意的是这个类存在于System.ServiceModel.Activities.dll中。他和System.WorkflowService.dll （.NET Framework 3.5）中的WorkflowServiceHost是完全不同的。

由此可见4.0中提供了3中不同的方式来管理/托管工作流实例。

WorkflowInvoker

可以像执行一个函数一样运行一个工作流。

优点：简单

缺点：在工作流执行过程中，如果和工作流实例进行数据交换

代码：

            WorkflowInvoker.Invoke(new Workflow1());

WorkflowApplication

可以控制工作流实例长时间运行，可以在运行过程中和实例进行数据交换。但是只能执行一个的工作流实例。

优点：

支持持久化，可以对实例进行控制，可以通过Bookmark来控制实例或交换数据。

应用例子：

使用工作流辅助建立一个向导的UI程序。

代码：

            WorkflowApplication instance = new WorkflowApplication(new Workflow1());

            instance.Completed = delegate(WorkflowApplicationCompletedEventArgs e)

            {

                Console.WriteLine("workflow completed, Id = " + instance.Id);

            };

            instance.Run();

            //....

            instance.ResumeBookmark("Submit", data);

WorkflowServiceHost

WorkflowServiceHost是一个最主要的工作流主机类。可以同时管理多个工作流实例，同时控制实例的激活等操作。支持WCF，和3.5相比有更强大的消息关联功能。当然WorkflowServiceHost也支持持久化（Persistence）和跟踪（Tracking）等功能。

在3.0/3.5中，我们使用DependenceProperty，使用绑定的方式在不同的Property建立关联，由此实现数据的交换。这种方式的确很灵活，但是也带来不少弊病。比如所有的数据都存在同一个域中导致性能的下降，同时DependenceProperty的生命周期也是很让人困惑的问题，我不只一次的在论坛上听到有人提出对DependenceProperty的初始化时间提出疑问。

在4.0中，我们建立了一种更简洁的数据管理模式，变量（Variable）和参数（Argument）。这也是一种更符合大部分人编程习惯的数据模型。在传统的编程模式中，我们使用变量来存储数据，使用函数来封装程序的功能，使用参数和返回值来进行函数间的数据交换。

在Workflow中，Activity是封装功能的单元，我们可以理解为传统编程中的函数。而变量、参数的概念是类似的。我们来看一个例子。

一个C#的Hello World只有几行

在这个例子中我们建立了一个message变量，它的生命周期就是我们的HelloWorldSample这个函数，在函数开始时我们会对这个变量进行初始化，结束时会释放这个变量的资源。同时我们调用了一个叫做WriteLine的函数，这个函数有一个输入参数类型是string，在调用函数时我们将变量message作为具体的值传入WriteLine函数。如果将上面的代码转化为Workflow，你会发现这些概念是对应的。

下面我们来具体介绍Variable和Argument。

参数（Argument），Activity的I/O数据流接口

Argument是Activity的I/O接口，分为InArgument、OutArgument、InOutArgument。

可见域：定义Argument的Activity的Execute函数及其所有实现子活动（Implementation Child Activity ）。

生命周期：等同于定义它的Activity。

InArgument

用于向Activity传入数据，只能对其进行取值操作。它可以使用Activity<T>、常数、Lambda Expression或者Variable作为表达式。

OutArgument

用于向Activity外部传出数据，只能对其进行赋值操作。它可以使用Activity<Location<T>>、Lambda Expression或者Variable作为表达式。

InOutArgument

用于向Activity传入或传出数据，可对其进行取值和赋值操作。它可以使用Activity<Location<T>>、Lambda Expression或者Variable作为表达式。

RequiredArgumentAttribute

默认情况下，在使用Activity时不需要对每一个Argument赋值，但是你可以为你的 Argument加上RequiredArgumentAttribute，用于表示必须在定义Workflow时必须为这个Argument赋初值。Runtime在创建Workflow实例时会对所有Argument进行检测，如果某个RequiredArgument没有赋值，将会抛出ValidationException。

变量（Variable），Workflow中的数据公共存储单元

Variable是用于存放数据的单元，Variable分为普通变量（Variable）实现变量（Implementation Variable）两种。

生命周期：等同于定义它的Activity，在Activity开始执行时， Workflow Runtime会初始化所有定义在这个Activity中的变量，而在Activity结束时结束Variable的生命周期。

注意：

Variable的初始化是有顺序的，如果你不清楚当前 Activity对Variable的初始化顺序，不建议使用同一个Activity中定义的不同Variable进行相互的初始化。因为这种错误无法在设计时别检测，只有在运行时才能被发现。

因为var2在var1之后初始化，所以在运行时会得到异常说var1没有被初始化。但是如果你交换var1和var2的位置，就不会得到任何异常。

Variable的默认值的类型是System.Activites.Activity<T>。但你还可以用常数、Lambda Expression或者其他得Variable来初始化Variable。除了类型（Type），名称（Name）和默认值（DefaultValue），Variable还有两个附加属性：只读（ReadOnly）和映射（Mapped）

只读（ReadOnly）

ReadOnly属性顾名思义，就是表示这个Variable在能在初始化时对其赋值，若试图在之后对其赋值，将会得到一个运行时的异常。

以上Workflow会在运行时Assign时获得一个InvalidOperationException。

映射（Mapped）

被标志为Mapped属性的Variable，可在工作流实例持久化时对这个Variable进行查询，在此我就不详细展开了。

普通变量（Variable）

一个典型的例子是Sequence得Variables属性。

可见域：定义Variable的Activity的所有普通子活动（Child Activity）。

注意：

你是无法在Activity的内部函数中或其实现子活动（Implementation Child Activity）中使用当前Activity所定义的普通变量。

下面是一个在自定义活动中使用Variable的例子：

实现变量（Implementation Variable）

Implantation Variable用于储存Activity的私有数据，它只能在定义它的Activity的内部函数中或Activity的实现子活动（Implementation Child Activity）中使用。

可见域：定义Variable的Activity的内部函数和所有实现子活动（Implementation Child Activity）。

下面是一个使用Implementation Variable的例子：