摘要:.Net Framework 1.1 SP1:http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=A8F5654F-088E-40B2-BBDB-A83353618B38.Net Framework 1.1 SP1 for Win2003:http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=AE7EDEF7-2CB7-4864-8623-A1038563DF23.Net Framework 1.0 SP3:http://www.microsoft.com/downloads/details.aspx?familyid=6978D761-4A92-4106-A9BC-83E78D4ABC5B&displaylang=en最后是一些.Net Framework 2.0 Beta1的一些Code Samples:http://www.microsoft.com/downloads/details.aspx?familyid=c3c41e75-f8a8-4077-84cf-e43176d93b1e&displaylang=en另外，大家都知道，MS已经决定让Avalon和Indigo能运行在WinXP和Win2003上了，并且在Longhorn的发行版本中去掉了WinFS（以后以类似Add-on的形式提供）。我在网上见得最多的问题就是：既然Avalon和Indigo已经可以在WinXP上使用了，而Longhorn里面又没有了WinFS，那我们还有什么理由非将自己的WinXP升级到Longhorn呢？嗯，真是有意思的问题......[阅读全文]

摘要:在上期的《程序员》杂志上，记得有一篇板桥里人写的Java相关的开篇，文章里面讲到，SOA is NOT Web Services。William Zentmayer在一篇Blog《Doing SOA without Web Services? I'm skeptical.》中表达了自己的观点，那就是虽然很多人都认为SOA并不就意味着Web Services，但是离开了Web Services的SOA几乎没有“价值”可言。这篇文章后面的留言对作者的观点进行了“无情的”驳斥，留言者都认为SOA是比Web Services更为广泛的概念，在以往（甚至先于Web Services的出现）的被开发出的系统之中，就已经可以看到SOA的存在了。在作者随后的《Doing SOA without Web Services? Part II》中，他虽然为自己先前的观点进行了辩护（理由是，如果考虑SOA必须要满足异构系统间的通讯，就必须使用一种业界公认的标准协议来进行通讯，即SOAP和Web Services），但还是接受了SOA更加倾向于是一种Messaging System的观点。MSDN上有一篇很棒的文章，《Messaging Patterns in Service-Oriented Architecture, Part 1》，介绍了SOA中出现的各种Messaging Patterns。比如，Messaging System很自然被理解成传递Message的系统，那么在这个系统中如何实现用Messaging Patterns调用远程系统的一个方法呢？答案就是“Command Message Type Pattern”。另外，对于上面这个问题，九月份的MSDN Magzine上面的一篇《Simplify Distributed System Design Using the Command Pattern, MSMQ, and .NET》也是属于极力推荐的文章。...[阅读全文]

摘要:Borland Conference 2004下月即将在加州圣何塞开幕，在BorCon04上，预计将有大量关于Delphi9的信息被“爆出”。Borland一直希望自己能在.NET开发平台领域占有一席之地，可惜Delphi8只能用“半成品”来形容，几乎没有吸引到太多的.NET开发人员，也造成了大量的Delphi Win32的开发人员仍然停留在Delphi5、6、7版本上，对是否进入.NET平台而犹豫不决。另外的那个C# Builder也是反映平平，毕竟C#程序员很少会不直接使用VC#的。现在Borland对Delphi9充满了信心，相信它会是一个“跨时代”的产品。下面是我从Borland站点、Borland员工的Blog和李维的论坛上所获得的一些关于Delphi9的信息：1、D9的CodeName叫做“Diamandback”。2、D9基于.Net Fx 1.1，预计将在今年年底正式推出，现在D9处于Beta1阶段。根据李维的说法，这个Beta1版本的稳定性非常好，甚至好过D8 SP3！！（从侧面证明了D8的稳定性的确是差...）3、D9同时支持.NET平台和Win32平台的程序开发，并同时支持Delphi、C#、VB.NET语言。D9可以自动的对Win32的程序生成相应的Wrapper，以让.NET程序可以直接调用。就是说，一个大的解决方案可能包括一个Delphi Win32 dll项目、一个C# .Net dll项目，一个Delphi .Net WinForms项目...4、D9内置了单元测试、建模、重构工具，看起来很强。5、对ECO（Enterprise Core Object）进行了加强，可以支持ASP.NET项目了。我一直认为ECO是D8（和C#Builder）里面最有价值、最Cool的东东！如果ECO可以单独提取出来，在VS.NET中间使用就好了...如果D9果真能够达到Borland所承诺的那样，具有强大功能（和VS2003比）的同时，具有很好的稳定性，那么D9的确将会是一个值得期待的开发平台。即使从对Object Pascal语言不感兴趣的.NET程序员的角度，在D9里面使用C#进行开发也令人很有兴趣。:)...[阅读全文]

摘要:前两天做了一个小东西，包装了一下ViewState的存储，实现将页面的ViewState保存到我们指定的地点。关于ViewState的原理已经如何进行这样的修改，可以参看以前我的一篇Blog上面的内容。Kaneboy.Web.ViewState内置了三种存储ViewState的方式，保存在Session中、压缩后保存在页面上的Hidden Field中，以及按照ASP.NET 1.1所实现的那样，直接保存在Hidden Field中。通过查看其源码，你可以更深入的了解ViewState的知识。根据我的使用试验，在有DataGrid或类似控件的页面上，使用内置的ViewState压缩方式就可以大大的缩小页面的体积。详细的使用说明在这里，通过阅读说明，你就可以大致了解它。源码在这里。...[阅读全文]

摘要:“源码是最好的文档”，有了源码，任何软件系统在开发人员面前就毫无“神秘”可言了...今天需要做一个上传文件的Web页面，在调用HttpPostedFile.SaveAs(String filename)方法将文件写到服务器磁盘上时，想到如果此文件已经存在于磁盘上，这个方法会如何处理呢？直接覆盖？抛出异常？翻一下.NET Framework文档，可惜里面没有对这个情况进行说明。于是进入Mono源码目录，定位到HttpPostedFile.cs文件，用记事本打开，找到SaveAs(String filename)方法，第一句就是：FileStream File = new FileStream(filename, FileMode.Create);OK，确切答案就是如果已经存在同名文件会直接覆写。我猜一定有人会想，“万一Mono的实现和.Net Framework不同怎么办？”其实我过后就这么想了，于是用Reflector打开了System.Web.dll，定位这个方法，呵呵，.Net Framework的实现也是“FileMode.Create”。不过.Net Framework使用了一个try...catch来保证关闭这个FileStream，而Mono的实现里面则没有，嗯，这是不是意味着Mono的稳定性仍有不少改进之处呢？...[阅读全文]

摘要:在拿到一个Assembly文件（.dll、.exe）的时候，如何才能迅速判断这个文件是使用Debug模式还是Release模式编译出来的呢？在项目的AssemblyInfo.cs文件中，使用这样一个技巧：#if DEBUG[assembly: AssemblyDescription("Debug")]#else[assembly: AssemblyDescription("Release")]#endif编译出来Assembly文件以后，只要直接察看文件的属性，就可以看出来了：如果要在程序中取得这个信息，可以使用：Object[] attrs = System.Reflection.Assembly.GetExecutingAssembly().    GetCustomAttributes(typeof(AssemblyDescriptionAttribute), false);if (attrs.Length > 0){    String sCompMode = (attrs[0] as AssemblyDescriptionAttribute).Description;}来得到这个信息。Source : http://weblogs.asp.net/tgraham/archive/2004/06/16/157545.aspx补充：Lostinet说出可以使用“System.Diagnostics.DebuggableAttribute”这个Attribute来判断一个Assembly是否是Debug模式编译的。但是，在这里C# 1.1编译器有一个“Bug”：不管当前的Assembly是否是Debug模式编译的，C# 1.1的编译器csc.exe都会给Assembly加上“System.Diagnostics.DebuggableAttribute”，而指定“/optimize”参数时，csc.exe才不加。就是说，我们即使不启用Debug来进行编译：“csc some.cs /debug-”，也会给编译出来的Assembly加上DebuggableAttribute；“csc some.cs /debug- /optimize”，这样才不会加上DebuggableAttribute。但是，幸运的是，VS.NET开发环境只要是Release模式编译，都会自动给csc.exe加上“/optimize”参数，所以...从这点上来讲，只要Assembly是在VS.NET里面编译的，这个方法还是有效的。...[阅读全文]

摘要:Enterprise Development Reference Architecture（EDRA），也就是以前的ShadowFax，在6月份已经发布了正式的1.0版本，现在项目正处在1.1的开发阶段（已经发布了一个1.1测试版本）。嗯，先解释一下Enterprise Development Application Framework，EDAF是这个项目提供的一个企业级开发平台和框架，开发人员可以基于EDAF来进行企业级应用的开发。EDRA则是对使用EDAF进行开发的一个参考、描述、规范...先看看EDRA的Architecture Overview图片：EDRA可以算是非常典型的SOA架构。可以看到图上被分为了两大块，Service Interface和Service Implementation，根据名字我们就能够大致猜出它们各自的作用和地位。在实际的应用中，我们通常可以将Interface和Implementation部署到不同的Tier，以获得更好的扩展性。我们根据这张图来从上往下的走一遍吧。:)首先，Client App发出一个Request给Service Interface，这个Request可以是多种协议的，WebServices、MSMQ、Remoting，每种协议都对应一个Interface Transport，Transport负责接受Request，并传递给各自对应的Adapter。Adapter对于Request可以做出一些初始化的处理，比如安全验证什么的，然后，Adapter会创建一个Context对象，将这个Request放在Context对象里面，然后将Context对象传递给Service Interface里面的Pipeline。Pipeline是一个配置性很高的组件，它根据配置文件，来载入各种Handler，包含了Request内容的Context对象就依次被这些载入了的Hander处理、传递，并最终到达一个Interface Pipeline Target，这个Pipeline Target是一个Dispatching Target，它可以根据配置，使用不同的协议将Context传递给Service Implement部分（Web Service、MSMQ、DCOM、或者Inproc直接调用）。Context首先到达的也是Service Implement部分的Dispatching Transport（类似Service Implement，也有多种Transport来接收多种协议的请求），每个Transport同样有一个Adapter，然后Adapter创建出Pipeline，将Context传进去。Context在Service Implementation的Pipeline里面做得事情和前面差不多。最终，Context到达了一个Business Action Target，这个Target负责调用“真正”的Business Action。Business Action根据包含在Context中的Request执行相应的操作，然后生成一个Response，将这个Response放进Context里面，然后将Context返回给Business Action Target。Context对象沿着来时的路线又一路返回，返回的路上也可能被经过的各个Handler进行一些处理，最后，Context返回到了创建它的Interface Transport Adapter。Adapter这时需要查看Context中是否包含了异常信息，并分辨异常信息是属于业务逻辑执行上的异常还是EDAF本身所产生的系统异常，如果是前者，将被直接返回给Client App，如果是后者，则进行一些Log或者其他操作后，返回一个包装好的安全的错误信息给Client App。在EDRA的主页上，同时还提供了一个Global Bank Reference Implementation，使用EDRA来构建的一个银行系统的示范项目。EDRA Wiki上也有不少有意思的内容。最后，如果对这样的架构和框架感兴趣，那么还可以去看看微软的另外一个项目：FABRIQ，FABRIQ是一个高性能的的、单向的、基于队列的一个Messaging Architecture实现。...[阅读全文]

摘要:昨天网上一位朋友推荐我看了一篇文章《Remote Scripting in .NET》，这篇文章的作者利用了Microsoft Remote Scripting技术，在服务器端进行了一些封装，方便了在ASP.NET中的页面上调用直接调用服务器端方法。说起来我以前对Microsoft Remote Scripting还是挺陌生的，MRS的原理是利用了内置的一个Java Applet，通过一些高层的封装，使页面上使用Script能够直接调用服务器上公开的方法。感兴趣的朋友可以看看MSDN上的文档，用起来还算是方便，特别是配合前面那篇文章作者做的那个封装的.NET组件。不过我个人对Applet并不是很感冒，特别是在我家里的那台没有安装JRE的WinXP SP2RC2的机器上更是根本没法用...其实我最喜欢的还是ASP.NET 2.0中的Script Callback那样的实现方式，简单、明了，于是想到，既然它也是底下使用XMLHTTP来实现的，那不如我自己在ASP.NET 1.1下面也照样用XMLHTTP实现一个好了。花费了一阵功夫，大功告成。大部分都是仿造的ASP.NET 2.0中的实现方式，但是部分地方还是不能做到完全一样，因为对于实现ICallbackEventHandler接口的控件的处理，我没法直接写到Page类或更里面的地方，所以需要在页面里面创建一个ScriptCallbackManager的控件。服务器端的进行步骤：1、让页面上的某个控件实现ICallbackEventHandler接口，我个人喜欢就让Page类直接实现；2、在实现了ICallbackEventHandler接口的控件上实现RaiseCallbackEvent方法，来处理客户端的请求；3、在页面中加入一个ScriptCallbackManager控件，在构造函数中指明实现了ICallbackEventHandler接口的控件，和调用完成后执行客户端的Script函数名。public class WebForm1 : System.Web.UI.Page, ICallbackEventHandler{    private void Page_Load(object sender, System.EventArgs e)    {        this.Controls.Add(new ScriptCallbackManager(this, "handleResultFromServer"));    }     public String RaiseCallbackEvent(String eventArgument)    {        return "You sent " + eventArgument + " !";    }页面上的进行步骤：1、在需要调用服务器方法的地方直接调用内置的scriptCallback()函数，第一个参数指定了要传递到服务器端的变量，第二个参数指定了此次请求的上下文；2、编写一个在完成调用之后自动执行的函数，这个函数的名称需要和服务器端ScriptCallbackManager控件的构造函数中指定的函数名称相同。function callBack(){    var param = document.all.txtRequest.value;    var context = "";        scriptCallback(param, context);} function handleResultFromServer(result, context){    alert(result);}在callBack()方法中调用了系统内置的一个Script函数scriptCallBack()，这个函数会自动调用服务器方法，并将第一个参数的值传给服务器端的RaiseCallbackEvent()方法的参数。handleResultFromServer是在调用完成后自动执行的函数。感兴趣的朋友可以在这里下载到这个Script Callback实现的项目源码。...[阅读全文]