Author Archives: liuhuimiao

临时发个招聘信息，希望给大家多提供一些类似机会。 1、工作地点：中国上海市。2、熟悉微软技术和平台，包括：Active Directory，.NET 2.0/3.0/3.5，Visual Studio，SQL Server，Silverlight/WPF, WCF等。至少3年以上的.NET平台开发工作经验。3、至少1年以上的项目管理经验。4、良好的沟通能力和团队精神。 如果您对该工作感兴趣，请发送简历至：shtao@microsoft.com 我们恭候您的加盟！！！ ——————邪恶的分割线——————另外，在博客堂呆了快7年了，时间真快，从最早的.net 1.0至今.net 4.0，都已经7年了。不管如何，感谢开心提供了这么好的一个地方，见证了.NET蓬勃发展的历程。由于个人最近心血来潮，将博客迁移到 http://www.liuhuimiao.com 和http://blogs.msdn.com/liuhuimiao 了，以后这里就不更新了。谢谢开心，谢谢大家。

【时间飞逝，在博客堂也常驻了6年多了。有感于经常有人反映说博客很久没更新了，加上近期确实也想把前几年做过的大大小小二三十个项目做个总结。于是决心每个月都花点时间来写点东西，长篇或随笔都好。前些日子讲了两三天关于如何交付好MOSS项目的课后，结合以前实施经验，又有一点心得，就以此作为开头，慢慢做一系列的原创总结了。】 文章目的：希望通过此文，能让读者了解搜索的本质和基于MOSS的企业搜索方案，在此基础上站在项目管理角度掌握如何实施好这类方案的项目的关键点，确保企业搜索项目成功交付。由于文章长度限制，本文分上下两部分，上部分包含搜索简介和基于MOSS的企业搜索的方案说明；下部分将涉及站在项目管理角度如何实施好这类方案。 一、企业搜索简介     搜索，目前是个比较热门的词。一提到搜索，我们的第一反应就是Bing、Google或Baidu。事实上，搜索的定义范围更广。一般上按应用范围划分，我们将整个搜索行业分为互联网搜索、企业搜索（局域网）和桌面搜索（个人电脑桌面）三个层面。目前，每个层面都有许多知名产品占据着主要地位。如下图所示：     在这里我们就不重点去说各个产品的优缺点对比了。我们需要更加关注的是，所有的搜索产品具有的共性，或者说，搜索解决方案的核心运作模式。这点对我们后面的项目目标范围确定、方案设计、项目的具体实施等都具有非常关键指导作用。     站在使用者角度，回想一下你通过Bing、Google或Baidu进行搜索的主要场景：输入关键字，按搜索按钮进行查找，然后搜索引擎罗列出找到的所有信息条目。然后，我们换个角度，站在搜索产品（或者说搜索引擎）的角度，思考下它的主要场景，将会得出所有搜索产品的核心运作模式：内容源–>搜索引擎–>呈现结果。如下图所示：     首先，内容源是基础。在客户内部，肯定事先有大量的数据内容以各种形式存放在各种地方（如存放于Web站点的网页、存放于共享文件夹里的各种文档、存放于业务系统中的业务数据等等），这种现象造成的各种问题（如数据难以共享、数据难以萃取成有价值的信息等）就是客户的烦恼痛点所在。换个角度说，也就是我们搜索解决方案项目要解决的问题。     其次，搜索引擎是技术手段。用搜索引擎来对所有的内容源进行数据信息提取、清洗、分类整理乃至智能分析、相关度设置等，以形成各种有价值的信息提供给使用者。也就是说，搜索引擎是我们萃取数据为信息的一种技术手段。好的搜索引擎除了在性能上体现为更快，在数据的分析整理等涉及到数据质量问题的处理上也更加智能化、个性化。这也就是为什么说性能好坏和数据信息质量的好坏是判断搜索引擎好坏的两个主要标准了。因此，在我们实施企业搜索的项目中，这点是项目的关键技术点，需要进行比较多的技术攻关工作。     第三，呈现结果是目的。通过搜索引擎进行数据萃取后，最终将结果呈现给使用者。呈现结果的机制也可以看成是搜索引擎的一部分，只是它表述更多的是一种用户体验，将搜索结果以更好的用户体验方式呈现给最终用户。就像上面提及的，站在使用者的角度，他所关心的就是“帮我寻找我要的信息”——既要找到信息，而且找到的信息是我要的。这两点也正好是搜索解决方案所要达到的的目标。     在宏观上理解了搜索后，接下来我们简单了解下企业搜索。企业搜索自然也遵循上述搜索核心运作模式，同时具有自己的一些典型特征： 内容源：企业局域网内的各种资源，包括位于企业内部门户网站、共享文件夹、FTP站点、Exchange公共文件夹等内的各式各样的文档资料及业务系统内部的业务数据等。 范围：主要针对企业局域网内部的资源。 数据量：中等（相对互联网搜索来说）。 安全性：安全性要求高且灵活。 爬网索引：依企业IT管理策略而定制。 二、基于MOSS的企业搜索方案     在搜索行业的三个层面里，微软都有相应的主流产品——互联网搜索的Bing，企业搜索的MOSS/FAST和桌面搜索的WDS。对于企业搜索，微软又分别做了市场细分，针对每种细分场景提供相应的企业搜索产品和方案。     我们这里只谈基于MOSS的企业搜索解决方案，对于微软的其他企业搜索产品，如Search Server、FAST等这里就略过，其实站在“实施好企业搜索项目”这个方向上大致原理都类似，区别的仅仅只是其中具体技术细节。     根据搜索的核心运作模式，结合MOSS特点，整个基于MOSS的企业搜索解决方案主要包括以下内容： 内容源的梳理：内容源是搜索方案的基础。内容源的梳理工作做得好，将起到事半功倍的作用。这点在后面如何实施好搜索项目中将具体细化讲述。 搜索引擎的定制：根据需求对MOSS搜索引擎做相应的功能定制，比如支持PDF和AutoCAD文档索引、支持爬FTP站点、相关度调整、用户权限的整合等。这方面的定制将涉及MOSS搜索引起的几个关键技术点，将在后面如何实施好搜索项目中进一步描述。 良好的用户体验：根据用户对信息格式的要求和使用习惯设计搜索呈现结果相关页面。除了基本的搜索结果元素呈现外，还包括最佳匹配、热门关键字、关联提示、联合搜索等。 部署方案：根据数据量、用户量及客户的实际IT环境设计部署方案。诸如需要多少台服务器、各种角 色的服务器怎么安排、对网络带宽的要求等。同时应该提出在可见的未来，数据量持续增加或用户量增加的情况下，如何调整以适应新情况。 持续的运维规范： 持续的运维优化，是所有基于MOSS的方案（包括企业搜索）必须涵盖的内容。只有通过一系列的管理、运营、维护规范来保证MOSS应用的正常运作，才能使得MOSS应用富有生命力。     基于MOSS的企业搜索方案的系统架构图如下所示：基于MOSS的企业搜索应用设计成为既是一个企业搜索应用，同时是一个可以为第三方应用提供搜索服务的基础服务。     … Continue reading →

先讲一个寻人启事的故事。 很久很久以前，他想寻一人，不得不知道她的所在地址，方能根据地址过去找到她。不幸的是，找到她了，但因操着不同语言而无法沟通，他又不得不找一个翻译来保证他与她之间的沟通顺利。很久很久以后，他想再寻一人却不知道她具体地址，他先守株待兔，看看她会不会突然冒出来和大家Say Hello，然后自己再跑上去搭讪。这种可能性貌似很小，除非她和自己一个小区。他拍脑袋一想，她如果在本市的话，肯定事先在派出所那边登记过资料了，于是就到拥有全市户口资料的派出所去打探，看看派出所那边能否提供她的资料并帮他们搭线上。 不得不承认，这是一个无聊的故事，和下面这个有的一拼。 WCF 3.5 中，当我们要调用一个服务时，必须事先知道该服务的地址，然后通过服务代理用双方约定好的契约与远程的服务进行交互。现在，WCF 4.0中提供了发现服务的支持，当我们再想调用一个服务时，没必要去知道该服务的具体地址，只需要利用 System.ServiceModel.Discovery 命名空间下的相关类就可以实现两种方式的动态发现服务： Ad hoc Mode：简单理解，就是服务启动时就向网络广播Hello消息，调用方收到后进行回应建立通讯的模式。 Managed Mode：简单理解，就是所有服务事先在一个叫 Discovery Proxy 的地方登记，然后所有调用方发送查找请求给 Discovery Proxy 来查找并调用相关服务的模式。 这个故事到此为止，比喻不是很恰当，但至少可以有一个比较感性的认识吧。更详细，可以看下下面原理说明： WS-Discovery 1.1 规范：http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html  Discovery Concepts：http://blogs.msdn.com/discovery/archive/2009/05/29/discovery-overview.aspx WCF Discovery：http://msdn.microsoft.com/en-us/library/dd456782(VS.100).aspx  WCF 4.0中要动态发现服务，用 Ad hoc Mode 实现起来还是比较简单的，下面就以代码方式先看下如何实现。对于Managed Mode，就需要继承 System.ServiceModel.Discovery.DiscoveryProxy 抽象类去实现自己的 Discovery Proxy … Continue reading →

顺利装好 VS 2010 Beta2 后，新建项目，打开.cs代码文件，结果报错误。不仅仅是代码文件，只要是相关的文件，如 xml, .config等均报此错误。 按照提示，用 /Log 参数启动VS IDE，查阅Log说是 Editor 问题导致此错误。后来核对了半天，才发现原来我在 VS 2008 中设置编辑器字体为 Fixedsys 字体，安装完 VS 2010 后将这个设置也带来过，结果目前 VS2010 Beta2 好像还不支持编辑器字体替换，换回“新宋体”或 Arial 等其他字体后，就没有再出现此错误了，所有代码文件都顺利打开。 造成这个问题的原因是因为VS 2010 整个 IDE 已经基于 WPF 重写，因此只支持 True Type 字体，而之前用的 Fixedsys 字体并非此类型，所以就报错导致所有文件都无法打开。后来了解到在更新版本里头，如果碰到不是 True Type … Continue reading →

【SharePoint】： SharePoint (MOSS) 2007 有了一个 SharePoint Online 服务了。这个是 Microsoft Online Services 的一部分，也是微软的“Everything could be hosted” 口号的具体落实。除此之外，还有 Exchange Online，Office Communications Online，CRM Online。 CheckList for custom code (MOSS 2007)： 采用对象模型的自定义开发方式，使得开发人员可以在MOSS 2007平台上进行各类扩展方案开发。但是同时，一个粗糙不当的设计或实现，都将把MOSS自定义应用带入深渊，轻则慢得比乌龟还慢，重则异常不断经常出错。这个时候，或许该下载一份 Code Checklist 给开发人员，好好对这 checklist 一条一条检查看看是否符合，以此在避免不必要的风险下，尽情享受到MOSS2007各种好处。 SharePoint Governance：貌似Governance这词比较酷还是怎么的，越来越多人喜欢用这个词了。比如 IT Governance，翻译为IT治理；那么 SharePoint Governance，就叫SharePoint … Continue reading →

MOSS里的CMS/Portal，需要进行高度的自定义，除非你觉得MOSS默认的“款式”就是你要的。PixelMill，我觉得它所发布的SharePoint SimpleCMS就是一款不错的应用。你可以观看 Video: Simple CMS for WSS，看看这个应用的一些具体使用方式，吸收下实例经验。我个人比较喜欢其中自定义的图片上传方式和新闻发布方式，这些符合用户操作习惯的应用才能生存。 MOSS里的Search，也是很好很强大的。在Codeplex中已经有了一个Search Community ToolKit，可以让你如虎添翼。比如其中的Smart Search，可以做出常见的相关搜索、搜索排行等，上海科技网站的搜索就是其中一个示例。   在SharePoint Team Blog上介绍了一个很酷的SharePoint应用：Wonders。在那个Virtual Earth Flash上标注的各种颜色的小点，实际上是读取SharePoint List中的数据信息动态显示的。这是一个非常好的SharePoint数据整合范例，就像文章说的："IDV Solutions’ Visual Fusion software extends SharePoint to create a visual composite application platform, empowering users and the enterprise to consolidate data and … Continue reading →

不知不觉之中，又有一个新概念逐渐充斥在各个技术社区中。OBA，全称为 Office Business Applications，较早之前，Javed Sikander在MSDN中发表了一篇名为《Building Office Business Applications: A New Breed of Business Applications Built on the 2007 Microsoft Office System》的文章中定义它为“a new breed of easily customizable solutions that address real-world business problems through the 2007 Microsoft Office system”。但在我能看到的大多数介绍OBA文章中更接近Justin的定义——“Office Business Applications … Continue reading →

1. 关于Check-out 锁定的错误: 当针对表单库关联Workflow后，用InfoPath客户端打开表单填写表单，填写完直接用Save保存回表单库。按设置，一保存回去就自动触发了工作流。但是触发后，有时可以，有时却报了Occured Error的错误，工作流加载失败。 由于有存在成功的现象，因此怀疑哪里环境出了问题。后来在Central Administration v3中配置了记录Workflow Infrastructure的详细日志，才发现出现了说该表单被Check out，然后已经处于锁定状态，所以工作流无法启动的异常信息。 这是个非常奇怪的问题。一直无法找到真正问题根源，不知是否为Bug。最后只能绕过该问题，在表单最后放了一个提交按钮，自动提交后自动生成唯一文件名保存在SharePoint Form Library中，然后马上关闭表单即可。 2. 用SPD 2007设计Workflow的建议： 记得，开发人员不到万不得已不要用SharePoint Designer 2007来开发工作流。这种事情让业务人员（如果有这种业务人员）去干这活吧。毕竟我个人以为SharePoint Designer 2007应该是定位在业务人员使用上的。开发人员老实开发Activity让业务人员用SPD 2007去设计工作流，或者直接用VS2005开发设计工作流才是正确的做法。 SharePoint Designer 2007和Visual Studio2005两者用来设计工作流的初衷都是为了让技术人员尽量管技术，让业务人员尽量分析处理业务。对此，DSL是用于沟通IT人员和业务人员的一个不错的选择；但Visual Studio 2005下的设计工作流更适合于开发人员，只不过通过DSL来缩小了与业务人员之间的Gap。而SharePoint Designer 2007，经过我这段时间作为开发者的快乐并痛着的经历，我觉得它完全是为业务人员而定制的一个产品，而非开发人员。最有力的证据就是——对SPD 2007设计的工作流的部署！你在测试环境用了SPD 2007进行设计了工作流，那就别指望能完全正确的直接部署到正式环境中，最有效的做法就是完全用SPD 2007再在正式环境中实施一次，或者用了站点模板部署后起码你还得用SPD 2007再打开正式环境的Workflow“编译”一次。这是一个另人抓狂的动作。 3. 基于Silverlight的Web Workflow的想法： 以前，有一个想法，就是做一个基于WPF的MOSS Document Sync工具。用于本地文件夹与MOSS … Continue reading →