navyliu

工作忙，废话少说：

1.把Assembly对应的dll部署到GAC的同时，还需要把对应的.pdb文件拷贝到GAC中，最好的方式是在部署脚本中用xcopy命令把.pdb文件拷贝到GAC中；

2.剩下的工作就和ASP.NET的Debug差不多了，调试的时候附加到当前的w3wp进程，在需要跟踪的地方设置断点即可进行调试了。

一个小窍门，在调试附加进程的时候，经常会有很多的w3wp进程，哪一个才是你需要调试的进程呢，采用如下的命令，

iisapp –a 

可以列出所有应用程序池对应的PID号，找到你调试站点的应用程序池，在调试的时候附加到对应的PID号即可。

今天开发了一个Custom Field Type，部署后，在New一个这个Field的时候，老出现FieldType的程序集不能加载的错误，提示是页面加载这前程序集没有编译什么地，用对应的E文Google了一下，还真有这个错误，犯的人还不少，以为遇上了大毛病，结果有点冒鼻血，解决方案就是IISReset。

呵呵，SharePoint的一些部署是需要重启IIS的，不求甚解如我的，部署Features后，最好先来一个IISReset。 谨记以防后犯。

这两天在开发自定义的字段。在字段部署的时候，遇到了几个问题。后来在SharePoint SDK中找到十分简单扼要的Custom Field 的部署方法，先记录下来。

Custom field types are deployed at the server farm-level, using the Windows SharePoint Services Solution Deployment functionality.

The various pieces of a custom field type solution must be deployed to the following locations:

• The field type class must be deployed as a strong-named assembly to the global assembly cache.
• The field type definition XML file must be deployed to the same location as fldtypes.xml, the XML file that defines the base Windows SharePoint Services 3.0 field types:  

\program files\...\web server extensions\12\template\xml\

Each field type definition must be included in a file named fldtypes*.xml. For example, if you have a field type definition for a field type that defines a Social Security Number, you might name the XML file fldtypes_ssn.xml.

• If you have specified a custom field editor user control for the field type, it must be deployed to the following location:

\program files\...\web server extensions\12\template\controltemplates\

在开发Custom Field Type的时候，Reflector是一个很好的工具，可以很方便的获得Assembly Information参数。

前天做一个会议通知的功能，发现一个比较奇怪的问题，我编程获取的时间值和系统显示的时间值不一致，真是一个比较奇怪的问题。

于是赶紧Google一下，初步确定是Timezone的问题。SharePoint的RegionalSettings中有一个Timezone，SharePoint存的是UTC时间，和我们的Timezone有8个小时的差别。必须要将内部存储的时间修改为LocalTime。

下面是转化的代码。timezone.UTCToLocalTime(DateTime.Parse(starttime)).ToLocalTime()

Timezone是一个SPTimezone变量，可以通过SPWeb的RegionalSettings获得对应Timezone。

今天编程创建一个站点，遇到了一个小小的问题。根由是没有理解SPWebCollection.Add方法中的nCLID这个参数。

刚开始，我以为nCLID和WebTemplate有关的参数，就按照例子中的参数设置为1033，结果遇到了“服务器不支持此语言”的异常，但是并没有想到这个异常和nCLID参数有关。于是google了半天，但是始终没有解（google的也都是E文的东西）。

偶尔看到一个帖子，上面的nCLID的设置并不是其他帖子指定的1033，而是web.Language。我马上照猫画虎把我的代码部分也换成这个，OK，执行通过。

这我才清除这个nCLID是MOSS对应的Localization的ID。看看SDK的解释：

英文不好如我的，还真很难准确理解locale id的含义。对于汉语，这个ID不是1033，而是2052，难怪会出错。

在这里不由得要抱怨一下，MOSS的文档相对于.net framework的开发文档来说，质量差太多了，尤其是少有Samples，当然没有中文的文档。对我等MOSS生手来说，确实有很大的难度。

在google或者百度中搜相关的信息确实少之又少。而百度中搜索的直接是毫不相关的内容在前面，太令我失望了，因此我技术资料搜索再也不用百度了。

英文的资料要齐全一些，但是前提是需要将服务器设置为英文的，这样异常提示才会是英文的，但是迁移到中文环境中估计又会有一堆的问题。

于是苦了我们这一片在MOSS上摸索前进的人，只能吃一堑长一智了。

立此文，以祭被这样一个小问题折腾掉的2小时。

开始试验在自己的团队中采用EPM做项目管理。EPM要用好还真不容易，有很多需要探索很研究的地方。现在开始把自己日常中遇到的问题逐一记录下来，和朋友们共享。等有空了把EPM以及MOSS的一些经验整理出几个讲座，和同事以及朋友们分享一下。

好了，废话不多说，前两头刚做完一个项目的计划，发布到EPM中，结果以项目组成员登陆进去后，不能看到分配给他的任务。问题出现在哪里呢？

原来我的项目计划只是保存并发布到Project Server上去了，但是并没有发布整个项目，原来在Project Professional中保存和发布并不是将整个项目计划发布了，只有将整个项目计划发布后，项目计划的更新才会发布到项目团队的协同空间中去。

那怎么发布整个项目计划呢？

在项目中心中，点击指定项目计划，在“项目详细信息”页面中，点击“编辑项目属性”，在项目的属性页面中，点击“保存并发布”，完成之后，才算是将整个项目计划发布到团队的协同空间中去了。

Project Server为什么要这样设置呢？按照PMP的观点，项目计划一经发布后，项目经理不能随意的对项目计划进行修改。项目计划的修改必须有相关的项目干系人的审批同意之后，才能进行修改。所以项目经理可以在EPM中对要调整的项目计划进行修改，他修改的项目计划，项目组合领导是可以看到的，项目组合领导审批同意后，项目经理才可以发布自己的项目计划。

今天做SharePoint 2007 SP1的升级，得到了一个惨重的教训。不过吃一堑，长一智，从中得到的教训，以后定会受益匪浅。

今天心血来潮想把SharePoint 2007升级到Sp1，以为SharePoint的升级会和微软的其他软件升级一样容易，就不加思索的运行了升级程序。结果升级后，原来配置的站点不能打开了，只报了一个莫名奇妙的服务器错误 ，然后给了一个连接，这个连接是指向MSDN中MOSS sp1升级文档，这个时候我才知道MOSS的升级没有那么简单，需要按照升级文档好好的规划升级工作。好在我升级的不是生产系统，只是团队内部协同的系统，没有酿成大错，赶紧找解决方案。

如果Google，百度一番，试验了好多种方法，浪费了好多的时间，才终于搞定这个问题。

错误的定位在SSP失效，无法打开SSP的管理页面。我最讨厌的是MOSS一出错就给你一个莫名奇妙的未知错误，让人很丧失信心。

在网上搜索了一番，原因是现在的SharePoint_AdminContent的Schema（3.0版本）和期望的3.1 版本的Schema不一致，MOSS为了防止数据丢失，屏蔽了对COntent数据库的连接。需要升级此数据库。

升级不能完成后，可以采用这个命令来解决：

Solution: "stsadm -o upgrade -inplace -url http://{central_admin_url}/"

example., stsadm –o upgrade –inplace –url http://mossserver:17492/

总结经验教训有如下几点：

1.基于SharePoint的系统，需要部署一个生产系统一个测试系统。测试系统最好部署在虚拟化环境中，方便备份和恢复。

2.对系统的升级以及大的调整，可以先在测试环境是实施完毕，确认方案正确后，在部署到生产环境中，否则会有很大的风险。

3.对于Server级的产品，其部署和升级都有很多方面的考虑，在实施前，一定要很好的阅读，避免在部署过程中走不必要的弯路。

好久没有上来写两笔了，今天上来记录一下自己解决问题的一个方法，希望对遇到类似问题的朋友有所帮助。

先说一下问题的场景。

我再做一个基于Moss的办公协同平台，在办公环境中，避免不了要有邮件提醒方面的功能，但是非常遗憾的是，我们的应用场景中AD中除了用户账号和密码外，其他的大部分内容是空的。因为我们的客户大部分的企业应用是基于IBM的东西，邮件和OA都是Domino的，LADP是Tivoli的，AD只是简单的应用在域准入方面。公司有严格的IT管理流程，要向AD中添加信息的话，据IT的要求，必须要提交IT申请，然后审批，然后实施......，我的头都大了。

有没有方法不用AD管理员干预就能修改AD的关键信息，包括工作电子邮件呢？答案是肯定的。

我经过摸索，初步实现了自主将AD账号与电子邮件的绑定。

1. 将工作电子邮件添加到“用户配置文件和属性”中

操作如下：打开“SharePoint 3.0管理中心”-->“共享服务管理”-->“用户配置文件和属性”，

在“用户配置文件属性”部分，点击“查看用户配置文件属性”，在联系人信息的“工作电子邮件”属性中，点击编辑，进入工作电子邮件属性的编辑页面。

在编辑设置中，选中“允许用户编辑此属性的值”单选框，保存即可。

2. 登陆到MOSS 2007站点中，点击“我的站点”，在我的站点中，点击“详细信息”，在详细信息的编辑页面中，修改工作电子邮件，保存既可以将AD用户与电子邮件相关联。

写这篇Blog的时候，笔者刚经历了一次痛苦的，往复数次的报销，每次驳回，我都怀有深深的自责，我填报销单太不小心了，浪费了领导审批的宝贵时间，也浪费了公司的办公资源。但是往深里一想，这都是我的错吗？报销系统是不是也负有很大的责任？以前报销有助理帮忙，还不知道其中的蹊跷，现在轮到自己报销了，才发现这个报销是如此的令人沮丧。我曾经出差1个多月，回来报销花了近2天时间，数次被驳回，后来在助理的帮助下，报销终于通过。问问周围的同事，很少有一次报销通过的，有的人实在受不了报销过程，干脆不报销了。有人笑言，公司报销系统难用，能为公司省不少钱呢。

笑言归笑言，我觉得，这样一个令人沮丧的报销系统，是对资源的极大浪费，就我的这一个不到500元的报销而言，驳回2次，总共提交3次，前后花了我近2小时，还不算因为报销受挫对工作的影响，我想我报销的审批人至少要花费半个小时来审阅我的报销，这样算下来，对人力资源的耗费已经超过报销额了，其他的利用办公用品的耗费只算小数目。

In some of the workflow scenarios, both BizTalk Server 2006 and WF satisfactorily meet the technical requirements. For these scenarios, making the right workflow-technology choice requires matching the solution to the needs of the specific organization. For the purposes of making recommendations that apply to your particular organization, we will use the Application Platform Infrastructure Optimization (APIO) model, as shown in Figure 3.

Figure 3. Application Platform Infrastructure Optimization (APIO) model

The APIO model is a technique for profiling an organization's maturity with respect to its application infrastructure, architecture, and development practices. The goal of this model is to give organizations a road map for optimizing their agility in providing IT solutions to meet the needs of the business.

The APIO model uses the following four profiles of an organization's maturity:

• Basic—Organizations treat software as a cost. They have largely siloed applications with little integration or reuse. The applications that they do have might be on a variety of platforms. They do not have consistent standards for infrastructure or development techniques; they do not have a consistent architectural vision.
• Standardized—Organizations still treat software as a cost, but they have taken steps to improve efficiencies. They have an architectural vision and try to consider opportunities for reuse. They have started to integrate some applications, but they are mostly point-to-point integrations.
• Advanced—Organizations treat software as a business enabler. They have dedicated architects and a clear architectural vision. They have many services and achieve a high level of reuse. All core business processes are automated and monitored. They use a centralized, packaged integration platform.
• Dynamic—Organizations treat software as a strategic asset. They have a very mature SOA in vision and implementation. They have clear processes for dynamically versioning and redeploying services. The can quickly adapt to business requirements changes, and can quickly integrate with new business partners.