『听风且吟』技术版

Adobe PDF Reader COM组件（axAcroPDFLib）的退出问题

Windie Chai — Wed, 02 Jun 2010 12:22:45 +0800

Adobe PDF Reader COM组件（axAcroPDFLib）可以用来在Windows Form中显示PDF文件的内容并进行交互。

我们知道，Windows Form应用程序在关闭的时候，会销毁所有控件，而在销毁axAcroPDFLib时似乎遇到了问题。

具体表现为：

关闭应用程序之后，进程依然会在内存中驻留较长时间，然后才彻底退出；
关闭应用程序之后，发生错误：

“0×0700609c”指令引用的“0×00000014”内存，该内存不能为“read”。

解决方法很简单，只需要在窗体关闭时手工卸载axAcroPDFLib组件就可以了。

示例代码如下：

[System.Runtime.InteropServices.DllImport("ole32.dll")]
static extern void CoFreeUnusedLibraries();

private void Form2_FormClosing(object sender, FormClosingEventArgs e) {
if (axAcroPDF1 != null)
{
axAcroPDF1.Dispose();
System.Windows.Forms.Application.DoEvents();
CoFreeUnusedLibraries();
}
}

CoFreeUnusedLibraries函数会检测当前进程中的所有COM组件，当发现某个组件的DllCanUnloadNow函数返回TRUE时，就调用FreeLibrary函数来卸载该组件。

那么DllCanUnloadNow如何才会返回TRUE呢？有两个条件，当这两个条件都满足时，DllCanUnloadNow就会返回TRUE：

组件的对象数为0；
类厂的锁计数为0。

在窗体关闭时调用axAcroPDFLib.Dispose就能保证该COM组件的对象数为0。

而锁计数则需要保证没有调用LockServer(TRUE)，如果调用了LockServer(TRUE)，则需要再调用LockServer(FALSE)来解锁。嗯，据说是这样的，COM我也不怎么懂，了解的同学可以指点一下。

WindStyle ExifInfo for Windows Live Writer发布

Windie Chai — Wed, 03 Feb 2010 23:12:13 +0800

什么是Exif？

Exif，既Exchangeable Image File，是由数码相机在拍摄过程中采集并且镶嵌到照片文件内部的一些信息。Exif信息主要包括拍摄照片时的设备信息、光圈、快门速度、ISO、拍摄时间甚至拍摄地点。

什么是WindStyle ExifInfo？

WindStyle ExifInfo是一个Windows Live Writer插件，作为Windows Live Writer添加图片时丢失Exif信息的补充，WindStyle ExifInfo允许你在向日志中添加图片的同时添加该图片的Exif信息，并可以定制照片和Exif信息的显示样式。

同时，WindStyle ExifInfo还是一个开源项目，它托管在微软的CodePlex网站，你可以点击这里访问本项目。

如何使用WindStyle ExifInfo？

具体使用方法请移步至此页面。

WF4.0活动模型（1）：工作流既活动

Windie Chai — Tue, 26 Jan 2010 09:05:52 +0800

如果你已经开发过Windows Workflow Foundation（WF）程序，那么你应该会非常熟悉活动。在WF世界中，程序被定义为一个活动树。有些活动用来控制程序的流，比如Sequence、If和While；有些活动执行特殊的操作，比如Assign、InvokeMethod和WriteLine；还有一些可以和外部系统通讯，比如Send和Receive。

例如下面这个简单的工作流：

图1. 一个简单的“扔硬币”工作流

去掉花哨的东西，工作流实际上是一个活动树：

图2. 图1中工作流的活动树

活动是WF的基本建模单元，就好比文本编程语言的抽象语法树（Abstract Syntax Tree，AST）。鉴于WF使用了运行时来直接执行活动树，活动也可以视为WF的基本执行单元，好比CLR的IL。

然而活动却还有一些独特的特性，使其要比传统的AST或IL更加强大：

活动是完全可扩展的：任何人都可以创建一个活动，并定义它的语法和语义。有时这些活动被称为“自定义活动”，这是为了与WF内置的活动相区别。我个人认为这个名字并不好，因为诸如Sequence和If这样的“内置”活动除了是有微软开发并包含在.NET Framework中之外，并没有任何特别之处。WF运行时并不会对内置活动有任何特殊的感知。事实上，任何开发人员都可以使用公开的活动API来编写自己的Sequence和If活动，而且在工作流中使用它们时，它们也会工作的很好。
活动是自描述的：活动定义了它自己的元数据和执行逻辑。从WF运行时的角度来看，活动只是一块包含了自定义行为的数据。WF程序只是这种数据树的一段描述。所以WF编程是纯声明性并且由数据驱动的。WF还提供了一组丰富的API来检查和创建活动树，类似CLR中的反射和反射发出（Reflection Emit）。这些API极大地提升了开发人员进行WF编程时的体验。一个明显的例子就是可视化设计器。WF团队提供了一组设计器，它们可以内置于Visual Studio，也可以脱离Visual Studio。任何人都可以不费力地创建新的可视化设计器（甚至新的文本语言）来构建活动树。

截至今日，.NET Framework中提供的许多“内置”活动是很轻量的。想要创建真实世界应用程序，开发人员就需要编写“自定义”活动来执行他们的任务。这些任务可能包括：

模拟业务逻辑的流控制，例如小组审查，当请求必须被多人审查并同意之后才能审批通过。
自动执行人类任务的活动，比如发送Email或运行一段管理员脚本。
连接其他系统的桥梁，比如使用特殊通讯协议来与Payroll系统通讯的活动。

现在我们知道活动是工作流编程体验的核心。WF开发人员必须真正理解活动。那么就让我们把活动推向舞台中央，来畅谈WF的活动模型吧。

分解活动

WF为开发人员提供了许多类来实现不同需求的活动。

图3. 活动模型类的层级

层级的顶端是Activity，它是WF中所有活动的基类。想要定义一个新的呃活动，开发人员需要实现Activity或者它的一个预定义子类的一个具体类，这些父类提供了不同的创作风格：

Activity

除了作为所有活动的基类并提供所有基本属性和方法之外，Activity类还可以用来直接以组合的方式定义活动。当子类直接继承自Activity时，开发人员可以通过创建已有活动的活动树来声明性地描述活动的实现。例如：

class Greet : Activity
{
public Greet()
{
this.Implementation =
() => new Sequence
{
Activities =
{
new WriteLine
{
Text = "Hello"
},
new WriteLine
{
Text = "World"
},
}
};
}
}

代码1. Activity类的使用示例

这段代码告诉WF运行时，当Greet运行时，它需要创建一个包含两个WriteLine活动的Sequence活动，并且将Sequence活动作为Greet的内部实现来执行。

当使用这个类来编程时，开发人员不能访问WF运行时的功能，比如书签。但它很简单并且完全是声明性的（译者注：如果不是以编程方式定义内部实现的话）。一旦社区里出现了丰富的活动库时，我们就可以将这种方式作为创建新组合活动的主要方式来使用。

CodeActivity

CodeActivity可以用来创作那些逻辑不存在于现有活动中的活动，它简单到只需要用代码实现一个Execute方法即可。

下面是一个示例：

class PrintFile : CodeActivity
{
protected override void Execute(CodeActivityContext context)
{
using (StreamReader file = new StreamReader("foo.txt"))
{
string line;
while ((line = file.ReadLine()) != null)
{
Console.WriteLine(line);
}
}
}
}

代码2. CodeActivity类的使用示例

使用CodeActivity非常简单，只需要实现它的Execute方法，此方法会在执行活动时被调用。CodeActivity非常适用于创建简单的叶活动。

AsyncCodeActivity

WF的一个主要价值就在于它支持长时间运行和异步服务。对于活动来说，需要执行长时间操作或者等待其他系统输入的活动是很常见的需求。我们不应该在WF的Execute方法里编写阻塞代码，这是因为它会阻止运行时去执行其他工作，并且服务可能会出现伸缩性和可用性问题。正如我门在《A developer’s view of Workflow》一文中的讨论，WF的“延续”（Continuation）就旨在解决这样的问题。一般来说，活动需要使用一组书签API来享受WF 延续的好处。为了节省开发人员的经历，AsyncCodeActivity提供了常见延续模式的高级封装：执行逻辑以代码方式实现，并且只有一个延续点。这种封装遵循了.NET的BeginInvoke模式并且隐藏了书签，以便于开发人员可以轻松地在WF中进行异步编程而不需要学习新的概念。这对于在WF中实现简单的异步IO来说非常完美。我们会在后续的文章中给出示例。

NativeActivity

如果活动的逻辑不能用现有活动的组成来表示，也不能由一个方法（或异步方法）来实现，就需要使用NativeActivity。例如，一些复杂的流控制模型，比如状态机。在开发NativeActivity时，开发人员需要站在WF运行时的高度来思考：他们需要将活动的执行过程视为队列中的计划工作项；他们能够直接访问绝大部分运行时计划功能，比如书签、取消、错误处理等等。使用NativeActivity的学习曲线是陡峭的，开发过程是复杂的。但是它同时又是最强大的活动创作方式，以及观察WF运行时内部的最佳窗口。在后续的日志中，我们将会尝试去创建一个NativeActivity，并深入观察WF运行时。

Activity<T>

有时候，你会希望活动能够“返回”一些值。例如，活动从文件或数据库获取了一些数据，并且需要将这些数据传递给工作流的剩余部分。WF定义了一系列泛型类来达成此目的。你会发现我们上面提到的所有活动类都有一个对应的泛型版本。例如，Activity<T>和Activity非常类似，它也支持组合风格的活动创作模式。但它还有一个名为Result并且类型为T的输出参数（我们需要单独写一篇日志来分析WF的参数概念）。Activity<T>的实现能够在执行期间为这个参数赋值，并且同一个工作流中的其他活动能够使用到这个值。

至于CodeActivity<T>、AsnycCodeActivity<T>和NativeActivity<T>全都拥有类似的情节所以就不再逐个介绍了。

未完待续……

本文翻译自：http://blogs.msdn.com/flow/archive/2010/01/24/lights-camera-activities-windows-workflow-foundation-s-activity-model.aspx

泛谈SharePoint 2010无代码工作流

Windie Chai — Sun, 24 Jan 2010 22:15:31 +0800

在1月16日的“SharePoint 2010 Day”活动中，我奉献了一节《SharePoint 2010：新一代无代码工作流》讲座，会后Choral兄让我把它拆成几篇日志，于是就有了本文（本文是当天课程去掉Demo之后再添油加醋的图文重现版）。

我们知道，工作流是真实世界中流程的抽象，在真实世界中，流程可以按照有没有人类参与来泛泛地分为两种：系统流程和人类交互流程。

系统流程是指那些没有（或者几乎没有）人类参与的流程，这种流程的执行过程早在设计阶段就能够完全预料，虽然某些情况下也可能会有少量的人类参与，但并不会左右流程的执行方向。

系统流程主要旨在解决系统以及数据之间的问题，我们可以把它视为服务或者过程。正因为系统流程如此简单，所以在SharePoint中有许多方式可以实现系统流程，比如Event Handler、Timer Job或者Console Application；也正因为系统流程如此简单，我们在面对一个需要实现的系统流程时，甚至不会（或者忘记了）将它与“工作流”这个看似高深的概念联系到一起。

而人类交互流程，既有人类参与的流程，才是我们最容易联想到“工作流”这个概念的流程。环顾我们生活的四周，人类交互流程无处不在。把真实世界中的流程抽象为数字化的工作流时，我们虽然能够尽可能多地处理每一种可能发生的情况，却很难知道工作流将来究竟会沿着怎样的路线执行。

人类交互使得工作流变得复杂，在SharePoint中，我们大多使用Visual Studio来实现人类交互流程，这是因为在SharePoint 2007时代，SharePoint Designer的工作流设计能力还不足以应付复杂的人类交互流程；而在SharePoint 2010时代，SharePoint Designer虽然仍旧不能设计可以循环回退的工作流（哦，这真是个令人沮丧的消息），但其大量新特性势必会让我们设计人类交互流程（或者系统流程）时更加得心应手，并且我们也可以看到，SharePoint Designer的工作流功能也一直在向着这个方向努力。

SharePoint 2007第一次引入了“工作流”这个概念。在SharePoint 2007中，工作流是基于Windows Workflow Foundation 3.0/3.5来构建的。SharePoint 2007内置了一些工作流来供我们使用，比如“审批”和“收集反馈”，但我们只能选择用或者不用，而不能修改这些内置工作流。除了内置的工作流之外，SharePoint 2007还允许我们使用SharePoint Designer 2007来设计无代码的工作流，或者使用Visual Studio 2005/2008来开发包含代码的工作流。

在SharePoint 2010中，工作流的底层基础结构依然是Windows Workflow Foundation 3.5（很遗憾没能够基于WF 4.0）。代码工作流的开发工具升级到了Visual Studio 2010，无代码工作流的设计工具也升级到了SharePoint Designer 2010。

SharePoint 2010将Office的一个重要的客户端成员，Visio，引入了工作流创作之中。众所周之，Visio是一个非常强大并且易用的图表设计工具，在SharePoint 2007时代，就有许多人在问“为什么不能用Visio来设计SharePoint工作流”这样的问题，因为用Visio可以很方便地设计出直观的流程图，相比而言，SharePoint Designer的工作流设计器却并不是那么令人满意。

我们可以在上图中发现，Visio和SharePoint Designer总是结伴出现，这是以为Visio只是一个工作流建模工具，它的作用只是帮助业务人员很方便直观的“画”出工作流流程图，这张流程图里只有简单的逻辑，而且没有包含任何数据，所以它必须经过SharePoint Designer补充加工之后才可以变成真正可以运行的SharePoint工作流。

除此之外，我们还可以使用Visio 2010和SharePoint Designer 2010来编辑SharePoint 2010的内置工作流（这种编辑并不是严格意义上的“编辑”，而是“复制并编辑”），对我们来说，这个功能不仅能够让我们修改内置工作流以满足我们的需求，也能够通过查看内置工作流的组成来学习如何用SharePoint Designer来无代码工作流。

在SharePoint 2007时代，工作流必须和列表或文档库做关联（或者绑定）之后才能够使用，这种工作流是一种列表级的工作流，在SharePoint 2010中，它被称为“列表工作流”。众所周知，列表工作流最为人所诟病的就是它难以重用，在使用SharePoint Designer设计列表工作流时，第一步便是选择需要关联的列表，并且工作流在设计完成之后，是无法将它复制到其他列表去使用的。

针对这个问题，SharePoint引入了一种新的工作流类型：可重用工作流。可重用本质上还是一种列表级的工作流，依然需要和列表做关联之后才可以使用，但我们在使用SharePoint Designer 2010来设计可重用工作流时，无需事先选择将要关联的列表，在工作流设计完成后，我们可以自由地将它关联到多个列表，甚至导出为一个WSP文件来部署到其他服务器之上。SharePoint 2010内置的几个工作流就是一种特殊的可重用工作流：全局可重用工作流，既可以在整个网站集的所有网站中重用的工作流，SharePoint Designer 2010可以让我们轻松地将一个普通的可重用工作流提升为全局可重用工作流。

除了必须和列表相关联之外，列表级工作流还有一个特点，就是必须基于一个列表项来启动。所以有些时候，我们为了使用一些系统流程，或者在流程执行期间才创建列表项的工作流，就不得不去准备一个无意义的列表，并且去创建一个无意义的列表项，只是为了启动一个工作流，无论从设计方式还是用户体验来说，这都不是一个令人满意的解决方案。SharePoint 2010中新增加的“网站工作流”则可以解决这个问题，顾名思义，网站工作流是一种网站级别的工作流，它不需要和列表做关联，也不需要基于一个存在的列表项来启动。如果需要启动一个网站工作流，可以直接在网站的【网站操作】【网站工作流】中进行操作。

由于Visio的引入，SharePoint 2010便有了三个工作流创作工具。其中，Visio凭借其易用直观的设计方式，为业务人员提供了设计工作流流程图的良好用户体验。业务人员在Visio中设计好工作流流程图之后，将其导出成为一个VWI文件，交给IT人员，IT人员再将其导入到SharePoint Designer中，补充逻辑和数据，使其成为一个可以运行的工作流。在这期间，由于各自领域和所用软件的差异，业务人员可能要与IT人员进行多次沟通。

如果在将来的某一天，无代码工作流已经无法满足我们的需求，IT人员就可以将其导出成为一个WSP文件，交给开发人员，开发人员再将其导入到Visual Studio中进行二次开发，经过这样一个过程之后，无代码工作流就变成了代码工作流。

此外，开发人员还可以使用Visual Studio 2010来为SharePoint Designer开发自定义操作，来丰富和补充SharePoint Designer的操作库。

以上便是我在“SharePoint 2010 Day”活动中奉献的讲座：《SharePoint 2010：新一代无代码工作流》的部分内容，本文略去了讲座中对于SharePoint Designer 2010新增的“自定义任务”的生命周期的相关介绍，以及关于网站工作流、可重用工作流、Infopath协同、Visio协同以及工作流状态图的相关Demo。如果时间和精力允许，我会将它们单独成文。

另外，感谢这次报名参加“SharePoint 2010 Day”活动的所有朋友，《SharePoint 2010：新一代无代码工作流》的PPT可以点击这里下载，此次活动的所有PPT可以访问这里获取。

如何在SharePoint 2010项目中引用UserProfiles.dll

Windie Chai — Fri, 15 Jan 2010 00:11:13 +0800

如果需要进行SharePoint的UserProfile开发的话，我们需要引用以下程序集：

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Office.Server.UserProfiles.dll

在添加引用的时候，Visual Studio 2010会弹出如下图所示的对话框，提示我们项目的.NET 版本太低：

强行引用之后，项目会因为找不到命名空间而无法编译，如果把项目的.NET版本改为4.0，这个问题就解决了。

然而SharePoint 2010依然基于.NET Framework 3.5的，如果你在.NET版本为4.0的项目中引用了Microsoft.SharePoint.dll并且企图实例化一个SPSite对象的话，在执行阶段会抛出一个FileNotFoundException，如下图所示：

那么如果想要在同一个项目中同时引用这两个程序集来进行开发该怎么进行？这个明显的冲突在SharePoint还是技术预览版的时候就让我郁闷不已，甚至连产品组的技术支持都没有给我明确的解答（一定是他们太忙了，我表示理解），今天在Kaneboy和十一的帮助下终于知道了如何去解决。

解决方法就是在.NET版本为3.5的项目中进行开发，额外引用下面这个程序集：

C:\Program Files (x86)\Microsoft Chart Controls\Assemblies\System.Web.DataVisualization.dll

最后再感慨一下，SharePoint到了2010时代，已经庞大的令人恐惧了。

Windstyle SlugHelper for Windows Live Writer发布

Windie Chai — Wed, 13 Jan 2010 22:20:00 +0800

什么是Slug？

Slug是用来描述日志或页面的一小段话，通常是日志或页面标题的URL友好化版本。

比如本插件页面的URL可以有两种形式，其中粗体字部分就是URL中的Slug：

http://coding.windstyle.cn/?page_id=859

http://coding.windstyle.cn/projects/windstyle-slughelper-for-windows-live-writer

虽然第一种Slug非常简短，但是我们并没有办法看懂它，更别提从它来推断出该URL所表示的页面的大致内容；而第二种就是友好的Slug，不仅对访客友好，也对搜索引擎友好。

什么是WindStyle SlugHelper？

WindStyle SlugHelper是一个开源的Windows Live Writer插件，它会在每次发布日志或页面时提醒你补全Slug，并会提供几种快速生成Slug的方式。

WindStyle SlugHelper提供的Slug生成选项包括：

不更改
同标题一致
将标题转换为中文拼音
使用Google将标题翻译为英文
使用微软Bing将标题翻译为英文
自定义

如何使用和参与WindStyle SlugHelper？

具体使用方法请移步至此页面。

让代码看起来更舒服（2）：选择适合的字体

Windie Chai — Sun, 22 Nov 2009 22:38:29 +0800

上一篇文章我和大家分享了一些Visual Studio的配色方案，以及一个用来生成配色方案的网页版工具，现在我再来和大家分享一下Visual Studio的字体设置。

字体不仅是设计师手中重要的武器，对我们开发人员来说，字体的选择也有许多讲究，一个好的、适合展示代码的字体，应该具备以下要素：

等宽的字符
简洁、清晰并且规范的字符形状
支持ASCII码为128以上的扩展字符集
与字符同等宽度的空格
易于分辨的小写字母l、大写字母I、数字1和符号|
易于分辨的大写字母O和数字0
易于分辨的前引号和后引号，最好能够前后对称
易于分辨的其他标点符号，尤其是大括号、中括号、小括号和尖括号
良好的中文支持和显示

下图展示了一个极端的反例，虽然很有个性，但并不适合用来显示代码。它的大写字母大的可怕，小写字母却小的可怜；字符不仅不清晰，而且不规范；小写字母l、大写字母I、数字1和符号| 难以分辨；大写字母O和数字0难以分辨；标点符号还凑合，只是下划线为什么是断开的？

当然，这个反例的确有些夸张，但其上文所列举的条件是比较苛刻的，我们在选择字体时没有必要非要完全满足所有条件，事实上这种字体也是凤毛麟角。下文所分享的一些字体也并没有完全满足所有条件，我们发现，只要满足了其中一些关键条件，用来显示代码就已经很不错了。

在Visual Studio中，更改编辑器的字体是件简单的事情，选择菜单【工具】【选项】，在弹出的“选项”对话框中依次选择“环境”和“字体和颜色”，然后在“显示其设置”中选择“文本编辑器”，最后在“字体”中选择字体就可以了，如下图所示：

在上图中，我们发现Visual Studio已经将等宽字体用粗体标识了出来，这样做是为了让我们更容易找到等宽的字体，并不表示等宽字体就一定适合显示代码，比如下图所示的“新宋体”就是一个反例：

在新宋体中，数字0之比大写字母O瘦那么一点点，小写字母l和数字1也十分相像，幸亏配色方案能够颜色将它们区别开来，否则实在难以分辨。这也从另一个角度说明了配色方案与字体是相辅相成的，搭配恰当时，会让代码更加清晰易辨。

下面就和大家分享一些在编程界声名烜赫的字体，截图所采用的配色方案为HumaneStudio，展示顺序为字体首字母升序。这些字体可能乍一看都一样，但仔细品味，还是能够发现不同的味道，希望大家都能找到适合自己的字体。

Andale Mono，演示字号为14，猛击这里下载：

Anonymous Pro，演示字号为14，猛击这里下载：

Bitstream Vera Sans Mono，演示字号为14，猛击这里下载：

Consolas，演示字号为14，Windows或Visual Studio已内置：

Courier New，演示字号为14，Windows已内置：

DejaVu Sans Mono，演示字号为14，猛击这里下载：

Envy Code R，演示字号为16，猛击这里下载：

Inconsolata，演示字号为16，猛击这里下载：

Monaco，演示字号为12，猛击这里下载：

Monofur，演示字号为16，猛击这里下载：

Progmata，演示字号为14，猛击这里下载：

Share TechMono，演示字号为16，猛击这里下载：

注：此字体似乎会将连在一起的fl显示为一个点，不建议使用，可惜可惜。

尾注：

本文所分享的字体均支持ClearType。
中文的显示的确是一个影响美观的重要因素，所以产生了许多微软雅黑和一些优秀英文字体的混合版，但其实还有一种方法可以快速而简单的实现用不同的字体显示中英文，方法如下：
- 用文本编辑器打开%AppData%\Microsoft\VisualStudio\9.0\VsFontLk.dat；
- 将0804一行修改为需要的中文字体，格式为“0804|中文字体名称”，比如“0804|微软雅黑”；

让代码看起来更舒服（1）：选择适合的配色方案

Windie Chai — Thu, 19 Nov 2009 22:16:58 +0800

“让代码看起来更舒服”，看到这个标题，也许你会条件反射地以为我要讲“重构”或者“编码规范”等等。噢，可爱的开发人员，我们暂且不谈技术，只谈体验。让我们来装扮一下每天都要面对的Visual Studio，让代码看起来更舒服。

下图展示了Visual Studio 2008默认的编辑器，为了让代码更加容易辨识，Visual Studio用不同的颜色将各种关键词区分开来。

默认的配色方案固然无可厚非，每当夜深人静的时候，它总是能让我热泪盈眶。我当然没有矫情到被自己的代码感动，而是我脆弱的眼睛实在受不了它那惨白的背景色。

于是我决定要做出一些改变。

好在Visual Studio可以方便地设置代码配色方案，选择菜单【工具】【选项】，在弹出的“选项”对话框中依次选中“环境”、“字体和颜色”，在“显示其设置”中选中“文本编辑器”，然后我们就可以随意地更改代码编辑器的字体和配色方案了。

好吧，我承认自己动手调整配色方案是一件机械式的体力活，开发人员最痛恨机械式的体力活。有这时间还不如Google一下，看看有没有前人栽好的树供我们乘凉，于是我找到了一些配色方案，只要导入到Visual Studio中，就可以马上看到效果！

导入配色方案的方法很简单，选择菜单【工具】【导入和导出设置】，在弹出的“导入和导出设置向导”对话框中选择“导入选定的环境设置”，然后根据自己的实际情况选择“是，保存当前设置”或“否，仅导入新设置，覆盖我的当前设置”，然后点击“浏览”来打开一个Visual Studio Settings File（扩展名为.vssettings）。

需要注意的是，Visual Studio Settings File包含了Visual Studio的各种设置，所以如果你导入的设置文件除了下图所示的“字体和颜色”之外，还有其他设置，请小心勾选。

下面是一些我找到的配色方案，以及它们显示同一段代码的效果图，大家挑选喜欢的下载吧。

Jeff-atwood，猛击这里下载：

HumaneStudio，猛击这里下载：

2008-DarkGrey，猛击这里下载：

2008-Ragnarok_Grey，猛击这里下载：

2008-Moria_Alt，猛击这里下载：

2008-Nightingale，猛击这里下载：

2008-DesertNights，猛击这里下载：

尾注：

由于年代久远，我已经记不清这些配色方案的出处了，所以没有注明来源。
这些配置文件均为Visual Studio 2008配置文件，我没有在Visual Studio其他版本做测试，不保证兼容性。

如果上述这些配色方案仍然不能满意的话，可以尝试一下国外友人开发的Visual Studio Theme Generator，只需要简单的设置一下基色调和对比度就可以生成一个Visual Studio配置文件了，需要的话，请猛击这里。

SharePoint 2010工作流系列（4）：初窥Visual Studio 2010的SharePoint工作流功能

Windie Chai — Mon, 16 Nov 2009 23:16:52 +0800

介绍完针对IT人员的SharePoint Designer 2010和针对业务人员的Visio 2010，我们再来看一下Visual Studio 2010为SharePoint开发人员提供了哪些便利。

在Visual Studio 历代版本中，Visual Studio 2010的变化算是比较大的。就连同时发布的.NET Framework 4.0也将CLR从2.0一下子升级到了4.0。

在新建项目对话框中可以看出，Visual Studio 2010仍然支持SharePoint 2007项目，不过只有工作流项目。而在SharePoint 2010分类中，却多出了如此多的内容，这便是全新的Microsoft SharePoint Development Tools。

由于SharePoint 2010的工作流仍然基于WF 3.5，所以我们仍然可以并且只能创建Sequential和State Machine两种工作流（SharePoint 2010没有使用WF 4.0真是件让人扫兴的事情）。除了这两种经典的工作流类型之外，Visual Studio 2010还能够导入由SharePoint Designer 2010设计的Reusable Workflow。

SharePoint 2010引入了一种新的解决方案类型，叫做sandboxed solution。SharePoint网站管理员可以不经过服务器管理员之手，直接将解决方案部署到网站集范围内，而且该解决方案的操作范围也被限制在部署它的网站集中。这极大地方便了简单解决方案的部署和使用，相信将来SharePoint 2010 Online推出之后，这种解决方案一定会大放异彩。不过SharePoint工作流并不支持这种部署方式，我们只能老老实实地将它设计成为一个farm solution，如下图所示：

Visual Studio 2010也能够创建SharePoint 2010新增的工作流类型：Site Workflow，如下图所示：

Visual Studio 2010并没有像SharePoint Designer那样大量新增活动，相比上一版本，只增加了如下图所示的几个活动：

此外，由于Site Workflow根本没有和具体的列表项绑定，所以不能使用和列表项相关的OnWorkflowItemChanged和OnWorkflowItemDeleted两个活动，其余所有活动都和List Workflow相同，这一点和SharePoint Designer 2010相似。

活动的变化暂时先看到这里，下面我们来看看其他变化，下图展示了Visual Studio 2010的SharePoint工作流解决方案资源管理器：

我们看到两个崭新的文件夹：Features和Packages。Microsoft SharePoint Development Tools提供了在组织解决方案内的Feature和Package的能力，通过这一功能，我们可以以图形化的方式来组织和管理Feature和Package，十分方便。下图展示了崭新的Feature编辑器：

在下图所示的添加项对话框中，我们可以看到，除了Sequential Workflow和State Machine Workflow之外，和工作流相关的可添加项还有Workflow Association Form和Workflow Initiation Form。

这两种页面的格式都是ASPX，但很可惜的是并没有提供可视化设计支持。我宁愿相信这也是beta版本的原因，因为Visual Studio 2010新增的Visual Web Part都能够使用可视化的方式来设计了。不管怎么说，我们终于可以比较方便的为工作流设计基于ASP.NET的启动页面和关联页面了。

当然，我们仍然可以使用InfoPath表单作为工作流的启动页面和管理页面。和上一版本一样，我们需要手工修改Workflow.xml文件，添加必要的宿主页面、内容类型ID和表单URN，Visual Studio 2010并没有替我们完成这部分内容（令人不解的是，为什么不把宿主页面和那个长长内容类型ID也像表单URN的相关元素一样注释起来，以供我们更加方便地使用呢？）。

我们从上面的解决方案资源管理器中看到的Elements.xml就是以前的Workflow.xml，并且由于新增了Site Workflow，Elements.xml的MetaData元素中也相应地增加了一个AssociationCategories元素，用以标识工作流时List Workflow还是Site Workflow。

本来想尝试用SharePoint Designer 2010和Visio 2010设计一个包含它们特有的操作（活动）的Reusable Workflow，然后保存为WSP模板，再使用Visual Studio 2010导入，看看会发生些什么。

结果可耻的失败了数次，唯一的收获就是发现如果Visio 2010设计的工作流流程图如果包含了那四个神秘的权限操作的话，虽然导入到SharePoint Designer 2010里可以正常识别并且设置属性，但是在检查错误的时候就会提示该活动放错了位置，只要将其移动到SharePoint Designer 2010新增的Impersonation Step中，错误就会得以解决。

我猜想是因为设置权限这种操作本身就需要更高的权限才能执行，而SharePoint 2010的工作流貌似已经是以启动工作流的用户权限来运行了，只有其中的Impersonation Step才会以工作流作者（代表着更高的权限？）的权限去执行。

另外播放一条小道消息，Office 2010 beta马上就要公开发布了，我已经提前拿到了这一版本。

SharePoint 2010工作流系列（3）：初窥Visio 2010中SharePoint工作流功能

Windie Chai — Wed, 11 Nov 2009 21:53:20 +0800

介绍了SharePoint Designer 2010的变化之后，我们再来看看Visio 2010是怎样在SharePoint工作流中发挥作用的。

打开Visio 2010，SharePoint工作流的图表模板位于Flowchart分类中，叫做Microsoft SharePoint Workflow（Metric），如下图所示，选中它，点击Create来创建一个SharePoint工作流流程图。

和SharePoint Designer 2010一样，Visio 2010也使用功能区取代了古老的菜单，下图显示了Visio 2010的工作界面：

在Visio 2010左侧的Shapes面板中，罗列了可以用来设计SharePoint工作流的形状，我们可以看到，Visio将这些形状分为3类：

SharePoint Workflow Actions
SharePoint Workflow Conditions
SharePoint Workflow Terminators

从上图可以看出，Visio 2010里用来设计SharePoint工作流的形状基本和SharePoint Designer 2010保持一致，不过它多出4个我们在上一篇文章中没有见过的形状，如下图所示：

这4个形状全部和列表项的权限设置有关，既然我们没有在SharePoint Designer 2010中发现与之对应的操作，那么将使用了这些形状的流程图导入到SharePoint Designer 2010中会发生些什么呢？我们来试试看：

SharePoint Designer 2010正确地将这4个形状识别为操作，并且可以正常设置属性。那么这4个光看名字就知道极为有用的操作为什么没有办法在SharePoint Designer 2010中直接添加呢？我宁愿相信是测试版的原因……

既然Visio 2010也可以绘制SharePoint工作流，那么它能不能够取代SharePoint Designer 2010？

答案是不能。

首先，这两款软件所面向的人群不同。Visio 2010面向业务人员，业务人员可能对SharePoint这个庞大系统的许多知识并不了解，但他们却熟知业务流程；而IT人员正好与其相反，他们熟悉SharePoint，却对业务缺乏了解，所以SharePoint Designer 2010才是他们应该使用的工具。

其次，这两款软件的分工不同。业务人员使用Visio 2010来绘制流程图时，需要做的仅仅是把自己掌握的业务逻辑用Visio提供的形状和连线表达出来，导出为一个.vwi文件，然后将这个文件交给管理SharePoint网站的IT人员就可以了；而IT人员则需要将此文件导入到SharePoint Designer 2010中，然后添加参数、配置属性，最终发布到SharePoint网站中成为真正可以运行的工作流。

综上所述，如果Visio 2010离开了SharePoint Designer 2010，它设计的工作流就仅仅是一张流程图而已。这种明确的分工使得业务人员终于能够不需要具备SharePoint和SharePoint Designer相关知识就能够轻松地参与到工作流设计工作中了。

我总是对SharePoint Designer工作流不支持循环耿耿于怀，于是尝试在Visio中绘制了一个可循环的流程图，果然提示工作流存在问题，无法导出，如下图所示：

同时Issues面板中明确地告诉我们，SharePoint工作流不支持循环，如下图所示：

关于Visio 2010在SharePoint工作流方面的内容就介绍这么多，当然，除了工作流功能之外，Visio 2010还可以把设计图发布到SharePoint 2010，SharePoint 2010内置了一个与之对应的服务叫做Visio Service，我们在第一篇文章中看到的工作流状态图就是使用这个服务来展示的。

『听风且吟』技术版

Adobe PDF Reader COM组件（axAcroPDFLib）的退出问题

相关日志

WindStyle ExifInfo for Windows Live Writer发布

什么是Exif？

什么是WindStyle ExifInfo？

如何使用WindStyle ExifInfo？

相关日志

WF4.0活动模型（1）：工作流既活动

分解活动

Activity

CodeActivity

AsyncCodeActivity

NativeActivity

Activity<T>

相关日志

泛谈SharePoint 2010无代码工作流

相关日志

如何在SharePoint 2010项目中引用UserProfiles.dll

相关日志

Windstyle SlugHelper for Windows Live Writer发布

什么是Slug？

什么是WindStyle SlugHelper？

如何使用和参与WindStyle SlugHelper？

相关日志

让代码看起来更舒服（2）：选择适合的字体

相关日志

让代码看起来更舒服（1）：选择适合的配色方案

相关日志

SharePoint 2010工作流系列（4）：初窥Visual Studio 2010的SharePoint工作流功能

相关日志

SharePoint 2010工作流系列（3）：初窥Visio 2010中SharePoint工作流功能

相关日志

『 听 风 且 吟 』技术版

Adobe PDF Reader COM组件（axAcroPDFLib）的退出问题

相关日志

WindStyle ExifInfo for Windows Live Writer发布

什么是Exif？

什么是WindStyle ExifInfo？

如何使用WindStyle ExifInfo？

相关日志

WF4.0活动模型（1）：工作流既活动

分解活动

Activity

CodeActivity

AsyncCodeActivity

NativeActivity

Activity<T>

相关日志

泛谈SharePoint 2010无代码工作流

相关日志

如何在SharePoint 2010项目中引用UserProfiles.dll

相关日志

Windstyle SlugHelper for Windows Live Writer发布

什么是Slug？

什么是WindStyle SlugHelper？

如何使用和参与WindStyle SlugHelper？

相关日志

让代码看起来更舒服（2）：选择适合的字体

相关日志

让代码看起来更舒服（1）：选择适合的配色方案

相关日志

SharePoint 2010工作流系列（4）：初窥Visual Studio 2010的SharePoint工作流功能

相关日志

SharePoint 2010工作流系列（3）：初窥Visio 2010中SharePoint工作流功能

相关日志

『听风且吟』技术版