而在编译时，如果使用到外部类型，是需要引用外部类型的程序集，否则无法编译成功。我们也经常会遇到类型的编译错误：

CS0246: The type or namespace name '*******' could not be found (are you missing a using directive or an assembly reference?)

而解决问题的最好办法就是我们把编译所需的程序集放到Bin目录，这样就可以保证BuildManager编译成功。但是在某些环境中，我们就是不希望将这样的引用程序集放成Bin目录，而通过动态载入的形式载入所需的程序集。

BuildManager的内部很复杂，但是它所提供的接口却非常的有限，都只是查询类型和程序集的接口。因为在BuildManager中管理着系统中最全的类型和程序集，所有动态编译的类型和程序集都可以通过BuildManager的查询接口得到。也就是说，即使你通过Type.GetType接口无法得到的类型，可能你通过BuildManager.GetType就可以得到，前提是在当前的运行时确实存在着这个类型。BuildManager所维护的程序集列表，也比AppDomain维护的列表多得多，在BuildManager里还订阅了AppDomain.CurrentDomain.AssemblyResolve向当前Domain提供所需的程序集。

在BuildManager编译时，它都会把Bin目录的所有程序集按一定的规则拷贝到"%WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files"相应的动态目录里，每个程序集单独一个目录，并配上__AssemblyInfo__.ini。

显然，我们让BuildManager在动态编译时动态增加程序集引用，是无法通过AppDomain来加载程序集来实现。必须想办法让程序集能够被添加到BuildManager的引用列表中，并且最好能够做到，不在Bin目录下的程序集，也会被动态拷贝到相应的动态目录里面，实际上要达到的行为是一个站点目录中可能会同时出现多个Bin目录。

通过搜索，我找到这样的答案，在Web.config做如下的配置，即可在一个站点里面设置多个Bin目录，让站点在编译时能找到引用：

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <probing privatePath="WebFileManager/bin" />
  </assemblyBinding>
</runtime>

全文完

使用Telnet发送邮件：

打开cmd命令行

输入telnet 127.0.0.1 25，连接本地邮件服务器

输入HELO，建立会话，返回250成功代码。

输入MAIL FROM:youname@server.com，邮件发送者，返回250成功代码。

输入RCPT TO:friend1@server.com ，邮件接收者，返回250成功代码。在这一步如果出现 550 5.7.1 Unable to relay for ******* 则需要在IIS自带的SMTP，在SMTP虚拟服务器上点击右键，在弹出的属性窗口里进行如下设置：

点击访问选项卡，再点击中继，在弹出的窗口出点击添加，然后选单台计算机，添加IP地址为 127.0.0.1。然后一路确定返回。

输入DATA，开始输入数据，在下一行输入以下邮件内容：

subject:this is subject

this is body

.

输入"."回车后邮件即被发送出去。

同时在此推荐一款由我们老板在几年前独立自主开发的邮件发送组件，qqMail.net，它可是一个可能强大的邮件发送组件，实现了比较全的SMTP协议，包括使用localhost匿名发送邮件，绝对比.NET自带的SMTP Client功能强大不少，作者本人也对SMTP的原理了如执掌。

也许这个组件DnSmtp也是相当的有用，但是我并没有用过。

Assembly assembly = CSScript.LoadCode(
    @"using System;
      public class Script
      {
          public static void SayHello(string gritting)
          {
              Console.WriteLine(gritting);
          }
      }");
AsmHelper script = new AsmHelper(assembly);
script.Invoke("Script.SayHello", "Hello World!");

使用Cs-Script很简单，只需要引用一个很小的程序集，它的使用同样简单。通过CSScript.LoadCode动态编译一段C#脚本，返回程序集对象，再利用AsmHelper对象以静态方法或返回实例对象的方式反射调用C#代码功能。

动态使用脚本可以给系统带来很大的灵活性，它和可与.NET互交互的Ironpython有着某种异曲同工之处，但又各有千秋。Ironpython可以充分发挥动态语言方便灵活的特点，但Cs-Script却完全具备了C#的完全功能。使用CS-Script最大的优势在于，它完全兼容.NET 2.0/3.0/3.5等版本，和Mono的基于功能。它以静态函数或对象实例的形式在系统中使用，运行于当前的AppDomain，给开发人员的使用带来极大的便利。而据我了解的Ironpython目前还只支持.NET 2.0，不支持C# 3.0的所有特性，这是当前Ironpython存在的一大不足，并且对于.NET开发人员来说，在python和C#两种语言之间不断切换也给开发调试带来非常大的麻烦。

开发语言的动态化是现代语言的一大趋势，但是从系统开发和维护的角度来说，个人还是倾向于静态为主，动态为辅的平台。在一些场合，动态语言（包括动态编译）都会给系统框架带来更大的灵活性。ASP.NET .aspx/ascx上的C#脚本就是动态编译的一个最直接的例子。

自己撰写技术博客已经有三四年的时间了，最开始写技术博客是为了总结自己在工作当中的一些心得和解决问题的过程。这是一个享受的过程，享受解决问题后的那种喜悦；享受在解决问题过程中煅练出来的举一反三，独立思考的能力；享受自己在工作中不断积累的那种兴奋。这时候写技术博客真正受益的只是自己，是自己进步一种手段。因为解决问题，不应仅仅解决了问题本身，还应该要知道为什么会出现该问题，这时候通过技术博客就能很好的进行分析和总结。

后来，随着能力的提高和经验的积累，解决问题已不再需要花费自己很多的时间。此时对技术有了更多的追求，开始对一些社区中推荐的开源框架产生了浓厚的兴趣，并着手进行研究。通过自己的研究，真正开阔了自己的眼界，虽然此时还并不能很好的完全读懂这些框架的代码。但是有了这层历练后，对自己之后的再进一步跨跃打下了很好的基础。对开源框架的兴趣不仅仅停留在研究的层面上，在开发实践中也在不断的找机会去使用这些开源框架，在这程当中获得了大量的第一手实践心得，并将这些心得以技术博客的形式总结出来。曾经试用过的开源框架包括：iBatis.net,Enterprise library,Castle,NBear,ASP.NET AJAX还有很多很多，但是经过一些实践后，现在仍然在使用的已经不多了。这些技术实践对自己现在的技术形态起着关键而深远的影响。

在自己有一定能力的时候，开始参与一些开源项目的工作。参与了NBear Mapping组件的开发，LumaQQ.NET开发包，开源了自己在开发实践中的一些零碎组件。在这个时候，以技术博客的形式发表项目文档和入门指南，并与使用者进行交流。

然而，在近来的一段时间里，由于忙碌等原因，自己慢慢的失去了通过撰写技术博客的方式来总结自己的技术体验。同时也产生了如何撰写技术博客的一些迷茫，要写一篇有质量，有内容所要需要花费大量的时间和精力，并且必须有很大的动力或者冲动，如果失去了这种冲动，那一篇构思完善的文章最后有很大可能是要夭折的。在过去的三天时间里，获得了近几个月以来少有的假期清闲，但是自己可以花一天的时间观看《走西口》，却懒得将一篇已写了两天的技术总结完成了。这就是慵懒的后果。

一直在思考该怎样写技术博客。也许现在给自己的答案是：想到哪，写到哪，一定要趁着当时的冲动，一口气完成。既然是博客，那就不需要组织太严谨。既然没有文采，那就用最为平实的语言来描述表达。只要自己日后还能看懂，有兴趣的人也能看明白就行了，要求别太高了。

这个其实是ASP.NET 2.0的一个“精心”设计，因为在很多情况下。ASP.NET会缓存很多资源，而如果没有监控目录的变动的话，那么有些已删除的资源就有可能仍然被使用着，造成其它不必要的资源泄露。通过这篇文章我们可以找到可能导致站点重启的一些条件，其中的第一条就是删除或重命名目录会导致站点重启。

这个问题早在ASP.NET 2.0刚发布的时候就被发现，并且已经有了专门的讨论《Deleting ASP.NET 2.0 Application Sub-Directories Shuts Down the AppDomain》，在文中也提了一种解决方案，但是做法太过复杂。最理想的方案是，有相关的补丁来解决这个问题，幸运的是，我们可以通过这里找到这个补丁，并且介绍如何配置来解决这个问题。

解决方案是：监控目录删除或重命名的机制叫：File Change Notifications （FCNs），这个补丁就是用来设置FCNS禁用或启用的开关，我们只要把FNCS禁用就可以避免这个问题。

做法：现在的ASP.NET 2.0已经到了SP2，我们不需要单独去安装这个补丁。我们只需要在注册表在做一步操作即可解决这个问题。在HKLM\Software\Microsoft\ASP.NET 添加一个名为：FCNMode 的DWORD值，默认它应该是不存在的，它的值含义为：

Does not exist
This is the default behavior. For each subdirectory, the application will create an object that will monitor the subdirectory.

0 or greater than 2
This is the default behavior. For each subdirectory, the application will create an object that will monitor the subdirectory.

1
The application will disable File Change Notifications (FCNs).

2
The application will create one object to monitor the main directory. The application will use this object to monitor each subdirectory.

我们将它的值设为1即可禁用FCNS。更为详细的可以参考：http://support.microsoft.com/kb/911272

退出注册表，重启IIS，问题即可解决。

说明一下：Session丢失只是AppDomain重启的一个副作用，并不是本文的重点，只是为了方便别人查找相关问题时的一个标题优化。另外导致站点重启的原因有很多种，可以参考上文给出的链接，这里不再遨述。

再次说明一下：如果你禁用了FCNs，那么不管你是修改了Web.config，还是BIN目录，都不会引起整个站点的重启。我想这个也会相应的给我们带来一些新的问题，比如缓存过期的问题。至于是否禁用，大家自己选择吧。:(

同理，Reqeust.QueryString也是不区别大小写的。

项目模板的创建非常简单，我们只需要将希望作为项目模板的工程，导出即可，在Visual Studio 中找到：File >> Export Template

如果当前解决方案中有多个工程，我们可能通过下拦框选择希望被作为模板的项目，选择“Project template ”进入下一步：

在这里，你可以选择是否自动将模板导入到Visual Studio ，还可以选择是否弹出显示导出的项目模板，点击完成即可完成项目模板的导出，并且此时，它会为我们自动导入到Visual Studio中，并且会弹出导出的项目模板目录，它是一个zip压缩文件。此时，我们再打开一个Visual Studio，新建项目时即可使用刚刚导出的模板。

到些为止，项目模板的创建已经完成。但是还有一点麻烦的是，每次我们要安装此模板时，需要手工将该压缩文件拷贝到项目模板目录，使用起来不是很方便。我们希望能像安装文件那样，双击即可完成安装，不需要手工拷贝文件。此时我们还需要一个文件，.vscontent，来制作.vsi安装文件。我们在刚刚导出的项目模板目录中新建名为：SampleProjectTemplate.vscontent的xml文件。它的内容如下：

<?xml version="1.0" encoding="utf-8" ?>
<VSContent xmlns="http://schemas.microsoft.com/developer/vscontent/2005">
    <Content>
        <FileName>SampleProjectTemplate.zip</FileName>
        <DisplayName>Sample Project Template</DisplayName>
        <Description>A project template created for this example.</Description>
        <FileContentType>VSTemplate</FileContentType>
        <ContentVersion>1.0</ContentVersion>
        <Attributes>
            <Attribute name="ProjectType" value="Visual C#"/>
            <Attribute name="ProjectSubType" value="Web"/>
            <Attribute name="TemplateType" value="Project"/>
        </Attributes>
    </Content>
</VSContent>

以上的属性配置就不多介绍了，需要说明的是ProjectSubType属性是指定将该模板安装在Web的项目列表当中。将项目模板的压缩文件和SampleProjectTemplate.vscontent压缩成一个ZIP文件，并且修改后缀名为：.vsi 。然后你可以看到的它的图标发生面什么变化了，双击该文件，我们会得到这样的一个安装向导界面：

OK，这就是我们需要的一个项目模板安装文件，直接完成，就可以完成项目模板的安装和导入。

现在，你就可以开始动手创建自己的项目模板了，享受项目模板带来的便利了 :)。

我们希望将版本控制的功能，独立于某一个具体的业务实体，这样才可以实现最大共用和扩展性。显然，要实现这一功能最好的切入点应该是在数据持久层，也就是在实体持久化时，我们需要有一个统一的，通用化的接口来完成，同时在这里插入版本控制的功能。无疑，这里的最合适的持久化接口应该是ORM，那就相当于我们要实现一个带实现版本控制的ORM接口。

版本控制功能，我们不仅要求与数据库无关，还要求与具体的某一种ORM框架无关。与数据库无关，我们可以很容易通过ORM来隔立，但是与ORM框架无关，我们就需要将版本控制的功能从与某一种ORM框架隔离开来。

版本控制功能，是插入到ORM接口中去的，那在哪里去检测实体的修改情况呢？一种方案是将原始数据和修改后的数据，传入版本控制接口，由版本控制模块进行比较，从而得出实体的变化情况。

另一种方案，就是在实体中插入一定的属性变化跟踪机制，这也是现有的ORM实体中已经有实现的一部分，不同的ORM框架在监控实体更新变化方面都有不同的机制，在NBear，LINQ To SQL，Entity Framework都有一套自己的实体属性变化跟踪机制。我们可以将这些不同的跟踪机制统一起来，形成一套标准的ORM版本控制模块的接口实现。

还有一些需要考虑的：

存储历史版本时，是使用增量存储还是使用完全存储。增量存储，在回滚历史版本时，就需要从当前版本起，做很多的回溯的工作，而完全存储就可能会耗很多存储空间。

在存储方式上，我们是将它们存储到数据库，还是以XML文件的格式单独存放每一个版本的记录。

目前的一个存储想法是：使用增量存储与完全存储共存，将每次改变的字段，以及它的原始值和新值保存到数据库中，方便在查看历史版本修改记录时用。而将每个版本完整值，以一定的目录格式，XML文件的格式保存在磁盘中，可以考虑压缩等因素。这样做的原因是，回滚历史版本的操作一般是相对比较少的，但是存储完整的历史版本值，却可能需要很多的数据库空间和考虑备份的问题。假设我们以操作日期的目录格式来保存文件，我们就可以方便的进行备份和转移。

遗留问题，在ORM中，对象的关联是必不可少的内容。对于对象之间的关联关系发生变化是否也需进行版本控制，这样一来，版本控制的内容就会变得更复杂和难以实现。所以暂且限定，版本控制只针对于单对象的属性值变化。

以上就是ORM With versioning control的一些想法，这些想法是从Content Repository API For Java (JCR)衍生而来的。在JCR中是实现了一个自有格式(XML)的数据库，用在CMS中存储一些结构可变（非结构化）的内容。同时在它的功能定义中，还包括了一些传统数据库（或数据库使用接口）所不具有的功能，包括：版本控制，数据变化检测等功能。我想法，在结构化数据的存储中，要实现这些功能，应该是在ORM上来实现，欢迎大家来讨论。

过去的一段时间，由于一些个人事情的牵伴，无法专心投入技术的研究和总结，落下了很多东西，不过总算是没有脱离主流。从现在开始，又要投入更有挑战性的工作当中去，在这过程当中，我相信会有很多东西值总结和思考，我希望能把这些东西记录下来，不断的促进自己的进步。技术的追求是无止尽的，我永远不会赞同够用就好的理念，那样是给自己找放松的理由，同时也会让自己只问题的表象，而不了解内在的本质。只会参考demo写代码的人，经验再丰富那都只是重复的机械运动，没有任何价值。我相信老板们更愿意找年轻，廉价的程序员来做这些事情。

扯远了，一点小感概（最近园子里面不是在掀起新一轮的程序员年龄与能力话题讨论吗）。在厦门的新环境，自己还是比较满意的。谦逊大方的老板，团结友好的同事，宽松自由的环境，这是自己能够快速适应这里环境的主要原因。在这里，可以找到探讨和学习的对象，在短短的一个月时间里，已经能明显的感觉到自己的一些方面突破。一个良好的技术环境，可以直接或间接的给我很多启发，也在不断的促进着我技术的进步，希望这是自己的技术生涯走向一个新的阶段的开始 :)。。

好久都没有继续LumaQQ.NET的开发，这一段时间一直没有心思静下心来做开发工作。导致LumaQQ.NET发布了三个版本之后，开发就一直处于停滞状态，关注的也少。今天在小组内，有朋友发出了登录失败：您的QQ版本已经停止使用这个贴子后，在晚上的时间了解了下确实是，腾讯停止了QQ2005协议了，在迷茫之际终于有人就提出将客户端版本号标志改为0x0E1C即可登录，试下果真可以。我之前也有试过修改这个版本号，可能是没有找到正确的版本号，导致登录时出错未知异常。如果有人知道，能不能麻烦把目前所有版本的QQ版本号标号告知一下，我也省得再去花时间找。

为了方便大家，先放出目前的可用版本，有需要的请下载更新程序集引用即可

程序集和文档下载

源代码（SVN）

另外，也许还需要一段时间才能继续LumaQQ.NET的开发，请大家见谅，也谢谢大家对LumaQQ.NET的关心和关注！

链接：

LumaQQ.NET讨论小组：http://space.cnblogs.com/group/100260

LumaQQ.NET官方开发博客：http://hjf1223.cnblogs.com/

在ASP.NET WebForm的架构下，我们可以通过一定的配置即可实现用户身份验证和授权。特别是在ASP.NET 2.0的Membership功能的支撑下，可以做到更加简洁可复用的用户验证系统。通过web.config可以做到对页面或目录对不同用户身份可见性的定制，但是它是基于物理文件和目录。而在ASP.NET MVC架构下，用户访问的每一个页面在磁盘中并没有一个固定的物理文件，它是通过Controller控制数据与视图的组合来生成HTML代码，进而向客户端输出。那么我们该如何来复用已有的表单验证授权机制呢？

在MVC中，请求的功能入口是Controller相应的Action函数，我们可以在函数执行前去控制请求权限。在ASP.NET MVC Preview 2后，提供了一个机制让我们可以对Action的AOP拦截，这个接口定义如下：

   1: public interface IActionFilter

   2: {

   3:     void OnActionExecuted(ActionExecutedContext filterContext);

   4:     void OnActionExecuting(ActionExecutingContext filterContext);

   5:     void OnResultExecuted(ResultExecutedContext filterContext);

   6:     void OnResultExecuting(ResultExecutingContext filterContext);

   7: }

我们有两种方式来实现拦截，一种我们可以通过定义Attribute来实现拦截的功能，在System.Web.Mvc程序集中有一个ActionFilterAttribute抽象类，通过重写这个抽象类的这些虚方法，我们就可以实现对特定的执行过程进行拦截。

另一种方法，我们注意到Controller这个类也实现了IActionFilter这个接口，并且也提供了这四个函数的虚拟方法定义。框架内部，在调用Action方法的时候同时来调用这些拦截方法。具体的可以参考：ControllerActionInvoker 这个类的实现，所有的Action的调用都在这个类当中被实现。所以我们只要重写Controller里这四个虚方法，也可完成本Controller面的所有Action的拦截。

在这里，我也找到了国外友人已经实现好的基于角色的MVC权限控制的方案。自定义了两个自定义Attribute，分别为：RequiresAuthenticationAttribute和RequiresRoleAttribute。通过这两个Attribute来可以作用于Class和Method，用标记哪些Controller或Action需要登录后，或者需要拥有哪些角色才能执行。如果用户没有拥有访问当然Controller或Action权限的时候，就会自动被重定向到登录页面去。下面是两个类的定义：

/// <summary>

/// Checks the User's authentication using FormsAuthentication

/// and redirects to the Login Url for the application on fail

/// </summary>

[RequiresAuthentication]

public class RequiresAuthenticationAttribute : ActionFilterAttribute

{

    public override void OnActionExecuting(ActionExecutingContext filterContext)

    {

        //redirect if not authenticated

        if (!filterContext.HttpContext.User.Identity.IsAuthenticated)

        {

            //use the current url for the redirect

            string redirectOnSuccess = filterContext.HttpContext.Request.Url.AbsolutePath;

            //send them off to the login page

            string redirectUrl = string.Format("?ReturnUrl={0}", redirectOnSuccess);

            string loginUrl = FormsAuthentication.LoginUrl + redirectUrl;

            filterContext.HttpContext.Response.Redirect(loginUrl, true);

        }

    }

}

/// <summary>

/// Checks the User's role using FormsAuthentication

/// and throws and UnauthorizedAccessException if not authorized

/// </summary>

public class RequiresRoleAttribute : ActionFilterAttribute

{

    public string RoleToCheckFor { get; set; }

    public override void OnActionExecuting(ActionExecutingContext filterContext)

    {

        //redirect if the user is not authenticated

        if (!String.IsNullOrEmpty(RoleToCheckFor))

        {

            if (!filterContext.HttpContext.User.Identity.IsAuthenticated)

            {

                //use the current url for the redirect

                string redirectOnSuccess = filterContext.HttpContext.Request.Url.AbsolutePath;

                //send them off to the login page

                string redirectUrl = string.Format("?ReturnUrl={0}", redirectOnSuccess);

                string loginUrl = FormsAuthentication.LoginUrl + redirectUrl;

                filterContext.HttpContext.Response.Redirect(loginUrl, true);

            }

            else

            {

                bool isAuthorized = filterContext.HttpContext.User.IsInRole(this.RoleToCheckFor);

                if (!isAuthorized)

                    throw new UnauthorizedAccessException("You are not authorized to view this page");

            }

        }

        else

        {

            throw new InvalidOperationException("No Role Specified");

        }

    }

}

如上所介绍的两种方法，我们一样可以定义一个Controller基类，通过拦截来进行权限的控制。但是与定义Attribute相比，手法并不是很好，也不利于通用化。但是就理论上的性能来说，会比Attribute更好。

到目前为止，ASP.NET MVC还没有更新的消息，我想在正式版本的ASP.NET MVC框架，权限控制问题会有一个官方说法。希望到时候会有一种更为灵活和可配置的方案。也许通过控制Url来控制访问权限也是一种可行的方案，会不会集成到RouteTable里面呢？让我们试目以待吧。

上一篇：ASP.NET MVC :从ASP.NET WebForm到ASP.NET MVC技术上的共用和差异

广告：我的基于MVC的网站

之前，从事ASP.NET开发，在没有特殊说明的情况下，指的就是ASP.NET WebForm的开发。之前ASP.NET技术的发展，直接就体现在WebForm技术上的进步。在ASP.NET MVC 出现之后，之前大家所掌握的ASP.NET技术对于ASP.NET MVC仍然有效，并且是最基础的部分。包括：页面处理流程，Web请求上下文对象，Web配置系统，公用性的组件模块，部分的服务器控件等等。我想从这几大块来详细阐述ASP.NET MVC对于ASP.NET技术的继承：

1. 页面处理流程：ASP.NET MVC 的页面处理流程仍然是在ASP.NET原有的处理流程上的扩展，在在上游的请求通道不变的前提下，通过特定的IHttpModule和IHttpHandler来处理ASP.NET MVC的请求。与WebForm页面处理不一样的地方就在于，在WebForm中，每一个页面都是一个IHttpHandler实例，页面的事件流程就是从IHttpHandler的ProcessRequest(HttpContext httpContext)方法开始。而在ASP.NET MVC中，所有的Controller都并不是IHttpHandler的继承实例，它的Action是在MvcHandler中被执行的，当然我们也可以自定义是MvcHandler。
2. Web请求上下文对象：在ASP.NET MVC中，处理请求的线程模型没有改变。请求的上下文对象，与原有的ASP.NET WebForm仍然是共用的。
3. Web配置系统：ASP.NET MVC仍然使用原有的配置系统，在Web.config中只是部分的配置节点不适用于ASP.NET MVC，比如页面访问授权配置。
4. 公用性的组件模块：在ASP.NET MVC中，包括Membership，healthMonitoring，httpModule,trace在内的内置和自定义的组件模块仍然是继续可用。
5. 部分服务器控件可用：首先，最为明显的是我们使用的是.aspx页面作为MVC的View。虽然后缀仍然为.aspx，但是它的意义已经不再是一个可执行的页面文件了，不再是一个纯粹意义上的IHttpHandler。但是它仍然是继承于原有的Page基类。在ASP.NET MVC中，将它作为View来展示，仍然以ProcessRequest为入口来执行页面，也就意味着除了回发事件的相关事件和函数不会被执行外，页面的执行事件流程仍然是有效的。以此，如果不考虑服务器控件的性能和其它因素影响，我们仍然是可以使用大部分的服务器控件，当然用不用取决于你。

以上是我总结到的一些ASP.NET MVC对ASP.NET原有技术的继承，但是做为ASP.NET技术的发展，有很多东西是本身就是乏善可陈的，不说，也应该知道就是那样。但是说出来，更有助于大家来区分ASP.NET，(ASP.NET)WebForm，ASP.NET MVC(为什么WebForm前面的ASP.NET加括弧呢？大家来说说原因)这三者的概念区别和关系。

下面我还想来说说，ASP.NET MVC较之前的ASP.NET(WebForm)开发技术在实践上有哪些比较明显的区别：

1. .aspx文件，已经不再是一个可被独立请求的页面了。你不能对它从物理上进行权限控制。
2. 我们的少用服务器控件了。我们仍然可以使用，你完全可以不考虑runat='server'的性能影响。但是并不保证所有的服务器控件都可用。可能还有其它的原因让你选择不使用服务器控件。
3. 我们没有PostBack和页面回发事件机制了。提交表单我们基本使用Web的原生方式了，传输的数据量也更为合理。
4. 我们少用ViewState了。少用，意味着我们还是可以用的。只是由于MVC架构的限制，我们在ViewState存的值并不会被序列化到客户端去，它有效性是在一次请求的上下文中。在某些特定的场合内，ViewState还是能发挥它的余热，并且并不影响性能。
5. 要处理一个用户的自定义请求，比如RSS请求。我们不再需要定义一个IHttpHandler或特定的.aspx页面。处理用户的每个请求都只是在一个Controller的Action函数当中，在Action函数中，你可以输出View，可以输出JSON字符串，还可以输出任何自定义格式的文件和输出流。
6. 业务逻辑与UI逻辑从架构上得到了很好的分离，但是你要不想这么做，仍然也是有效的。只是在这种情况下，你还是选择WebForm吧。

ASP.NET MVC和WebForm在很多实现上的统一，是我们已经掌握ASP.NET原有开发模式的开发人员顺利的上手MVC保证。之后陆续会有几篇我在用MVC实践自己一个网站后，对MVC的一些总结和心得。

The web services enumeration components are not available. You need to reinstall Visual Studio to add web references to your application.

在中文社区中没有找到相关的解决办法，通过国外的一个博客找到了解决方案：

运行：devenv /resetskippkgs

这个办法至少对他，对我都是有效的。

QQWry.NET.QQWryLocator qqWry = new QQWry.NET.QQWryLocator("qqwry.dat");//初始化数据库文件，并获得IP记录数，通过Count可以获得

QQWry.NET.IPLocation ip = qqWry.Query("120.67.217.7");  //查询一个IP地址
Console.WriteLine("{0} {1} {2}", ip.IP, ip.Country, ip.Local); 

以下是与IPLocation.dll在性能上的对比代码：

   1: Stopwatch stopwatch = new Stopwatch();

   2: List<string> ips = new List<string> { "218.5.3.128", "120.67.217.7", "125.78.67.175", "220.250.64.23", "218.5.3.128", "120.67.217.7", "125.78.67.175", "220.250.64.23" };

   3: stopwatch.Start();

   4: for (int i = 0; i < 100; i++)

   5: {

   6:    foreach (string item in ips)

   7:    {

   8:         ip = qqWry.Query(item);

   9:       // Console.WriteLine("{0} {1} {2}", ip.IP, ip.Country, ip.Local);

  10:    }

  11: }

  12:  

  13: stopwatch.Stop();

  14: Console.WriteLine("QQWryLocator 花了{0} ms", stopwatch.ElapsedMilliseconds);

  15:  

  16: stopwatch.Reset();

  17: stopwatch.Start();

  18: for (int i = 0; i < 100; i++)

  19: {

  20:    foreach (string item in ips)

  21:    {

  22:        string s = IPLocation.IPLocation.IPLocate("qqwry.dat", item);

  23:       // Console.WriteLine(s);

  24:    }

  25: }

  26: stopwatch.Stop();

  27: Console.WriteLine("IPLocation 花了{0} ms", stopwatch.ElapsedMilliseconds);

性能比较结果：

源码和示例下载。

阿不

但是，在有些情况下，虽然我们开发的Web Service都使用元数据类型的参数，为什么死活都无法直接调用测试呢？点击方法链接也只是出现SOAP消息的格式定义？原来这个问题一直都没有解决，google一下就可以找到解决办法了，只要我们在web.config中的system.web配置节点下增加这一段配置即可：

   1: <webServices>

   2:    <protocols>

   3:      <add name="HttpPost" />

   4:      <add name="HttpGet" />

   5:      <add name="HttpPostLocalhost" />

   6:    </protocols>

   7: </webServices>

相关资料：http://msdn.microsoft.com/en-us/library/aa560062.aspx

本周六5月10日在福州外贸中心酒店10楼会议室 举行的福建ITPro交流活动，

这是省内由微软举办的第一次IT行业专家交流会，届时我们会邀请微软最有价值专家及微软资深讲师与各位分享沟通技术热点及解决方案，希望能有机会与各位IT精英现场交流。

具体安排如下： 

微软整体IT安全方案与SharePoint 2007成功案例展示 活动时间：05月10日 / 14:00-17:00 / 13:30开始签到 信息系统给企业带来了诸多便利，越来越多的信息通过网络进行高效的传递，同时也带来了全新的挑战，即如何保护我们的系统，使它们能够在不断演变、日益增多的安全风险中安然无恙，微软有没有专门争对安全的整体方案呢？IT整体安全策略 SharePoint Server 2007是一个好平台，这大家都知道，但大部分都碰到一个问题，如何应用？能帮助企业实现什么？能给企业带来什么价值？由中国移动福建公司泉州分公司成功案例的分享，将会给我们带来一个最好的学习机会。 日程安排 13:30-14:00　来宾签到 14:00-14:30　福建ITPRO团队介绍 14:30-15:20　微软IT整体安全策略 15:20-15:40　休息、交流 15:40-16:30　SharePoint 2007中国移动成功案例 16:30-17:00　填写反馈表/交流/Q&A 联 系 人：王冬兴 报名电话：13313783437 报名邮箱：owen@owencn.net ITProCity简介 　　ITProCity是一个面向IT专业人士及其团队的会员制联盟组织，面向所有IT专业人士开放，符合条件的IT专业人士和IT专业人士团队都可以成为ITProCity的会员。 　　ITProCity 致力构建一个社区协助平台，帮助IT专业人士及其团队沟通交流、获取知识、提升技能、实现价值；并帮助IT专业人士及其团队与主流IT厂商之间建立良好的互动关系。 讲师介绍 宋立桓MVP 雷君MVP 活动地点 福州外贸中心酒店10楼小会议室 福州 鼓楼区 五四路73号

ITProCity团队 福建ITPRO团队 2008年05月

   1: <asp:DetailsDataSouce ID="DetailsDataSouce1" runat="server">

   2: </asp:DetailsDataSouce>

   3: <asp:DetailsView ID="detailsView" runat="server" DefaultMode="Edit" DataSourceID="DetailsDataSouce1">

   4:     <Fields>

   5:         <asp:TemplateField>

   6:             <HeaderTemplate>

   7:                 电流:</HeaderTemplate>

   8:             <EditItemTemplate>

   9:                 <asp:TextBox ID="textBox1" runat="server" Text='<%# Bind("[电流{a}]") %>'></asp:TextBox>

  10:             </EditItemTemplate>

  11:         </asp:TemplateField>

  12:     </Fields>

  13: </asp:DetailsView>

在一个页面中，定义了如上的一个DetailsView控件，为这个控件指定了ID为DetailsDataSource1的DataSouceControl控件，这个控件是我们自己定义的一个DataSourceControl，它返回的数据字段包括："ID"，"电流{a}"，"电压(v)"，"备注'"，"名称]"。我并没有设置DetailsView的AutoGenerateRows属性的值，默认情况下，它是为我们自动的生成这些字段的对应的数据显示和输入控件。除此之外，我们还另外添加了一个数据模板字段，在这个模板中指定了编辑模板。在编辑模板中我使用了<%# Bind("")%>这样的语法，将textBox1与"[电流{a}]"字段双向绑定起来。

为什么这里的字段都有一些特殊呢？因为我原先的意图是除了分析绑定语法以外，还要测试哪些特殊字符无法使用数据绑定语法来绑定数据的。这个在下篇文章中会具体介绍。

Bind与Eval不一样，这样的Bind并不Page或TemplateControl的一个方法，事实上我们应该把它当成一个关键字来看待，因为在ASP.NET的双向数据绑定当中，并没有这样的一个函数存在，它的存在是只是告诉ASP.NET动态编译页面类时，将这个语法编译成一定的代码格式，并生成一些函数代理来达到双向数据交流的目的。

那么这一段代码，动态编译生成的服务器代码又是如何的呢？让我们反编译动态程序集，里面会找到用于创建DetailsView的__BuildControldetailsView的私有方法，在这里会调用到一些其它内部方法，我们不要让这些方法来干扰我们的视线，直接找到创建如上模板字段的方法：

   1: [DebuggerNonUserCode]

   2: private TemplateField __BuildControl__control5()

   3: {

   4:     TemplateField field = new TemplateField();

   5:     field.HeaderTemplate = new CompiledTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control6));

   6:     field.EditItemTemplate = new CompiledBindableTemplateBuilder(new BuildTemplateMethod(this.__BuildControl__control7), new ExtractTemplateValuesMethod(this.__ExtractValues__control7));

   7:     return field;

   8: }

这里首先把this.__BuildControl__control6作为一个代理函数，用于创建头部模板的内容，也就是如上的“电流：”字段标题。然后才是创建EditItemTemplate，这个模板又被一些的中介模板所代替，我们只需要来关心this.__BuildControl__control7和__ExtractValues__control7即可。__BuildControl__control7是为了编辑数据字段时，将数据字段的值显示在输入控件中（输入控件的初始化，即字段值绑定到输入控件中）；而__ExtractValues__control7则是在提交数据时，要找出这个模板内所有的双向绑定字段，将这些字段的值以绑定字段名为Key，以输入控件的值为Value添加了IOrderedDictionary字典中。DetailsView等数据绑定控件调用这些委托代理来收集所有的被双向绑定的字段的最新的值。下面分别是两段函数的代码片段：

   1: [DebuggerNonUserCode]

   2: private TextBox __BuildControl__control8()

   3: {

   4:     TextBox box = new TextBox();

   5:     box.TemplateControl = this;

   6:     box.ApplyStyleSheetSkin(this);

   7:     box.ID = "textBox1";

   8:     box.DataBinding += new EventHandler(this.__DataBinding__control8);

   9:     return box;

  10: }

  11: public void __DataBinding__control8(object sender, EventArgs e)

  12: {

  13:     TextBox box = (TextBox) sender;

  14:     IDataItemContainer bindingContainer = (IDataItemContainer) box.BindingContainer;

  15:     if (this.Page.GetDataItem() != null)

  16:     {

  17:         box.Text = Convert.ToString(base.Eval("[电流{a}]"), CultureInfo.CurrentCulture);

  18:     }

  19: }

   1: [DebuggerNonUserCode]

   2: public IOrderedDictionary __ExtractValues__control7(Control __container)

   3: {

   4:     TextBox box = (TextBox) __container.FindControl("textBox1");

   5:     OrderedDictionary dictionary = new OrderedDictionary();

   6:     if (box != null)

   7:     {

   8:         dictionary["[电流{a}]"] = box.Text;

   9:     }

  10:     return dictionary;

  11: }

由上面的代码片段可以了解到，ASP.NET动态编译器是将Bind语法拆分为两部分：绑定输出和读取输入控件值。绑定输出部分与前篇介绍的机制是完全一样的，并且也是调用DataBinder.Eval方法来绑定数据；而读取输入控件值则是会根据页面上控件的类型，以及绑定的控件属性名称，生成一段强类型的控件属性读取代码，并将控件的值保存到dictionay中返回出去。而它全然不知，容器控件是如何将这些值合并起来传给对应的DataSouceControl控件的。

关于数据容器控件而何与DataSouceControl协同工作，并不是我们这里要分析的重点。但是我们可以简单的描述一下工作流程，以DetailsView的数据更新为例：大家通过反编译DetailsView的源码，会找到名称为HandleUpdate的私有方法，在这个方法里面会去处理数据项更新前的值(至于在Web环境中如何保存更新前的值，就需要靠ViewState的强大功能了)，和更新后的值(通过ExtractRowValues函数调用类似上面生成的__ExtractValues__control7代理函数来收集所有双向绑定字段的值存到NewValues里面)，并将他们分别保存在两个不同的IOrderedDictionary对象（OldValues，NewValues）中。然后将调用对应的DataSouceView的Update方法，传入原字段值和新字段值和一些必须的参数，即可由我们通过重写DataSourceView的方法来得到所有需要更新字段的原始值和新值，并可以对比比较哪些字段值是否发生了变化。NBearDataSource控件就是利用了这样的机制来直接重DataSourceControl和DataSourceView来达到数据的全自动修改和添加方案的。

这里还有一点不得不说，在GridView,DetailsView，并不一定需要使用<%# Bind("")%>语法来实现数据的双向绑定，他们的字段双向绑定可以通过BoundField及它的子控件代替模板控件的绑定语法，一样可以达到双向绑定的目的，简单但没有模板来得灵活。而在存取不同版本的字段值也是类似的机制。

由于这部分涉及到的都是动态和内部代码，如果没有亲自去阅读这些代码，估计还是很难理解。最后我们再来简单总结一下：ASP.NET在模板中双向绑定字段，是通过<%# Bind() %>这样的语法，但是Bind我们更应该把它理解为是一个关键字，而不是一个函数。因为在ASP.NET的控件中，并没有存在这个函数。ASP.NET运行时在编译页面代码时，会把Bind关键字的代码当成两部分来编译：一部分是单向绑定代码；另一部分而是读取对应输入控件的绑定属性，以绑定字段名为Key，添加到IOrderedDictionary中收集返回给数据容器控件（GridView,DetailsView,FormView）等，让它们处理。

总体来说，ASP.NET 2.0的双向绑定机制给我们在提交数据时带来了极大的方便，尽管有些人很排斥DataSourceControl的模式，但是我们不可否认合理应用会大大提高我们的开发效率。希望通过这两篇的介绍，我们能对ASP.NET数据绑定机制有更多的认识。在下一篇的文章中，我们将会介绍一些关于数据绑定方式，性能，以及对字段名的局限性等相关主题。

附上示例工程，本文分析面页是Default3.aspx和App_Web_ryn6wtvv.dll程序集。

系列导航:

深入ASP.NET数据绑定（上）

深入ASP.NET数据绑定（下）——多样的绑定方式

首先要向所有关心LumaQQ.NET发展的朋友们道个歉，因为距上一次版本更新已经过去了一个多月的时间了，新版本一直迟迟都没有发布。在这段时间里，由于一些个人原因，没有时间和精力投入到新版本的开发当中来，让大家失望了。最近很多人都在问，LumaQQ.NET希望做得什么程度。我目前的定位是：以Lumaqq2005的协议为蓝本，基本能做到简单的文本信息收发功能即可，不打算去分析更新的协议，也不找算做到能基本代替官方QQ的程度，因为我们是定位在机器人开发包的级别。如果有让您失望，还请谅解。关于更详细的开发计划请参考：关于LumaQQ.NET未来开发计划

在Preview 3当中，我们主要增加了群消息的功能（但不包括群管理功能），还修复和完善了之前存在的一些不足和BUG，下面就来简单了解下：

框架完善部分

1. 使用了新的ByteBuffer，可以解决可能存在的内存使用不合理的问题（感谢Red_angelX的提醒和提供这么好的一个类）
2. 完善信息发送接口,可以收发长信息（感谢蓝色的风之精灵的贡献）
   • 关于如何实现收发长信息可以参考蓝色的风之精灵的两篇文章修改LumaQQ.NET，使其支持长消息发送和使LumaQQ.NET支持接收长消息
3. 可以解析默认表情(解析成[face0.gif]等格式,由用户去替换)和自定义表情(文件名) （感谢蓝色的风之精灵的贡献）
   • 关于解析表情同样请参考蓝色的风之精灵的文章关于转换QQ消息中系统表情，自定义表情和截图的函数。与之不同的是，我把默认表情都解析成[face{0}.gif]的格式，大家可以根据需要再去替换。
4. 修复了一些已知的bug，包括之前的天气预报日期问题和QQ注销后程序不退出会出错的问题等。

新增功能部分，主要新功能群信息的功能

1. 得到我加入的群列表。
   • 这个功能需要使用好友管理的读取好友列表的功能，在返回的好友列表中有两种好：普通好友和群好友。大家只要根据定义的类型来判断就可以得到所加入的群列表，如：if(friend.Type == FriendType.IS_CLUSTER)
2. 接收群消息和群通知的功能
   • 这个功能分为几个事件，这些事件的InPacket事件参数类型都为ReceiveIMPacket，但是事件不同，里面的属性字段使用不同，同样的，所有的群操作命回复事件包都是ClusterCommandReplyPacket，但是根据事件不同，这个对象的属性使用不同。请大家仔细查阅ClusterCommandReplyPacket的注释说明。
     • ReceiveClusterIM：接收到群消息事件
     • AddedToCluster:被加入到群通知
     • RemovedFromCluster:被从某个群中移动的通知
     • ApprovedJoinCluster:群管理员同意我加入群的通知
     • RejectJoinCluster：群管理员拒绝的加入群的通知
     • HasRequestedJoinCluster:有人请求加入群的通知
3. 请求加入群功能，这个功能通过JoinCluster接口发送请求，如果返回结果提示需要发送身份验证，则调用RequestJoinCluster来发送验证信息。加入结果则以系统通知（上面的事件）的形式返回。
4. 根据群ID查找群，通过SearchClusterById发送查找群请求。
5. 退出群，通过调用ExitCluster请求退出群。
6. 发送群信息功能，暂不能分包发送长信息。
7. 修改群名片
8. 刷新群内组织架构
9. 得到单个成员和全部群名片信息
10. 得到群资料，群成员列表（QQ号码）
11. 得到在线成员
12. 得到群成员详细信息

以上功能测试基本正常，如果有任何问题或疑问请通过LumaQQ.NET小组交流讨论，同时大家也可以加入LumaQQ.NET QQ群讨论，号码是：22858783 谢谢！

另外，在这里要特别感谢蓝色的风之精灵的热心和贡献，解决了一些疑难问题，希望大家再接再厉一起来完善LumaQQ.NET。

文档和源码下载

更新：增加了for vs 2005的Preview3。  04/24/2008

通过分析Timer组件，我们就很容易发现，他们都是通过ThreadPool这个类的功能来实现定时器的功能。ThreadPool类，提供了对当前进程内的后台线程统一管理，集中调配和资源重用的线程池实现。利用ThreadPool可以实现任务的延迟处理，I/0 异常操作，线程间的互斥执行，定时任务等功能。

ThreadPool提供了一系列管理和维护线程池的接口。在LumaQQ.NET中，我需要的功能就是利用：QueueUserWorkItem 和RegisterWaitForSingleObject 这两个接口来实现的。

QueueUserWorkItem :让我们可以注册一个排队的异步任务，等到线程池有剩余的线程资源时去异步执行任务。

RegisterWaitForSingleObject :让我们可以注册一个等待信号就绪的异步任务，等到该线程等待的信号就绪后异步执行该任务。这个接口等待信号是一个WaitHandle对象，同时还可以指定等待超时（间隔时间），而通过设置executeOnlyOnce参数的值可以指定是否重复执行该任务。

了解了ThreadPool的基本情况后，我们就可以来设计我们的异步线程执行框架。首先对异步任务和间隔任务，我们分别定义了两个接口ICallable和IRunable来描述：

   1: /// <summary>

   2: /// 可以被提交到线程池异步处理的接口

   3: ///     <remark>abu 2008-03-07 </remark>

   4: /// </summary>

   5: public interface ICallable

   6: {

   7:     /// <summary>

   8:     /// 是否已经在运行

   9:     ///     <remark>abu 2008-03-07 </remark>

  10:     /// </summary>

  11:     /// <value></value>

  12:     bool IsRunning { get; }

  13:     /// <summary>

  14:     /// WaitCallback回调

  15:     ///     <remark>abu 2008-03-07 </remark>

  16:     /// </summary>

  17:     /// <param name="state">The state.</param>

  18:     void Call(object state);

  19: }

  20: /// <summary>

  21: /// 可以被提交到线程池定时运行的接口

  22: ///     <remark>abu 2008-03-07 </remark>

  23: /// </summary>

  24: public interface IRunable : IDisposable

  25: {

  26:     /// <summary>是否已经在运行

  27:     ///     <remark>abu 2008-03-07 </remark>

  28:     /// </summary>

  29:     /// <value></value>

  30:     bool IsRunning { get; }

  31:     /// <summary>

  32:     ///     <remark>abu 2008-03-07 </remark>

  33:     /// </summary>

  34:     /// <param name="state">The state.</param>

  35:     /// <param name="timedOut">if set to <c>true</c> [timed out].</param>

  36:     void Run(object state, bool timedOut);

  37:     /// <summary>

  38:     /// 注册在线程池后的信号变量

  39:     ///     <remark>abu 2008-03-07 </remark>

  40:     /// </summary>

  41:     /// <value></value>

  42:     WaitHandle WaitHandler { get; set; }

  43:     /// <summary>

  44:     /// 注册后的对象

  45:     ///     <remark>abu 2008-03-07 </remark>

  46:     /// </summary>

  47:     /// <value></value>

  48:     RegisteredWaitHandle RegisterdHandler { get; set; }

  49: }

之后，我们需要定义一个任务注册类，来管理异步任务的注册的提交工作，这个类我将它命名为：ThreadExcutor

   1: /// <summary>

   2: /// 利用线程池来异步执行线程

   3: ///     <remark>abu 2008-03-07 </remark>

   4: /// </summary>

   5: public class ThreadExcutor

   6: {

   7:     /// <summary>提交一个线程等待执行

   8:     ///     <remark>abu 2008-03-07 </remark>

   9:     /// </summary>

  10:     /// <param name="callable">The callable.</param>

  11:     /// <param name="state">The state.</param>

  12:     public static void Submit(ICallable callable, object state)

  13:     {

  14:         if (!callable.IsRunning)

  15:         {

  16:             ThreadPool.QueueUserWorkItem(new WaitCallback(callable.Call), state);

  17:         }

  18:     }

  19:     /// <summary>

  20:     /// 注册一个轮循线程

  21:     ///     <remark>abu 2008-03-07 </remark>

  22:     /// </summary>

  23:     /// <param name="runnable">The runnable.</param>

  24:     /// <param name="state">The state.</param>

  25:     /// <param name="interval">The interval.</param>

  26:     public static void RegisterIntervalObject(IRunable runnable, object state, long interval, bool onlyOnce)

  27:     {

  28:         // if (runnable.RegisterdHandler == null)

  29:         // {

  30:         runnable.WaitHandler = new AutoResetEvent(false);

  31:         runnable.RegisterdHandler = ThreadPool.RegisterWaitForSingleObject(runnable.WaitHandler, new WaitOrTimerCallback(runnable.Run), state, interval, onlyOnce);

  32:         // }

  33:     }

  34: }

实际上这个类，只是将传入ICallable和IRunable对象，注册到线程池当中来，而运行时机则由线程池去管理和分配。接下来就是实际的任务设计了，在LumQQ.NET中目前有三个这种的任务：

PacketIncomeTrigger：异步处理输入包。只有等到有收到数据后，才提交这个任务，在后台线程中去处理QQ事件。一次处理会全部处理所有已收到的输入包，处理完后退出。当包处理线程正在运行时，试图注册相同任务将自动不会被注册。

KeepAliveTrigger：定时执行发送在线包的任务，它实现的就是Timer组件的功能。

ResendTrigger：这是一个不定时执行的间隔线程。重复发送包，保证每一次重得发送包都是顺序执行的，而不希望同时可能执行多个重复发送包线程，而且下一次的执行时间也是动态的。要实现这个功能我们只需要在注册等待线程时指定合适的超时时间和executeOnlyOnce为true(只执行一次)，等到任务执行结束后，再重新注册一次定时线程。这样就可以完善解决不定时的间隔线程问题了。

更多详细的功能实现请参考LumaQQ.NET中的相关代码。

阿不

记得前不久，在园子里有这样的一篇文章，介绍了几种WEB环境定时刷新数据的机制。其中就有提到google gmail的一种比较巧妙的做法，现在记不得当时是怎么理解这种做法了，只记得有“保持长连接”的基本做法。（当然现在也找不到这篇文章了，希望了解的朋友能提醒一下）。今天由于架构方案的需要，再来仔细思考连接保持方案，以及参考gmail的请求行为，总结了一下，应该是这样的：客户端一直保持一个与服务器的连接，这个连接一直保持着对服务器的请求动作，直到服务器发现有数据后给它返回后，才结束返回这一次请求。客户端在接收到请求返回后，在处理这些返回之前，又向服务器发送了一次连接请求，直到下一次有数据返回。不可避免的有一种情况，就是如果服务器长时间没有需要给客户端发送数据的话，那么可以就会造成请求失败（超时或其它原因）。对于这种情况的处理也是一样的，在错误的回调事件中重新发送一次请求连接。这样就可以模拟保持连接状态了。

用伪代码来描述一下思路吧：

客户端脚本：

   1: function Request()

   2: {

   3:     Ajax.Request(url,OnSuccessed,OnFailed);

   4: }

   5: function OnSuccessed(response)

   6: {

   7:     //重新发送一次请求

   8:     Request();

   9:      //处理返回数据

  10: }

  11: function OnFailed()

  12: {

  13:     //错误（超时）重新请求

  14:     Request();

  15: }

Web服务：

   1: public class IMService : IHttpHandler

   2: {

   3:     public bool IsReusable{return false;}

   4:     public void ProcessRequest(HttpContext context)

   5:     {

   6:         //读取最新数据

   7:         while(true)

   8:         {

   9:             string message = GetMessage();

  10:             if(!string.IsNullOrEmpty(message))

  11:             {

  12:                 context.Response.Write(message);

  13:                 break;

  14:             }

  15:             Thread.Sleep(500);//等待一段时间再重新读取。

  16:         }

  17:     }

  18:     private string GetMessage()

  19:     {

  20:         //取得最新数据

  21:     }

  22: }

这种方案的好处有：客户端可以第一时间得到服务器需要给客户端发送的数据（而至于Web服务怎么知道要给客户端发送数据，也就是服务器的轮循设计，则是另一个需要考虑的方案）；可以减化客户端逻辑，无需要创建和释放定时器，并减小由此产生的对客户端性能的损失；减少去服务器的请求次数，减少做无用功，节约节省带宽和减少服务器资源需要处理的连接请求。

相信在此之前，已经有很多人在使用这种方案了。欢迎大家就此方案发表自己的见解。

补充：服务器部分的设计，除了使用轮循外，也可以考虑使用资源互斥访问的方式来设计，这样做可以获得更佳性能，更高实时性，具体的方案应当根据实际情况来考虑。相关的设计可以参考Cat Chen的文章《使用 .NET 实现 Ajax 长连接 (Part 2 - Mutex Wait & Signal)》

我个人挺看重MVP这个荣誉的，因为我刚刚入门的时，就从广大的MVP专家那里学到了很多东西，那时就梦想有朝一日我也能成为这MVPs中的一员，也能为.NET社区做出自己的贡献。一直以来，我都在不屑努力的提高着自己，也慢慢看到了自己的进步，在工作中，我的努力慢慢得到了认可。而当选MVP，则是社区力量对我最大的鼓励。技术的追求永无止境，毕业即将4年（学习使用.NET3年半的时间），4年只是我的一个开始。接下来技术生涯中，我还希望能保持对技术的热情，不断追求和探索，力争在技术上取得更大的进步。

在这里，还不得不感谢博客园，感谢dudu，感谢园子里所有帮助和关心过我的朋友们。大家的支持和鼓励是我不断取得进步不可缺少的力量，我也将尽自己最大的努力，在以后的日子里做出更多力所能及的贡献。同时也祝贺本次当选的其他MVP们，以后有机会一定向大家多多学习。

PS.今天是愚人节,希望不是被微软给愚了...