博客园_LeeWenjie NET Blog

【转发】谈论 SharePoint 2010中的沙盒解决方案（Sandboxed Solution）

2011-12-15T12:58:00Z

谈论 SharePoint 2010中的沙盒解决方案（Sandboxed Solution）

这么好的文章，一定要收藏，作为以后的技术资料。

期待《SharePoint 2010应用程序开发指南》。

引用

SharePoint 2010中的沙盒解决方案（Sandboxed Solution）
当程序员使用Visual Studio 2010为SharePoint 2010创建应用程序时，可以创建两种类型的解决方案，服务器场解决方案和沙盒解决方案。比如，打开Visual Studio 2010，新建一个空白SharePoint项目，你看到的第一个界面就是如下这个对话框。

服务器场解决方案（或简称为场解决方案）和SharePoint 2007一样，是一种被完全信任的解决方案。场解决方案可以包含能放到解决方案包里面的所有SharePoint组件和元素，比如应用程序页、可视化Web部件等等。在SharePoint 2010系统上安装场解决方案包，需要系统管理员在SharePoint服务器上，打开命令提示符窗口或PowerShell窗口，输入相应的命令行指令或Cmdlet，将这个场解决方案包安装到SharePoint服务器场里面。

如果你的客户对SharePoint系统有严格的管控流程，那你就惨了。你辛辛苦苦的把代码里面的Bug全部修正之后，把项目打包成更新的解决方案包，然后，身为开发人员的你必须填写N张表格，接着就只能眼巴巴的等着管理服务器场的IT人员帮你把这个更新的解决方案包部署到服务器场里面，因为只有他们才有权限能在服务器上直接操作。如果客户每次还需要你去解释，到底每次更新都做了些什么，对服务器有何影响，那你就更加会头大了。

于是SharePoint 2010引入了沙盒解决方案的概念。说到“沙盒”，嗯，这可是好东东啊。这些年整个开发平台都在围着“沙盒”转，JVM就是一个“沙盒”，CLR也是一个“沙盒”。有了“沙盒”，就能将自定义代码限制在其中，即使它一不小心crash掉，也能最小化带来的影响。

SharePoint沙盒解决方案的作用也差不多。如果开发人员将自己的SharePoint 2010项目创建为沙盒解决方案，那么SharePoint 2010会在一个特定的“沙盒”中运行沙盒解决方案，并随时监控“沙盒”里面代码的运行情况。

对于场解决方案里面所包含的代码，除了少数组件外，其他大部分组件，例如Web部件、页面、事件处理程序之类的，都是被载入到w3wp.exe进程中运行。这个是理所当然的，因为SharePoint就是一个ASP.NET Web应用嘛，所以各种自定义代码自然会被ASP.NET Runtime给载入到w3wp.exe进程中。

但是如果是沙盒解决方案，其中所包含的代码将运行在一个单独的进程中（准确的说，有好几个进程都被用于运行沙盒解决方案里面的代码），而并非w3wp.exe进程。

例如，开发人员将一个自定义Web部件打包到一个沙盒解决方案包，部署到一个网站集并激活，然后将这个Web部件给放置到某个页面上。当有用户访问这个页面时，w3wp.exe就会发现，需要运行那个Web部件中所包含的自定义代码，这时，w3wp.exe进程会联系（本地或远程服务器上的）SPUCHostService.exe进程，告诉它需要以“沙盒”模型执行一些代码。SPUCHostService.exe进程会通知SPUCWorkerProcess.exe进程载入需要运行的代码，SPUCWorkerProcess.exe进程会通过SPUCWorkerProcessProxy.exe来完成对SharePoint对象模型的调用，并执行那个Web部件中的自定义代码。这些代码执行完成之后，会将执行结果最终返回到w3wp.exe进程，w3wp.exe拿到这个自定义Web部件的执行结果，就可以继续将页面执行下去了。

要想SharePoint 2010服务器场能执行沙盒解决方案，就需要在至少一台服务器上启动“Microsoft SharePoint Foundation沙盒代码服务”。从SharePoint 2010管理中心打开“服务器上的服务”页面，就可以将这个服务在指定的物理服务器上启动或停止。

如果你的服务器场包含了n台服务器，那么你既可以在所有物理服务器上启动“Microsoft SharePoint Foundation沙盒代码服务”，也可以只选择在某几台应用服务器上启动“Microsoft SharePoint Foundation沙盒代码服务”。甚至最极端的，你可以准备一台CPU和内存都很强大的服务器，加入到服务器场中，然后专门在这台服务器上运行“Microsoft SharePoint Foundation沙盒代码服务”。这样，无论服务器场中的哪一台前端服务器需要运行沙盒解决方案中的自定义代码，这些请求都会被发送到这台强大的物理服务器。万一沙盒解决方案里面的自定义代码很烂，会严重影响运行代码的服务器的CPU或内存资源，那么也只会影响到这一台特定的服务器。

当w3wp.exe进程需要找到一个地方运行沙盒代码时，它会基于某种预先制定的策略。SharePoint 2010有两种策略可用：1、总是在得到请求的同一台服务器上运行沙盒代码；2、使用一种内置的优化规则来传递执行请求。第1种策略非常简单，w3wp.exe总是会将执行沙盒代码的请求传递给自己这台服务器上的SPUCWorkerProcess.exe进程，也就是由当前服务器负责运行沙盒代码。第2种策略类似于一种“负载平衡”机制，SharePoint会检查服务器场中哪些服务器可以用来运行沙盒代码，然后按照一个优化规则，让w3wp.exe将执行代码的请求传递到某台服务器。这个优化规则简单来说就是，如果上次是服务器A执行了某个沙盒解决方案里面的一个Web部件代码，那下次会优先考虑继续让服务器A执行同一个Web部件里面的代码。

具体选择哪个策略，可以在SharePoint 2010管理中心打开“系统设置 - 管理用户解决方案”页面，然后就能选择2个策略中的某一个了。

沙盒解决方案中包含的代码除了会在单独的进程中运行之外，它还有很多的限制。首先，SharePoint 2010使用了CAS（Code Access Security）来限制了沙盒代码能做的事情。在“Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\wss_usercode.config”文件中定义了沙盒代码的CAS策略，沙盒代码的权限被这个CAS策略限制为：

●SecurityPermission.Execution：可以执行托管代码；
●AspNetHostingPermission = Minimal：可以在ASP.NET中运行，但不能访问服务器上的任何资源；
●SharePointPermission.ObjectModel：可以使用SharePoint对象模型。

由于CAS的限制，沙盒代码能够做的事情是很有限的，比如，它不能访问服务器上的任何文件，也不能访问数据库。除了这些限制之外，对于SharePoint对象模型的调用，SharePoint系统对沙盒代码进行了进一步的限制。

虽然CAS中给予了沙盒代码“SharePointPermission.ObjectModel”权限，但沙盒代码在单独的进程中运行之前，它们都会被经过预先检查，凡是不运行调用的对象模型出现在了代码中，就会直接抛出异常，中止代码运行。禁止在沙盒代码中使用的对象模型包括：

●SPSite的构造函数
●SPSecurity类
●Microsoft.SharePoint.Navigation命名空间下的所有类
●除了SPUtility.SendEmail()和SPUtility.GetNTFullNameandEmailFromLogin()之外的所有SPUtility所提供的方法
●其他...

在SharePoint 2010 SDK中有一个列表，列出了所有允许在沙盒解决方案中被使用的SharePoint对象模型，请参考：http://msdn.microsoft.com/en-us/library/ee537860.aspx。

除了对代码的限制之外，对于能被包含在沙盒解决方案中的SharePoint元素，也有一些限制，下面这些元素都不能被包含在沙盒解决方案中：

●Web应用程序和服务器场级别的Feature
●代码工作流
●内容类型绑定
●<HideCustomAction>元素
●Custom Action group
●应用程序页
●可视化Web部件

SharePoint 2010会严格监控沙盒解决方案中的代码的运行状况。为了限制沙盒代码所占用的服务器资源，SharePoint 2010为每个网站集分配了一定的“点数”，随着沙盒代码的运行，这些“点数”会被逐渐消耗，如果一个网站集所分配的“点数”被消耗完了，那么这个网站集里面所有的沙盒解决方案将暂时不可用，直到第二天“点数”被自动重置为预设置为止。

管理员可以在SharePoint 2010管理中心的“应用程序管理 - 配置配额和锁定”页面为每个网站集指定其可用的“点数”配额。默认每个网站集每天可以消耗的“点数”配额是300。

那么SharePoint 2010是如何计算“点数”的呢？SharePoint 2010内置了一套计算规则，如果希望了解这些规则，可以打开服务器上的SharePoint 2010 Management Shell，然后输入一个Cmdlet指令：

[Microsoft.SharePoint.Administration.SPUserCodeService]::Local.ResourceMeasures | ft Name,ResourcesPerPoint,AbsoluteLimit

上图所示的就是SharePoint 2010内置的“点数”计算规则。比如，“UnhandledExceptionCount 50 3”表示：每50个未捕获异常将消耗1个“点数”，而每天如果某个解决方案包由于未捕获异常的原因消耗了3个“点数”（也就是它发生了150次异常未捕获的情况），那么这个解决方案包将被直接中止运行，即使网站集当前还有剩余“点数”。

说了沙盒解决方案这么多的限制，那么为什么开发人员要使用沙盒解决方案呢？沙盒解决方案最大的好处，就是它的部署和管理不需要服务器场管理员的参与。网站集管理员可以打开“网站设置 - 解决方案”页面，就能直接上载沙盒解决方案，并对它们进行激活、停用等操作。

由于网站集管理员就可以直接通过Web界面来部署和管理沙盒解决方案，从此网站集管理员（或开发人员）就不用每次求爷爷告奶奶的等着服务器场管理员进行解决方案部署了。当然，这是一种妥协，服务器场管理员利用SharePoint 2010系统对沙盒解决方案的种种限制、监控，来保证了沙盒解决方案能始终在一个安全的“沙盒”环境中运行，即使沙盒代码写得很糟糕，它也会能把前端服务器搞死。有了这些保证，服务器场管理员也就能放心的让网站集管理员自己开发、部署沙盒解决方案了。
（以上内容节选自正在撰写中的《SharePoint 2010应用程序开发指南》，略有修改。）

本文链接

【原创】NET4.0在SharePoint 2010 IIS下出现导演

2011-12-15T10:51:00Z

SharePoint 2010 虚拟目录是运行在NET2.0下，当部署程序为NET4.0时，会出现以下问题，目前尚未解决，暂时修改为NET3.5.

1、NET4.0在SharePoint 2010 IIS下出现导演

----------------------------------------------------------------

未能加载文件或程序集“XXXXXX”或它的某一个依赖项。生成此程序集的运行时比当前加载的运行时新，无法加载此程序集。

说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。

异常详细信息: System.BadImageFormatException: 未能加载文件或程序集“SpRibbon2”或它的某一个依赖项。生成此程序集的运行时比当前加载的运行时新，无法加载此程序集。

源错误:

执行当前 Web 请求期间生成了未处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。

-----------------------------

2、主要原因是引用的项目 .net 版本与启动的框架不同

我的电脑->右键管理->internet信息服务->默认网站->右键属性->ASP.NET->> 更改相应的asp.net版本即可

3、修改后会提示WebConfig中某些项重复引用，

4、去除后，提示 “XXXXX”用户没有“C:\Windows\Microsoft.NET\Framework64\v4.0.30319”目录的写权限。

通过aspnet_regiis -i 重新安装后问题照样存在，

望碰到类似问题的朋友提供帮助。

本文链接

C#实现多语言

2011-12-13T08:38:00Z

1、要在项目稳定以后，再做多语言本地化。

2、做语言主要注意一下几点

2.1控件（包括窗体）的多语言支持，可以在vs2008的命令提示中输入winres。采用可视化的操作界面进行设置

窗体需要设置LocalLizable = true

并选择Language

2.2变量多语言：

(1)代码中一定不要使用硬编码。

(2)使用此编码方式：string msg = Properties.Resources.InfoMsg。InfoMsg是通过Resources.resx设置。

因此所有的需要多语言处理的都要用变量的方式在Resources.resx进行设置

(3)在程序完成后，复制Resources.resx文件。将其命名为Resources.en-GB.resx。

3、在程序出口处，加入以下语句

System.Globalization.CultureInfo UICulture = new System.Globalization.CultureInfo("en-GB");

Thread.CurrentThread.CurrentUICulture = UICulture;

通过以上步骤即可完成程序多语言

注意：多语言处理后，程序bin目录下就会出现相应的多语言的文件夹

本文链接

【转载】互联网产品开发中的“快”字诀

2011-12-05T03:29:00Z

探索并推行适合腾讯的敏捷研发及项目管理，从产品、运营、技术、管理四个方面，诠释了腾讯互联网产品研发中贯彻的价值观——“快”。

当今互联网的发展，已不是大鱼吃小鱼的时代，而是快鱼吃慢鱼的时代。互联网产品的制胜原则就是一个字——“快”。在各种形态的产品研发中，我们始终贯彻如一的价值观之一就是“快”，我们应该如何来理解和诠释“快”？又会从哪些方面来执行贯彻这个原则呢？

快速迭代，快做快发

互联网产品不同于传统软件开发，我们面对的是上亿用户这样一个庞大的使用群体，他们是谁，有什么喜好，有何种习惯，会怎样使用我们的产品，是否喜欢我们的产品……

图1 QQ农牧场的“极速模型”

这些情况我们并不能准确地知道。因此，互联网产品的需求，并不能通过几个月的用户调研、市场调查、产品规划就能弄清楚，何况互联网的用户群体本身也处于飞速的动态发展之中。

那么，这种情况下如何发展我们的产品？如何对各种可能的产品特性做选择？用户将是最好的指南针，迅速让产品去感应用户需求，不断地升级进化，推陈出新，才是保持领先的唯一方式。要不断地倾听用户的反馈，不断地调整修改，然后决定你后面的方向。

所以，“快速迭代”是我们对产品的基本要求，能否做得足够快已成为衡量一款产品研发是否成熟的标准之一。以“QQ农牧场”为例，目前平均每天都会有至少一个版本发布，甚至更多，之所以能做到如此高的产品发布节奏，是由于我们一直坚持在做两件事情。

以稳定迭代，小步快跑

首先，QQ农牧场采用了一种有特色的敏捷迭代开发模式，我们称之为“极速模型”。

QQ农牧场的研发团队，由多个角色组成，包括：项目经理、产品、UE设计、前台开发、后台开发、测试、运维。以一周为一个固定的迭代开发周期，这一周时间包括了团队一次完整的各个角色的研发协作过程：迭代前有特性规划、迭代后有回顾，其中迭代过程也会包括迭代规划、开发、测试、发布等过程。但与Scrum敏捷迭代最大的不同是：并非在迭代结束时进行交付，而是能够在一次迭代中完成多次交付和发布过程。

此种方式看似简单，但其实对团队的综合研发能力是一个巨大的挑战。其中主要挑战来自以下几个方面。

特性需要能裂解成很细小的可交付的子特性，通常不超过两天的开发工作量。
迭代前，特性规划、沟通确认、界面交互及视觉设计这些工作均需提前安排完成。
迭代计划及评估过程，还必须考虑到特性/子特性之间的耦合关系以及开发人力的耦合关系，合理地作出计划安排，保证开发过程的顺利进行，降低风险。
要求团队成员工作咬合能力高，自运转能力高，需要长期默契配合。前台开发、后台开发、测试人员都能够高效率沟通，顺畅协作。

以特性为中心，随做随发

其次，我们产品研发的所有活动，都是以特性为中心开展的。一种比较通常的方式是规划一批特性，然后经过一个开发阶段进入测试，集中测试回归后完成发布。但在“QQ农牧场”，从特性规划、计划、开发、测试、发布都是以特性为单位来驱动的。也就是说当完成了一个特性的开发后，即刻转入测试、完成测试后即刻发布。在一个迭代周期内，会有很多不同的特性独立并行于从开发到发布的过程。

这还必须依赖于产品技术架构、测试自动化、运维发布自动化能力做支撑。但是“以特性为中心、随做随发”的核心思想，是产品、技术、项目管理、运维的指导原则，它是让产品的整个研发配套能力建设围绕这个中心来持续开展的基础。

反馈及时，响应快速

做到产品的快速发布只是第一步，其根本目的就是让用户尽快用到新功能，尽快得到用户反馈信息，以便及时地对产品开发做调整。所以，一个产品团队能否快速获取用户反馈、是否真正重视反馈并及时作出响应非常重要。经历了12年互联网的摸爬滚打，我们非常重视来自用户的反馈意见，并不断改进产品，积累了丰富的交付经验。

建设用户反馈渠道

首先，要解决如何搜集用户反馈的问题，满足不同用户习惯，提供多种方式的反馈渠道，让反馈及时得到。用户可以通过不同的渠道对使用的产品进行问题反馈，提出意见和建议。

重视反馈，快速响应

用户反馈、意见和建议就像一座矿山，为产品的发展提供了宝藏，但产品团队是否真正认识到它们的价值，是否能够快速地挖掘这些宝藏，却并不是一件容易的事情。
以QQMail为例，为了快速响应来自用户的反馈，在腾讯流传着一个1000/100/10的故事。

每人每月必须回复1000条论坛用户帖子。

每人每月必须查阅100篇与QQMail相关的网络评论文章。

每人每月必须处理10个用户反馈意见。

注重数据运营，有数据才有真相

无论事前经过多么细致的调研、多么缜密的规划，对于产品经理来说，一个新特性的发布，仍然是一个提心吊胆的经历：特性被用户的接受程度如何，用户将如何使用，新特性给产品带来了怎样的拉动或抑制，哪些特性可能存在交互、易用性、稳定性等问题。要想回答这些问题都很困难。

图2 连续运营数据分析示例

通过运营数据的分析，我们能够在短时间内获得对某个产品特性的准确评价，进而快速地指导产品下一步的发展。图2是一个产品93天内用户注册成功率的连续运营数据的例子。

从图2可以看出，7月12日前注册成功率稳定维持在20%~30%之间。7月12日对注册页面交互流程进行了优化并对外发布，之后两周的数据观察表明新的交互设计起到了预期的作用，注册成功率提升到了40%~60%，即使在7月17日、24日两天有定向向某省所有上线QQ用户发布消息时，其注册成功率也在40%左右浮动两个百分点。通过运营数据分析，能够快速地判断特性目标是否达到，进而指导下一步的行动。

快需要创新、需要实力

我们希望产品迭代得更快，但有了这个理念就一定能够快起来吗？快不只是一种产品理念，更是一种技术实力，遵循着这个核心价值观，需要技术上的创新思维，让技术能力来支撑我们的“快”。

以QQ宠物为例，通过技术架构创新成功地提升了客户端产品的发布速度和更新频率。如果采用传统客户端方式的话，一次版本的全量升级需要6个月的时间，而在新架构下一次全量升级仅需1天。架构从以下几方面提升了快的能力。

客户端Web化技术：像B/S系统一样的开发方式和发布周期

有人会问：客户端的产品发布能快得起来吗？我们能做到让客户端像Web一样敏捷吗？答案是肯定的，我们的客户端微内核懒加载架构，将客户端Web化技术做到了像Web一样开发客户端产品。

图3 QQ宠物的技术架构

整个架构由客户端的微内核、插件版本控制服务器和资源下载服务器构成，如图3所示。

微内核简要介绍如下。

整个客户端改造成为一个微内核插件平台，只有一个插件加载器、插件版本控制组件、资源下载组件。

插件加载器，负责加载插件。
插件版本控制组件，负责询问版本服务器获取加载的版本。
资源下载组件，负责下载插件资源。

客户端的简要启动运行流程如下。

获取版本：内核启动后，询问版本控制服务器，获取需要加载的版本。
下载相应版本的XML配置。
加载器解析XML配置。
开始第一个插件加载逻辑。
下载第一个插件的资源。
加载第一个插件。
继续加载子节点插件。
微内核懒加载架构与Web架构的比较如表1所示。

同时，通过微内核懒加载架构还能做到特性即插即用，使产品灵活稳定。组件之间被强行解耦，大大降低了依赖性在联调、测试、系统集成方面带来的工作难度。由于每个组件都可以被独立下载，在客户端加载运行，这也就意味着发布风险的降低、效率的提升。

面向特性的竖向架构：以特性为开发粒度，提升开发效率

传统的产品技术架构多为横向的分层结构，而每一层又习惯于分配给不同的人来负责。这直接带来的一个问题是，我们以特性为粒度进行开发、联调、测试时会因为人员耦合、层耦合带来复杂性、引入风险。

图4 传统的横向分层产品技术架构

举个例子，比如开发一个login页面登录功能，可能需要Web前台工程师开发页面、Web后台工程师开发CGI、Server后台工程开发用户鉴权接口、数据库工程师做数据库表结构开发。那么这样一个简单的login功能，在联调、测试、发布方面就会牵扯很多的人力协作，而又因为每一层都需要改动代码，可能对这一层的其他功能代码造成影响。试问这样的方式能快得起来吗？

QQ宠物的新架构则以特性为中心，采用竖向的架构来解决这个问题，每个特性一个组件，一个人负责开发，每个组件必须包括UI、逻辑、协议的代码实现。

这样的方式，使得面向特性的开发模式得以强制化，从而提升了效率，加快了节奏。

快需要手段
想快容易——做快难。在产品研发过程上，除了产品、运营、技术上的能力，我们还需要有必要的手段保证整个研发快起来。

图5 竖向产品技术架构

Scrum敏捷开发：发扬光大

我们早在2005年就引入了敏捷开发，目前已经将Scrum结合我们自身的产品、文化、团队特点形成了自己的敏捷研发管理框架。经过自下而上的发展和腾讯人积极的探索和沉淀，逐步形成了经典迭代、极速、大象、运营这四个比较有特色的敏捷研发管理模式。而在敏捷的推广、实施方面，也已经有了一套以运营为理念的推广模式，把敏捷当作产品来运营，形成了“管理”、“工程”两条线，在多个维度推行敏捷。

CI：持续集成，快速体验

CI在产品开发、测试阶段提升自动化效率方面非常有效。目前我们CI的发展水平还参差不齐，但从起初的自动编译已逐步加入了静态代码检测、单元测试、自动化部署等更多内容，开始为更多的研发团队所青睐。

图6 腾讯的Scrum敏捷开发

作为加快产品发布的能力，CI在以下几个方面作用明显。

自动编译输出报告，维护代码可运行，及时暴露风险，降低集成成本。
Dailybuild日构建系统，让产品经理、测试人员可以尽早进行体验和测试。
作为一个自动化系统，利用静态代码检查、单元测试报告等手段为团队提供报告，促进编码质量不断得到重视，降低缺陷解决成本、缩短解决时间。

灰度发布：提升发布的频率，降低发布风险

在互联网行业，灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能，让他们先来体验新功能、新特性。通过用户反馈、数据运营的手段及早获得反馈，及时改进。以此方式，既可以降低发布风险，也可以提升发布频率，加快发布节奏。

总结

快是一种追求、一种习惯，更是一种能力，这种能力需要产品、技术、运营、研发管理多方面的支撑才能够快得起来。这样的快，就像是中国的高铁，在高速的行驶中还必须让你感到安全、舒适、服务、便利。

本文链接

【转载】SHAREPOINT TimeJob定时器开发

2011-11-30T09:05:00Z

SHAREPOINT定时器开发
Technorati 标签: TimeJob,定时器,sharepoint,moss
SHAREPOINT定时器开发其实比较简单，只是资料相对较少，我认为开发者只要参考这三篇文档既可。
第一篇：中文的资料，可以大致熟悉下思路和方法，但是其中的一些内容可能不是最新的了
http://www.cnblogs.com/zhalin/archive/2008/03/07/1094385.html
第二篇：AC最新写的HOW TO文章，非常详尽
http://msdn.microsoft.com/en-us/library/cc406686.aspx#WSSCustomTimerJobs_Conclusion
第三篇：第二篇的代码下载
http://code.msdn.microsoft.com/SharePointWarmupJob/Release/ProjectReleases.aspx?ReleaseId=1117
下面重新再总结下定时器的开发、部署与调试方法：
1 定时器开发
1）框架就照搬上面的源代码，要用VS2008开发
2）重新引用Microsoft.SharePoint.ApplicationPages.Administration 位置在：C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG\ADMINBIN\Microsoft.SharePoint.ApplicationPages.Administration.dll
3）在Execute方法中编写自定义代码
4）如果需要获取外部的配置信息，需要写一个OwsTimer.exe.config ，放到C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN 中
OwsTimer.exe.config文件实例：
<configuration>
<appSettings>
<add key="CBSS" value="server=;database=;user id=;password=" />
</appSettings>
</configuration>
5）编译后，自动会生成WSP
2 部署
1）用VS命令行方式注册MSDN.SharePoint.Samples.SharePointWarmupJob.dll到GAC
cls
d:
cd D:\mossproject\test\SharePointWarmupJob.Source\SharePointWarmupJob
"d:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" -uf MSDN.SharePoint.Samples.SharePointWarmupJob
"d:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" -if bin\Debug\MSDN.SharePoint.Samples.SharePointWarmupJob.dll
iisreset
2）部署WarmUpJobManager.aspx
原来定时器需要另外一个SPFeatureReceiver类，因为我们需要一个Feature来把我们的Timer部署到服务器上去，通过Feature Activated/deactivated来触发/关闭这个TimerJob，TIMEJOB的间隔时间也在这里设置。
现在有了WarmUpJobManager.aspx就无需这么麻烦了。WarmUpJobManager.aspx在源代码中已经包含了，需要把TEMPLATE下的ADMIN文件夹整个拷贝到C:\Program Files\Common Files\Microsoft Shared\web server extensions\12中
在安装完solution 后就可以在应用程序管理中看到
3）安装solution
pushd %programfiles%\common files\microsoft shared\web server extensions\12\bin
stsadm -o addsolution -filename D:\mossproject\test\SharePointWarmupJob.Source\SharePointWarmupJob\wsp\Debug\SharePointWarmupJob.wsp
stsadm -o deploysolution -name SharePointWarmupJob.wsp -local -force –allowGacDeployment
4）触发/关闭这个TimerJob
5）重启TIMEJOB
net stop SPTimerV3
net start SPTimerV3
3 调试
1）确保代码是以DEBUG方式编译
2）Execute方法中编写的自定义代码头尾要加上
#if (DEBUG)

GetOwsTimerTask();
#endif
3）每次都必需按照以下顺序操作才能正常调试
把Assembly DLL放到 GAC
命令行：iisreset
在WarmUpJobManager.aspx中Deactivate feature, 然后activate feature.
命令行：net stop SPTimerV3
命令行：net start SPTimerV3
Visual Studio: Attach to process: OWSTIMER.EXE
完。
本文链接

【转载】Web开发人员的6种赚钱之道

2011-11-30T06:39:00Z

Web开发人员的6种赚钱之道
2011-08-15 10:27 | 1988次阅读 | 来源：伯乐在线【已有1条评论】发表评论
关键词：Web,开发人员 | 作者：蒋少雄 | 收藏这篇资讯
你是web开发人员吗？还是这个行业的新人？你想赚点外快吗？或者去挣赖以生存的钱？上面这些问题中，只要你对任意一条做出了肯定的回答（否定全部的问题也很难），那这篇文章就会对你有所帮助。
接下来，我会介绍到大部分可能通过web开发技能从网上赚钱的方法。我知道应该还有其他途径，但是在大多数情况下都会是下述的几个类别。那么，让我们开始列出它们。
0．当一名自由职业者
这个是最显而易见的。如果你会制作网站、编写脚本、设计网页或是模板，你就可以向他人提供你的服务。如果你准备为你的客户辛勤工作，并为你所付出的时间获取酬劳，这也许是一个赚钱的好途径。你拿到的活越多，挣的钱就越多。关于自由职业者还有更多可写的，但是那些都是题外话了。
问题：你得去寻找需要你服务的人群。
可能的解决方式：有很多可以找工作的网站。其中最大最出名的3家是：Elance、Freelancer和ODesk。雇主在这些网站上贴出面向自由职业者的工作，你可以“竞拍”这些工作（就像在ebay上竞拍一样）。
限制：唯一的限制可能就是你的时间。基本上你的报酬取决于你做的工作。经常是以小时计算。你干的越多——挣得就越多。但是有朝一日当你无法再承担再多的工作的话…
1. 发布免费脚本、模板（或是其他任何免费的东西）
开始的时候听上去有些蠢，提供免费的东西挣钱？怎么挣？
当你发布了免费的东西，你会有一些收获。首先可能会有捐赠。如果人们喜欢你给他们的那些免费的东西，他们会想返还给你一些，对你来说，最好的就是钱了。所以请不要忘记索要并布置一个按钮，以便任何做出决定的人都能轻而易举的捐赠。
另外，很多人也许会想让你定制或把你的脚本、模板安插在他们的网站上。你将是他们咨询此事的第一人，因为他们知道你很了解你的产品！
而这还不是全部！你会因为给出免费品而得到特殊福利。如果你有网站的话，那你将会得到更多浏览量。如果你获得了更多的浏览量，你就可以轻松的通过下面这两条赚钱（“联盟计划、点击付费、卖广告”和“卖你自己的产品”）。
问题：一般来说，如果你的免费产品不是特别特别广为人知的话，你将无法挣得赖以生存的钱。
可能的解决方式：同时应用下述两点（“联盟计划、点击付费、卖广告”和“卖你自己的产品”）
限制：俗话说，天空才是界限。你可以制造并发布更多免费产品，人们就不止会因为新产品而回访，你还会从搜索引擎在你的旧产品上获得大量点击。
编注：Code Canyon网站是全球数一数二的代码交易平台，有72多万的会员，有很多优秀的开发人员在这里出售他们的代码。如果你已是脚本代码巧匠，不妨把你的代码发布上去出售，这不失为一种赚钱之道，尤其是在工资涨不过物价的环境。
2. 联盟计划、卖广告
线上广告真的能养活你。但是对于所有这些项目，你都需要一个地方去放置你的广告或者链接代码。所以你需要建一个自己的网站并得到一些点击量。如上述所言，最好的方法就是提供来访者一些免费的产品。可以是一些脚本、模板、剪贴画或是有用的信息。另一种方法就是从SEO（搜索引擎优化）下手或买一些访问量。当你拥有来访者后，你就要放置广告并开始挣联盟佣金，或者卖各种广告。
问题：这个听上去很容易。但是你的新网站将会非常难以取得访问量，找一个转换率很好的联盟计划甚至更难。
可能的解决方式：努力工作。阅读在这个行业成功的人们的博客，向他们学习。
限制：再提一次，天空才是界限。你的网站越来越成功，你就能赚更多的钱。
3. 卖你自己的产品
卖你自己的产品和从属项目营销类似，但还是也有很大的区别。
你将获得销售额的100%。
你必须自己制造产品（不管是脚本、模板还是其他任何东西）。
你还要考虑到支付手段，客户支持等等。
一般来说，比起加入营销项目，卖自己的产品可以让你学到更多（你必须去制作人们想买的东西！）。这也需要更大量的工作。但是也许真的很划算。
问题：你要为你的产品负责，支持客户。为了运行你的产品，你需要投入大量的时间和（或）金钱。
可能的解决方式：把你的产品开发外包给一些自由职业者。有个好地方可以找到这些人，那就是（对的…我再说一次…）：Elance、Freelancer和ODesk。然而你开始的时候仍需要资金。
限制：如果你有了优秀的产品，你就要去宣传它然后…除非广告预算不足，否则只有天空才是你的界限。
4. 出售网站
这个也许能赚大钱，卖网站大致有两种方法：
制作网站并以现金售出
购买网站→稍作加工→再以更高价格现金卖出
也许你不信，但是的确有效。人们在寻找一些万事就绪的网站为他们赚钱，这是一个巨大的市场。门户网站Flippa是一个很好的起始点。这个网站就像ebay一样，只不过是买卖网站。
问题：不是所有的网站都畅销。你得去找到利基（niche），制作出优秀的网站并寻找客户。此外，当你购买网站的时候，你很容易上卖家的当。你一定要清楚你到底在做什么…
可能的解决方式：在你开始之前去浏览Flippa上的表单，学习一下你的货品和销售方式到底是什么。去了解一下如何检查你购买网站的卖方。
限制：在开始业务的时候你需要投入一些资金。你会需要一些像域名（我推荐namecheap上的便宜域名）和托管（Site5上提供廉价可靠的托管）。你也可能不确定是否能捞回本钱。
5. 找一份全职工作
如果你认为上述几条都不是挣钱的好主意的话，你也许仍然需要去找（或者继续）早八点晚四点的全职工作。有些人认为这是挣活命钱的最好方式…虽然我不这样认为。
问题：你将没有时间照顾你的家庭，会面对疯狂的老板，没有任何形式的自由。
可能的解决方式：辞去你的工作并发展你自己的线上业务（如果你工作之余还有时间的话，也可以在你的闲暇时间开展业务）。
限制：不管你从老板那里得到了多少工作学到了多少知识，还是挣一样的工资…
结束语
网络上挣钱的方式多种多样，发挥你的Web开发技能的方法同样如此。我认为我涵盖了其中的大部分，并且希望提供给你了一些新点子。很多独立的开发人员并不拘泥于这其中的单一途径，因为这些方法都是多多少少相互关联的。那么，你通过网络挣钱的方法是什么呢，欢迎留言介绍你的方法。

本文链接

【原创】企业级工作流管理系统评价依据或标准

2011-11-28T08:59:00Z

【原创】企业级工作流平台评价

标签：工作流平台特性构架 soa

在国内工作流管理系统优劣参差不齐的情况下，企业如何寻找到真正不错的工作流软件呢？这的确让不少公司伤神，在此，结合近期对工作流的学习和研究，说说一款优秀的工作流平台应该具备那些基本特点，仅供参考，如有偏颇请多多包涵。

一个完整的工作流管理系统通常由工作流引擎、工作流设计器、流程操作、工作流客户端程序、流程监控、表单设计器、与表单的集成以及与应用程序的集成八个部分组成。
1. 工作流引擎
工作流引擎作为工作流管理系统的核心部分，主要提供了对于工作流定义的解析以及流程流转的支持。工作流定义文件描述了业务的交互逻辑，工作流引擎通过解析此工作流定义文件按照业务的交互逻辑进行业务的流转，工作流引擎通常通过参考某种模型来进行设计，通过调度算法来进行流程的流转(流程的启动、终止、挂起、恢复等)，通过各种环节调度算法(SPLIT、AND、OR等)来实现对于环节的流转(环节的合并、分叉、选择、条件性的选择等)。
2. 工作流设计器
工作流设计器为可视化的流程设计工具，用户通过拖放等方式来绘制流程，并通过对于环节的配置来实现环节操作、环节表单、环节参与者的配置。工作流设计器为用户以及开发商提供了快速绘制、修改流程的方式，

工作流设计器的好坏决定到工作流管理系统的易用性。
3. 流程操作
流程操作指所支持的对于流程环节的操作，如启动流程、终止流程、挂起流程、直流、分流(单人办理)、并流(多人同时办理)、联审等，象这些流程操作都是可直接基于引擎所提供的环节调度算法来直接支持的，而在实际的需求中，通常需要自由的对于流程进行干涉，如取回、回退、跳转、追加、传阅、传阅办理等，而这些流程操作对于工作流引擎来说是不合理的，因此必须单独的去实现。
流程操作支持的好坏直接决定到一个工作流管理系统的实用性。
4. 工作流客户端程序
工作流客户端程序为工作流系统的表现形式，通常使用Web方式进行展现，通过提供待办列表、已办列表、执行流程操作、查看流程历史信息等来展现工作流系统的功能。
5. 流程监控
流程监控通过提供图形化的方式来对流程执行过程进行监控，包括流程运转状况，每个环节所耗费的时间等等，而通过这些可相应的进行流程的优化，以提高工作效率。
6. 表单设计器
表单设计器为可视化的表单设计工具，用户通过拖放的方式来绘制业务所需的表单，并可相应的进行表单数据的绑定。
表单设计器为客户以及开发商提供了快速修改表单的方法，表单设计器的易用与否以及功能的完善与否影响到工作流管理系统的易用性。
7. 与表单的集成
通常业务流转需要表单来表达实际的业务，因此需要与表单进行集成来实现业务意义，与表单的集成通常包括表单数据的自动获取、存储、修改，表单域的权限控制、流程相关数据的维护以及流程环节表单的绑定。
与表单的集成的好坏影响到工作流管理系统是否能提高开发效率。
8. 与应用程序的集成

通过与应用程序的集成来完善工作流管理系统的业务意义，主要涉及到的是与权限系统以及组织机构的集成。流程环节需要相应的绑定不同的执行角色，而流程操作通常需要与权限系统、组织机构进行关联。

1、

SOA技术构架，我认为在SOA标准横行的今天，拥有先进的SOA技术构架是必要的，并充分利用了先进的SOA技术标准。因此良好的技术构架保证了系统能够支持企业级应用，并能够进行长期稳定的功能扩展。反之，如果采用私有的技术构架，则整个系统的稳定性、可靠性、并发服务能力可能受到工作流系统的限制。

2、支持企业级应用的，比如看它是否支持集群，是否具有良好的错误处理机制，是否支持事务管理，是否备很好的系统管理工具等。另外还要看在它承受大量用户的并发访问和大量流程的并发运行，是否保证系统具有稳定的响应等。

3、有良好的可扩展能力也是不可或缺的。例如支持模板、活动等的扩展方式，这样使开发商可以对该系统进行扩展，也更加符合行业特点。

4、有良好的应用集成能力，这样才方便调用各种应用，如调用WebService、DLL等。还可以通过应用插件和第三方中间件平台和更多的应用系统进行集成。这对作为应用集成系统特别重要。在进行大型应用系统的集成时，可以采用工作流管理平台作为业务流程集成工具，提供大范围的业务流程支持。

5、平台应该拥有独立性，使之能够支持各种应用服务器，支持Oracle、SQL Server等各种常用数据库，支持包括Windows、Linux、各种Unix系统的主流操作系统等等，方便应用系统的开发商可以自由选择系统平台。

6、很好的开放性和嵌入能力，这也作为一个优秀工作流平台不可缺少的。

7、很好的稳定性，稳定性是平台产品的最重要的品质之一。工作流管理平台的稳定性由其良好的构架设计作保证。

8、具备全面的流程流转功能和与业务的内在支持，如分支，合并，集合等等。

由于水平有限，在对照网上各工作流的介绍而写的。所以写的不对的地方请多指教、补充。

本文链接

【原创】SharePoint2010 ASPX页面设置自定义功能区（Ribbon）

2011-11-18T02:34:00Z

SharePoint2010 ASPX页面设置自定义功能区（Ribbon）

SharePoint2010的页面风格发生了很大的改变，其页面风格类似于Office的视图，这种视图被称为功能区（Ribbon）视图。

一、服务器功能区的体系结构

SharePoint 2010

Microsoft SharePoint Foundation 2010 中的服务器功能区可创建一致的用户界面来处理 SharePoint 对象。您可以使用服务器功能区 XML 和简单的 ECMAScript（JavaScript、JScript）以声明方式扩展功能区，也可以针对更高级的情形使用功能区 XML 和页面组件。

服务器功能区中的基本对象

功能区中的首要元素就是选项卡。选项卡显示在 SharePoint 网站页面的顶部。每个选项卡都包含多个组。这些组又包含多组控件。每个组可以包含多个控件，并具有一个标签来标识该组。组内的控件包括按钮、下拉菜单、复选框、组合框、拆分按钮和库。其中每个控件都绑定到一个唯一的命令。

服务器功能区是使用服务器功能区 XML 在功能清单文件或用户自定义操作中定义的。功能区 XML 用于定义各个选项卡、组和控件。Tab 元素包含一个Groups 元素。每个 Groups 元素又有多个 Group 元素。Group 元素内是一个 Controls 元素，该元素又包含多种类型的控件。服务器功能区中的控件部分列出了可用的控件类型。有关功能区 XML 的详细说明，请参阅服务器功能区 XML。

服务器功能区通信

功能区使用多个对象与页面的其余部分进行交互。它必须知道启用了哪些控件、控件的状态以及何时进行刷新。服务器功能区使用CommandDispatcher、PageManager、PageComponent 等对象进行通信。其中每个对象在与功能区的交互中都扮演着重要角色。

PageManager 可初始化所有控件并向功能区注册 PageComponent 对象。PageManager 的一个实例位于该页面上。

CommandDispatcher 负责处理所有 PageComponent 对象以及这些对象可以处理的命令。在页面上收到命令后，CommandDispatcher 会接收该命令并将其传递给正确的 PageComponent。

PageComponent 在 ECMAScript（JavaScript、JScript）中创建并处理由 CommandDispatcher 传递的命令。将 PageComponent 添加到页面中后，您可以使用 JavaScript 创建 PageComponent 的实例，并将其注册到 PageManager 中。然后，PageComponent 即可响应您在功能区 XML 中定义的命令。

服务器功能区中的控件

服务器功能区包含许多类型的控件。其中包括复选框、按钮和组合框等简单控件，还包括拆分按钮或飞出位置等更高级的控件。

二、 SharePoint 2010 Server 功能区组件

图中的标注号指向以下特定组件：

选项卡
组
控件
上下文选项卡组

三、使用页面组件实现服务器功能区命令

除了使用命令 UI 处理程序外，还可以使用页面组件。页面组件是一个在外部脚本库 (.js) 文件中定义的 JavaScript 对象。该对象实现了几个属性和方法，它们将告知服务器功能区命令基础结构如何初始化该对象、该对象可处理哪些命令以及某个特定命令是否可用，并可在页面组件接收焦点或失去焦点时做出响应。

必须将此脚本文件添加到显示功能区自定义项的同一页面中。可通过多种方法来实现这一点。第一种方法是，使用 SharePoint 2010 中的新 <CustomAction ScriptSrc="" /> 功能，根据功能的范围将库添加到网站、网站集、Web 应用程序或服务器场中的所有页面。另一种方法是，从自定义应用程序或网站页面 (.aspx)、自定义用户控件 (.ascx) 或自定义服务器控件内的托管代码添加脚本。以下代码示例将向 Web 部件内的页面添加页面组件文件。

本例在自定义ASPX页面中实现：

ASPX

注意：1、继承母版：DynamicMasterPageFile="~masterurl/default.master"

2、如果没有继承母版页，需自定义Sharepoint Ribbon控件

1 <%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>
2 <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
3 <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
4 <%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
5 <%@ Import Namespace="Microsoft.SharePoint" %>
6 <%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
7 <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ApplicationPage1.aspx.cs" Inherits="SpRibbon2.ApplicationPage1" DynamicMasterPageFile="~masterurl/default.master" %>
8
9 <asp:Content ID="PageHead" ContentPlaceHolderID="PlaceHolderAdditionalPageHead" runat="server">
10
11 </asp:Content>
12
13
14 <asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">
15  asdhkasjhfsadf sdfsdalfjaklsjdfklasjdfklasjdfo;
16     <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
17 </asp:Content>
18
19 <asp:Content ID="PageTitle" ContentPlaceHolderID="PlaceHolderPageTitle" runat="server">
20 应用程序页sdfsaf
21 </asp:Content>
22
23 <asp:Content ID="PageTitleInTitleArea" ContentPlaceHolderID="PlaceHolderPageTitleInTitleArea" runat="server" >
24 我的应用程序页asdfasd asdf
25 </asp:Content>
26
27
28
29 <asp:Content ContentPlaceHolderID="PlaceHolderPageImage" runat="server">
30 </asp:Content>
31
32 <asp:Content  runat="server" ContentPlaceHolderID="PlaceHolderPageDescription">
33 </asp:Content>
34
35
36 <asp:Content ContentPlaceHolderID="PlaceHolderLeftNavBar" runat="server">
37  xvzxcv asdfasdf asdfa dfasfdsadfsadfsafas

38 </asp:Content>

sharePoint Ribbon控件代码（本例未使用，可参考MSDN）

1、继承：LayoutsPageBase

2、重写：

override void OnPreRender(EventArgs e)

1 using System;

2 using System.ComponentModel;
3 using System.Web;
4 using System.Web.UI;
5 using System.Web.UI.WebControls;
6 using System.Web.UI.WebControls.WebParts;
7 using Microsoft.SharePoint;
8 using Microsoft.SharePoint.WebControls;
9
10 namespace SpRibbon2
11 {
12     public partial class ApplicationPage1 : LayoutsPageBase
13     {
14         protected void Page_Load(object sender, EventArgs e)
15         {
16         }
17
18         protected override void  OnPreRender(EventArgs e)
19         {
20             try
21             {
22                 SPRibbon ribbon = SPRibbon.GetCurrent(this);
23                 if (ribbon != null)
24                 {
25                     ScriptLink.RegisterScriptAfterUI(this, "SP.Ribbon.js", false, true);
26                     ribbon.CommandUIVisible = true;
27                     ribbon.MakeTabAvailable("Ribbon.Read");
28                     //加载及激活自定义上下文Tab页。
29                     ribbon.MakeTabAvailable("Ribbon.PropertyChangerTab");
30                     ribbon.MakeContextualGroupInitiallyVisible("Ribbon.WebPartContextualTabGroup", string.Empty);
31                 }
32                 base.OnPreLoad(e);
33             }
34             catch (Exception ex)
35             {
36                 throw ex;
37             }
38         }
39     }
40 }

四、创建服务器功能区组件自定义项

创建一个上下文选项卡组，一个带两个组的选项卡和几个控件。详细结构可参考：Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\XML\CMDUI.XML。

feature.xml

1 <?xml version="1.0" encoding="utf-8" ?>

2 <Feature Title="SPRibbon2 Feature"
3          Scope ="Web"
4          Id="94269D73-8DF2-4515-B501-4C2111FF9DAF"
5          xmlns="http://schemas.microsoft.com/sharepoint/">
6   <ElementManifests>
7     <ElementManifest Location="element.xml"/>
8   </ElementManifests>
9 </Feature>

Element.xml

1 <?xml version="1.0" encoding="utf-8"?>
2 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
3   <CustomAction Id="WebPartContextualTabs"
4                 Location="CommandUI.Ribbon">
5     <CommandUIExtension>
6       <CommandUIDefinitions>
7         <CommandUIDefinition Location="Ribbon.ContextualTabs._children">
8           <ContextualGroup Id="Ribbon.WebPartContextualTabGroup"
9                            ContextualGroupId="WebPartContextualTab"
10                            Title="Ribbonized Web Part Tools"
11                            Sequence="150"
12                            Color="Green"
13                            Command="WebPartContextualTab.OnEnableContextualTab">
14             <Tab Id="Ribbon.PropertyChangerTab"
15                 Title="Tools"
16                 Sequence="501">
17               <Scaling Id="Ribbon.PropertyChangerTab.Scaling">
18                 <MaxSize Id="Ribbon.PropertyChangerTab.MaxSize"
19                           GroupId="Ribbon.PropertyChangerTab.PropertyGroup"
20                           Size="LargeLarge" />
21                 <MaxSize Id="Ribbon.PropertyChangerTab.MaxSize"
22                           GroupId="Ribbon.PropertyChangerTab.PostBackGroup"
23                           Size="LargeLarge" />
24               </Scaling>
25               <Groups Id="Ribbon.PropertyChangerTab.Groups">
26                 <Group Id="Ribbon.PropertyChangerTab.PropertyGroup"
27                        Title="Edit"
28                        Description="General Web Part properties."
29                        Sequence="15"
30                        Template="Ribbon.Templates.Flexible2">
31                   <Controls Id="Ribbon.PropertyChangerTab.PropertyGroup.Controls">
32                     <Button Id="Ribbon.PropertyChangerTab.PropertyGroup.GeneralDialogButton"
33                             LabelText="General Properties"
34                             TemplateAlias="o1"
35                             Sequence="15"
36                             Image16by16="/_layouts/Images/WebPartRibbonContextualTab/16x16Placeholder.png"
37                             Image32by32="/_layouts/Images/WebPartRibbonContextualTab/32x32Placeholder.png" />
38                     <Button Id="Ribbon.PropertyChangerTab.PropertyGroup.UXDialogButton"
39                             LabelText="Display Properties"
40                             TemplateAlias="o2"
41                             Sequence="17"
42                             Image16by16="/_layouts/Images/WebPartRibbonContextualTab/16x16Placeholder.png"
43                             Image32by32="/_layouts/Images/WebPartRibbonContextualTab/32x32Placeholder.png" />
44                   </Controls>
45                 </Group>
46                 <Group Id="Ribbon.PropertyChangerTab.PostBackGroup"
47                        Title="PostBack"
48                        Sequence="25"
49                        Template="Ribbon.Templates.Flexible2">
50                   <Controls Id="Ribbon.PropertyChangerTab.PropertyGroup.Controls">
51                     <Button Id="Ribbon.PropertyChangerTab.PropertyGroup.GeneralDialogButton"
52                             LabelText="Write to Web Part"
53                             Command="WebPartContextualTabs.OnPostback"
54                             TemplateAlias="o1"
55                             Sequence="15"
56                             Image16by16="/_layouts/Images/WebPartRibbonContextualTab/16x16Placeholder.png"
57                             Image32by32="/_layouts/Images/WebPartRibbonContextualTab/32x32Placeholder.png" />
58                   </Controls>
59                 </Group>
60               </Groups>
61             </Tab>
62           </ContextualGroup>
63         </CommandUIDefinition>
64       </CommandUIDefinitions>
65
66       <CommandUIHandlers>
67         <CommandUIHandler Command="WebPartContextualTab.OnEnableContextualTab"
68                           CommandAction=""
69                           EnabledScript="return true;" />
70         <CommandUIHandler Command="WebPartContextualTabs.OnPostback"
71                           CommandAction="javascript:__doPostBack('RibbonizedWebPartPostback','');" />
72       </CommandUIHandlers>
73
74     </CommandUIExtension>
75   </CustomAction>

76 </Elements>

五、部署
feature部署：拷贝feature.xml和Element.xml文件到SharePoint目录下：
xcopy ..\Features\.xml "X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\SpRibbon2\" /y
ASPX文件部署：
xcopy ..\ApplicationPage1. "X:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SpRibbon2\" /y
DLL文件部署：
xcopy SpRibbon2.dll "C:\inetpub\wwwroot\wss\VirtualDirectories\80\bin\" /y
六、Feature功能安装和激活【2011-12-15补充】
打开"Visual Studio 命令提示(2010)"工具，定位到“C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN”。
1、安装功能：
stsadm -o installfeature -name SpRibbon2 -url http://localhost:80
2、激活功能
stsadm -o activatefeature -name SpRibbon2 -url http://localhost/

七、Sharepoint测试

添加链接

更详细的操作详见microsoft MSDN
本文链接

【原创】sharepoint排错

2011-11-17T06:09:00Z

sharepoint运行出错的错误的提示，往往十分友好，几乎无法告诉我们到底哪里错。

一般需要查看运行

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

以前查看长篇的日志很痛苦。

最近发现，一般通过搜索

expection

error

这两个词，就能快速定位到错误的相关段落。

本文链接

【转载】Sharepoint开发问题归纳

2011-11-17T06:05:00Z

1、自己的webpart报错：AllowPartiallyTrustedCallersAttribute

需要在AssemblyInfo.cs中加入[assembly:AllowPartiallyTrustedCallers] (经常会忘了加)

2、用普通用户执行webpart时可能权限不够，需要提升权限
当将webpart部署到站点后，如果用的是管理员的帐户来运行，则成功；如果用一般用户，则跳转到用户无权访问的页面。通过查找资料，终于找出了问题所在：如果用户没有“管理列表”的权限，则无法更新List、View、ListItem等。给一般用户“管理列表”的权限显然是不可行的，那如何提升用户的权限呢？
在wss 3.0中提供了一种更快捷的方法，采用RunWithElevatedPrivileges ，如下：

Code
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(SPContext.Current.Site.ID))
{
using (SPWeb thisWeb = site.OpenWeb(SPContext.Current.Web.ID))
{
                        thisWeb.AllowUnsafeUpdates = true;
                        SPList list = thisWeb.Lists["任务"];
                        spView = list.DefaultView;
string query = "<Where><Eq><FieldRef Name=\"Status\"/><Value Type=\"Text\">" +      dropDownList.SelectedValue + "</Value></Eq></Where>";
                        spView.Query = query;
//一般用户没有Update()的权限，所以在这里提升用户权限
                        spView.Update();
                        thisWeb.Dispose();
                    }
                    site.Dispose();
            }
}
);

3、在webpart中取得当前登录用户

SPWeb web = SPControl.GetContextWeb(Context);
Label1.Text = web.CurrentUser.Name;

本文链接