摘要:对WCF的了解还停留在2006年初看Indigo的地步。当时看了一本MS 2005年出版的《Programming Indigo》电子书，是一本非常棒的书，我只记得当时作为初学者我看第一遍的时候，对其中每个章节中的相关概念定义都能心领神会，这就说明这本书是一本非常棒、值得收藏的书。因为WCF的核心就是接口协议定义，而它做到了让初学者能迅速理解这些接口协议。 对于学习WCF，我个人理解是一定要理解WCF中的接口协议定义和规则约束！了解这些远远比你去看看Code，写写Sample来得重要许多。从某种意义上，学WCF就是学概念、学定义、学规则、学接口协议，而不是让你像学C#或ASP.NET那般追求深入实际应用，然后再去反过来体会C#/ASP.NET原理。 一晃，Indigo更名为WCF并入.net3.0概念中。天天念叨着WCF、WPF、WF，可是除了WF还顺应潮流接点轨外，WCF就停在Indigo阶段，WPF更仅仅只了解其相关的XAML知识。正好最近越忙越是精力充沛，抽空花了两三个小时翻了2007年2月刚出版的《Programming WCF Services》一书，算是在Indigo基础上重新认识了下WCF，感觉还OK，各类细节变来变去，但只要它的接口协议、概念定义没变就好办，剩下的就是从《Programming WCF Services》新书中挑几章自己兴趣的或感觉变化比较大的再细细品味下，也算完成本书的阅读工作了。 昨天我说花了一夜用HTML+Photoshop+Javascript搞了个系统原型，于是有人开始质疑我这个做法是否值得，理由是让美工或其他人搞个比自己搞既快又好。我承认自从99年接触Photoshop 3.0/4.0以来，我的美工水平一直停滞在满足图片的修修补补，让专业美工搞这个自然是快而好。但我想做一件事情，更多的应该是看做这件事情的目的。系统原型相当于建筑行业的图纸，其更多的价值在于迅速构建一个与用户沟通的管道，确保做出客户想要的东西，同时为后面的系统设计提供了基础约束。由于业务复杂，加上时间紧张，自己也弄过ps，就凑合了，最终效果也不错。  MS发布了个Windows Workflow Foundation Web Workflow Approvals Starter Kit，算是给了ASP.NET开发人员一个交待。 最近在做EPM，不过这个EPM没有用Project Server，却是完全用ASPNET + SQLServer搭建，这也是各种原因造就。不然利用 Project Server，一个小时应该可以搭建出一个简单却实用的 EPM 应用出来。恰巧上次和网友讨论过一些 MS 企业服务器产品的主要应用业务，这里也稍微整理下一些我接触过的MS服务器产品，不对的地方还请指正。 Project Server:  EPM SPS: Portal WSS: Team Work (Document Mgmt) BizTalk:  EAI Commerce Server: EBusiness Content Management Server：WCM Exchange：Mail, Message platform  LCS：IM MOSS：Portal+WCM+ECM+BI+Search+BPM...[阅读全文]

摘要:Sahil Malik 最近一连发表了10篇关于 MOSS BDC 的文章，真是让人振奋： SharePoint 2007: BDC - The Business Data Catalog SharePoint 2007: BDC - The Hello World Example SharePoint 2007: BDC - Extending the Hello World Example SharePoint 2007: BDC - Extending the "Hello World" example even further - adding specific finders SharePoint 2007: BDC - Using BDC Data in Lists SharePoint 2007: BDC - Custom Actions on your Entities SharePoint 2007: BDC - Introducing associations between entities SharePoint 2007: BDC - Enabling Search on business data SharePoint 2007: BDC - User Profiles SharePoint 2007: BDC - Writing Custom Code against the runtime object model 如果涉及到表单中托管代码(VSTA or VSTO......[阅读全文]

摘要:对于普通ASP.NET站点来说，要对该站点的URL进行访问授权控制，可以通过创建一个HttpModule来监控每个Request，如果Request Url为受控URL（即要访问该URL地址需要经过一种特定验证授权）时，则跳转到验证授权页面进行身份验证授权，完成后再返回即可正常访问Request Url。我想，这个实现并不难，网络上也可以找到诸多用HttpHandler和HttpModule来做这块处理的示例。 那么，SharePoint Portal Server 2003中，访问受控URL和普通ASP.NET站点有何不同吗？带着这个疑问，我们可以一开始也用HttpModule来做尝试。假设此时我们访问一个SharePoint 文档库的某个内容，其URL地址应该是 http://localhost/DocLib1/Test.doc，而在我们的受控URL数据库记录中发现 http://localhost/DocLib1 为受控URL，那么要访问 http://localhost/DocLib1/Test.doc，就不能让未经过验证授权的用户直接访问，而应该跳转到我们验证授权页面进行身份验证授权后方能访问。结果很让人遗憾，我们的访问畅通无阻。于是做了调试跟踪，发现在 HttpModule 中 Request.Url 不是我们想要的 http://localhost/DocLib1/Test.doc，而是一个对我们未知的 http://localhost/_vti_bin/owssvr.dll，正因为这个地址不是受控URL，所以HttpModule不做处理直接让用户继续访问了。 姑且不论owssvr.dll到底为何物，现在要解决的关键问题有两个： 为什么我们点的是 http://localhost/DocLib1/Test.doc 这个请求，而到HttpModule时，却变成了http://localhost/_vti_bin/owssvr.dll，谁干的好事？ 我们能否在这家伙做这件事之前把执行权抢过来做我们自己的处理？ 对于第一个问题：谁动了我的URL？在了解这个问题答案之前可以先参考以下文章： Windows SharePoint Services & SharePoint Server 2003 Architecture Essentials Overview of the SharePoint Team Services Architecture 看完上面两篇文章，或许你已经清晰知道是谁动了我们的URL。是stsfltr.dll（可以在IIS管理器-->Web站点属性窗口-->ISAPI 筛选器找到）这个ISAPI Filter在HttpModule之前抢先做了处理。 第一个问题找到了，第二个问题：怎么解决这个问题，把执行权抢过来？只能自己再写个 ISAPI Filter，并把该 ISAPI Filter排在stsfltr.dll之前了。于是，我们创建了一个C++ Win32 项目，定义了下面这个一个ISAPI Filter class： class CRedirectorFilter : public CHttpFilter { public:      CRedirectorFilter();      ~CRedirectorFilter();        BOOL IsSecureDocument(LPCTSTR docUrl, LPCTSTR agent, LPCTSTR cookie);      BOOL GetCookie(CHttpFilterContext* pCtxt,CString strName, CString & strValue);      BOOL GetAgent(CHttpFilterContext* pCtxt,CString strName, CString & strValue);   // Overrides      // ClassWizard generated virtual function overrides          // NOTE - the ClassWizard will add and remove member functions here.          //    DO NOT......[阅读全文]

摘要:在MOSS Document Library中的Page，有Basic Page和WebPart Page两种，前者更多的体现WCM特性，后者则更侧重体现Portal特性。 不管是Basic Page还是WebPart Page，都是直接和MOSS本身结合非常密切，都直接采用Site中的MasterPage。如果我们想把一个普通的ASP.NET Page也加到MOSS站点里运行，比如也放在Document Library里，或者放在Site某个文件夹下面，然后通过MOSS站点URL直接访问运行该ASP.NET Page，就需要做一些工作了。这里就准备介绍这么一个Tip来完成这件事。我想，这种应用方式主要是针对一些需要特殊页面效果，或者追求短平快的小量自定义的场景的，也不失为各类复杂应用场景提供一个可以方便Work Around的通道。正常应用场景中一般比较少用到。 1、首先从最简单的Hello World Page开始。点击此处查看 HelloWorld.aspx 源代码。 <%@ Page Language="C#" %>   <html> <head runat="server">     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">     <title>Hello World Page</title>       <script runat="server">         protected void Page_Load(object sender, EventArgs e)         {             Response.Write("Hello World!");         }     </script>   </head> <body>     <form id="form1" runat="server">     </form> </body> </html>  2、将HelloWorld.aspx上传到Documents文档库中。此时，你直接点击文档库中的HelloWorld.aspx进行浏览，其URL类似http://localhost/Documents/HelloWorld.aspx，将出现“An error occurred during the processing of /Documents/helloworld.aspx. Code blocks are not allowed in this file.”的错误异常。通过这个异常信息也就知道，其实我们要做的就是允许在Page Server Code能被顺利编译执行。 3、修改MOSS Site的web.config，比如C:\Inetpub\wwwroot\wss\VirtualDirectories\80\web.config。找到PageParserPaths这么一个节点，修改如下： <PageParserPaths>    <PageParserPath VirtualPath="/Documents/helloworld.aspx" CompilationMode="Always" AllowServerSideScript="true" /></PageParserPaths> 4、重新浏览http://localhost/Documents/helloworld.aspx，页面正常被编译执行。 至此已经验证普通的ASP.NET Page是可以顺利集成在MOSS中被执行的。可以看到CompilationMode="Always"就意味着这个操作是属于“不得已而为之”的了，但这类不得已的场景现实应用中毕竟还是存在的。下面发散思维，扩展下思路。 5、我们把SharePoint的一些接口也写在这个普通ASP.NET Page里，从这个ASP.NET Page去操作SharePoint的库表等相关信息。点击此处查看 HelloSharePoint.aspx源代码。 <%@ Page Language="C#" %> <%@ Import Namespace="Microsoft.SharePoint" %> <%@ Import Namespace="Microsoft.SharePoint.WebControls" %>   <html> <head runat="server">     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">     <title>Hello SharePoint</title>       <script runat="server">         protected void Page_Load(object sender,......[阅读全文]

摘要:通过以下代码枚举列出所有的Exchange Server、StoreGroups和MailStore，并获取每个MailStore中Mailbox的数量。本段C#代码为http://www.ureader.com/message/513012.aspx一文中的VBNET代码改写而成，在Exchange 2003环境中测试通过。 通过这段代码，结合创建 Mailbox 的代码，可以实现获取Exchange环境的Server、StoreGroup、MailStore和Mailbox信息，或在指定Store（比如在所有Store中最少Mailbox的那个，或者人为指定目标Store）中创建Mailbox。         protected void Page_Load(object sender, EventArgs e)         {             DirectoryEntry RootDSE = new DirectoryEntry("LDAP://RootDSE");             string rootPath = "LDAP://" + RootDSE.Properties["configurationNamingContext"].Value.ToString();             DirectoryEntry configContainer = new DirectoryEntry(rootPath);               DirectorySearcher configSearcher = new DirectorySearcher(configContainer);             configSearcher.SearchRoot = configContainer;             configSearcher.Filter = "(objectCategory=msExchExchangeServer)";               // Enumerate all Exchange Servers             SearchResultCollection serverResults = configSearcher.FindAll();             foreach (SearchResult serverResult in serverResults)             {                 Response.Write("<br/><br/><font color=\"red\">=== Exchange Server: " + serverResult.GetDirectoryEntry().Properties["cn"].Value.ToString() + " ===</font><br/><br/>");                   SearchResultCollection storeGroups;                 SearchResultCollection stores;                 int mailboxCount;                   // Enumerate all Store Groups                 storeGroups = SearchContainer(serverResult.Properties["distinguishedName"][0].ToString(),                     "(objectCategory=msExchStorageGroup)");                 foreach (SearchResult storeGroup in storeGroups)                 {                     string storeGroupName = storeGroup.GetDirectoryEntry().Properties["cn"].Value.ToString();                     Response.Write(storeGroupName + "<br/>");                       mailboxCount......[阅读全文]

摘要:MOSS 搜索相关： 在IE7的搜索设置项中增加 MOSS 搜索�