摘要:TechReady是微软内部面向Services、DPE、TS等部门的技术会议，每年两次，这次是第5次。听了几天课，虽说很多内容有点旧，但其中还是有不少好的东东，呵呵。TechReady5的第2天，Bill Gates给了一节General Session，BillG出场的时候，集体起立鼓掌，大概是感谢他创建了如此一个伟大的公司，并为之奉献了这么多年吧，另外一个原因也是因为BillG即将退休，以后他将把主要精力放到他的慈善基金会上，以后能够在公司会议上看到他的次数肯定会越来越少了。在BillG演讲之后，安排了问答互动环节，有一个好像是印度的同事问BillG觉得微软以后面临最大的困难和挑战将会是什么。BillG的回答是：聚集足够聪明的人，想出好点子，并且在别人实现这些点子之前就抢先实现出来。关于Visual Studio 2008，听了一节Scott Gu亲自主讲的ASP.NET 2.0的课程，名人就是名人啊，听的人暴多，安排的也是大房间，Scott Gu演示的功力颇深，直接给我们show了很多的新功能，特别是IDE对JS的支持，实在是太cool了。另外还听了一节介绍.NET 3.5与VS2008的课程。在会场直接通过无线就开始往自己笔记本上拖VS2008 Beta2的安装文件，回房间就开始安装VS2008 Beta2  :)，运行速度感觉相当不错。关于SharePoint，听了不少介绍实施经验的课，很多课程都是下面听的人不断“诉苦”，呵呵。不过还是听到了不少让人兴奋的内容，包括：1、SharePoint产品组将提供一个External Storage API，允许自定义实现文档库文件存储方式。也就是说，我们将可以通过它，将文档库中的文件保存到任何地方，比如，直接保存到服务器的文件系统中。这个东东将在SP1中提供。SP1啥时候出？今年年底。透漏一个“秘密”的网址：http://support.microsoft.com/kb/938499/en-us 2、VS2008中带的SharePoint Workflow项目已经被包含在VSTO 3.0里面，它极大的简化了调试过程。基本上，调试一个SharePoint Workflow的方法就是直接按F5。 听课间隙，顺便去会场里面设置的一个可以考MCP考试的地方把SharePoint 2007的四个MCP Exam都考了：70-631,70-630,70-541,70-542。每次考试过程中都感觉只怕过不了，太多题不怎么懂了，但是每次都考过了... :)...[阅读全文]

摘要:增加了更多的内容：WSS 3.0 SDK 1.1     MOSS 2007 SDK 1.1如果你有足够的尝鲜欲望，也可以试试1.2的测试版。...[阅读全文]

摘要:Patrick写的文章基本上都属于必看，Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 Part1, Part2，感谢博客园的小熊，他已经将第一部分翻译了出来。...[阅读全文]

摘要:虽然SharePoint Server 2007使用了ASP.NET 2.0的基础页面模型，SharePoint页面基本上也是基于标准的aspx技术来构建，但SharePoint Server 2007的页面模型仍然要比普通的ASP.NET应用复杂很多。对于一个SharePoint开发人员（和设计人员），了解SharePoint的页面模型是非常非常重要的。在SharePoint 2007中，将页面分为两种：Application Page和Site Page。Application Page是指SharePoint应用程序中用到的页面。比如，当我们进入到一个SharePoint站点的站点设置中后，几乎所有的站点设置页面都是Application Page。如果我们看到地址栏中的页面路径都是类似“http://sharepointsite/_layouts/xxx.aspx”这样的格式，也就是说，页面位于“_layouts”虚拟目录中，那么这个页面就是Applicatoin Page。Application Page在物理上被存放在SharePoint Web前端服务器的“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts”目录中，不能被用户进行定制。而Site Page是指位于一个SharePoint站点中的普通页面。比如，站点的首页：“http://sharepointsite/default.aspx”，或者位于一个文档库中的页面：“http://sharepointsite/pages/xxx.aspx”，都是Site Page。Application Page实际上和一个普通的ASP.NET页面没有任何区别。开发人员如果有需要，可以自己添加新的Application Page，你既可以在“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts”目录中添加新的页面，也可以在这个目录下创建新的子目录（或虚拟目录），来放置你的Application Page。在Application Page中，开发人员可以根据自己的需求，直接添加In-line code，这些code都会直接被执行，就像一个普通的ASP.NET应用程序一样（当然，对于Code-behind的模式，Application Page也是支持的）。比如：<script runat="server">protected void Page_Load(Object sender, EventArgs e){    // 代码...}</script>对于Application Page，SharePoint 2007总是认为它们是安全的，因为，站点的管理员（非服务器管理员）和用户都没有办法直接修改Application Page，所以，SharePoint 2007会直接“执行”它们。如果你要创建自己的Application Page，尽量遵守这样的模式：1、让你的Application Page从“Microsoft.SharePoint.WebControls.LayoutsPageBase”继承下来；2、让你的Application Page使用位于Layouts目录中的“Application.master”这个Master Page；3、在Layouts目录中创建一个新的子目录（或虚拟目录）来放你的Application Page，不要和SharePoint自带的Application Page混杂在一起。Site Page比Application Page要更复杂一些。对于Site Page，我们通常根据它们是否已经被进行了定制（通过SharePoint Designer 2007），将Site Page分为Uncustomized Page和Customized Page。（在SPS2003中，使用的是Ghosted Page和Unghosted Page这两个术语。）当我们新建一个站点的时候，所有的页面都是Uncustomized Page，这些页面都是直接使用了存放在SharePoint Web前端服务器磁盘上的页面模板（位于“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE”的各个子目录中），换言之，这个新站点的页面其实是“不存在的”，它们只是一个“标记”（这也就是在SPS2003中，它们被称为Ghosted Page的原因），如果用户访问一个页面，SharePoint会自动从磁盘上找到那个真正的页面模板文件，然后将其载入到内存中，解析它，并将其编译成一个独立的dll文件（为了性能，这个dll会缓存在磁盘上以避免下次重复编译），然后载入这个dll，运行，输出。但是，如果站点设计人员用SharePoint Designer 2007打开这个SharePoint站点，然后用SharePoint Designer打开某个Site Page文件，进行某些修改，保存，SharePoint会自动将修改后的文件内容保存到站点所用的内容数据库中，它就成了一个Customized Page。从此，这个Customized Page就和磁盘上的页面模板“脱离关系”了。当用户访问这个页面时，SharePoint会自动从内容数据库中读出这个文件的内容，然后对其进行解析，运行。注意！这次，SharePoint不会再将其编译成一个独立的dll文件了，实际上，SharePoint会在内存中载入这个页面的结构，运行，然后输出，然后将它从内存中卸载以节省内存。从Uncustomized Page和Customized Page的运行模式上，我们就能看出它们的运行效率存在着不小的差别。首先，Uncustomized Page是位于磁盘上的，它的读入速度会比较快，其次，Uncustomized Page会在第一次被访问时就被编译成一个dll，避免了重复编译。比如，两个不同SharePoint站点的首页“default.aspx”如果都是Uncustomized Page，而且使用的是同一个页面模板，它们只会被编译一次。而Customized Page位于内容数据库中，读入速度比不上磁盘文件，而且它不会被编译成dll，而是只会在内存中进行解析，运行。但是，有意思的是，Customized Page的解析运行方式虽然在速度上可能要慢，但却要更节省内存一些。因为在内存中载入一个页面的结构，进行解析运行后，是可以再释放掉的，而一个dll被载入后，是不能被释放掉的。这是因为.NET不支持载入程序集后再卸载程序集，呵呵。（但.NET支持创建AppDomain后再释放掉AppDomain。）除了存放位置和运行效率上的不同，在代码安全上，Uncustomized Page和Customized Page也存在很大的区别。类似于Applicaton Page，Uncustomized Page也是被SharePoint信任的页面，位于Uncustomized Page里面的ASP.NET In-line code会被直接运行。而Customized Page由于可以被站点设计者（可能他并非是服务器管理员）通过SharePoint Designer向其中加任意的In-line code，所以，默认的安全规则根本不会允许Customized Page中的服务器端代码被运行。类似的，如果Uncustomized Page上面被放置一个服务器端控件，是没有问题的，但是，如果要向Customized Page上放一个服务器端控件（包括Web Part），那么这个控件就必须在站点的web.config中被标识为“Safe Control”（也就是增加新的“<SafeControl>”节点来标识某个控件是安全的）。虽然SharePoint对Customized Page有这些安全上的限制，但是，服务器管理员通过修改web.config文件中的安全设置，是可以更改这样的默认安全限制的。比如，如果你希望站点的“MyPages”目录下的页面，即使它们是Customized Page，也允许被包含服务器端In-line code，可以在web.config中增加这样的内容：<SharePoint>   <SafeMode......[阅读全文]