C#的foreach语句是从do，while，或者for循环语句变化而来的，它相对要好一些，它可以为你的任何集合产生最好的迭代代码。它的定义依懒于.Net框架里的集合接口，并且编译器会为实际的集合生成最好的代码。当你在集合上做迭代时，可用使用foreach来取代其它的循环结构。检查下面的三个循环： 对于当前的C#编译器(版本1.1或者更高)而言，循环1是最好的。起码它的输入要少些，这会使你的个人开发效率提提升。(1.0的C#编译器对循环1而言要慢很多，所以对于那个版本循环2是最好的。) 循环3，大多数C或者C++程序员会认为它是最有效的，但它是最糟糕的。因为在循环外部取出了变量Length的值，从而阻碍了JIT编译器将边界检测从循环中移出。 C#代码是安全的托管代码里运行的。环境里的每一块内存，包括数据的索引，都是被监视的。稍微展开一下，循环3的代码实际很像这样的：…
在用 ASP.Net 开发页面的时候，我们常常通过 System.Web.HttpUtility.UrlEncode 和 UrlDecode 在页面间通过 URL 传递参数，成对的使用 Encode 和 Decode 是没有问题的。 但是，我们在编写文件下载的页面的时候，常常用如下方法来指定下载的文件的名称： 之所以转换成 UTF8 是为了支持中文文件名。 这时候问题就来了，因为 HttpUtility.UrlEncode 在 Encode 的时候，将空格转换成加号(+)，在 Decode 的时候将加号转为空格，但是浏览器是不能理解加号为空格的，所以如果文件名包含了空格， 在浏览器下载得到的文件，空格就变成了加号(dnawo注：还是能成功下载的，只是原本文件名中的空格下载到本地后成了加号)。…
Close() and Dispose() are basically the same thing on an ADO.NET connection object for providers shipped by Microsoft, and typically for 3rd party providers as well (haven't seen one that does it differently, but you never know :). The only difference is that Dispose also clears the connection string. Calling only 1 of them is enough - whichever you prefer or applies…
Default.aspx： upload.ashx： 最后，web.config中configuration增加以下节点： 完成！点击下载示例 SWFUpload官方站点：http://swfupload.org/ SWFUpload源码下载：http://swfupload.googlecode.com/
几天前无意中写了这么两个函数： 今天看了就有这么一个疑问：当传两个string类型参数时哪个函数会被调用？用事实说话吧： 显然，后者的优先级比前者高，那前者的params参数就没有意义了，正确的函数定义：
.NET学生类Student： 序列化和反序列化 //引入命名空间 using Newtonsoft.Json; using Newtonsoft.Json.Converters; 1).序列化 2).反序列化 点击下载Newtonsoft.Json
这是本书中唯一一个被一整个函数占用的原则，你应该避免写这样的函数。GetHashCode()仅在一种情况下使用：那就是对象被用于基于散列的集合的关键词，如经典的HashTable或者Dictionary容器。这很不错，由于在基类上实现的GetHashCode()存在大量的问题。对于引用类型，它可以工作，但高效不高；对于值类型，基类的实现经常出错。这更糟糕。你自己完全可以写一个即高效又正确的GetHashCode()。没有那个单一的函数比GetHashCode()讨论的更多，且令人困惑。往下看，为你解释困惑。 如果你定义了一个类型，而且你决不准备把它用于某个容器的关键词，那就没什么事了。像窗体控件，网页控件，或者数据库链接这样的类型是不怎像要做为某个任何的关键词的。在这些情况下，什么都不用做了。所有的引用类型都会得到一个正确的散列值，即使这样效率很糟糕。值类型应该是恒定的(参见原则7)，这种情况下，默认的实现总是工作的，尽管这样的效率也是很糟糕的。在大多数情况下，你最好完全避免在类型的实例上使用GetHashCode()。 然而，在某天你创建了一个要做为HashTable的关键词来使用的类型，那么你就须要重写你自己的GetHashCode()的实现了。继续看，基于散列(算法)的集合用散列值来优化查找。每一个对象产生一个整型的散列值，而该对象就存储在基于这个散列值的“桶”中。为了查找某个对象，你通过它的散列值来找到这个(存储了实际对象的)“桶”。在.Net里，每一对象都有一个散列值，它是由System.Object.GetHashCode()断定的。任何对GetHashCode()的重写都必须遵守下面的三个规则：…
以前曾经动笔写过一片《字符串比较方法的性能对比》的文章，很多朋友提出了非常好的意见和建议。碰巧最近看到好多人在这样比较字符串 似乎很有意思，大家都喜欢另辟蹊径的使用字符串比较，为了较为客观的反应各种字符串比较的优势，我特地做了一个本地测试，分别区分字符串长度一致以及长度不一致的情况，另外每种情况下还对字符串的比较方式上使用4种不同方法： 1、使用地球人都知道的“==”比较运算符 2、使用String.Compare方法，即上面提到的代码 3、使用string.Equals(string,StringComparison.Ordinal)方法 4、使用string.Equals(a, b, StringComparison.OrdinalIgnoreCase)方法…
最近比较关注C#书写出来的代码性能问题，越研究就越觉得很有意思。 在日常的编程过程总，由于编程需要，我们经常会比较两个字符串是否相等，然后再做相应的处理。代码书写起来是觉得很爽，不是吗？if (a==b) then ……else……但是有没有更快的方式呢？为此查阅了一些资料了MSDN文档。当我们调用 a==b的时候，通过IL代码可以看到内部实际上调用了String.Equals(string,string)这个方法 更为严重的是更底层调用的是EqualsHelper辅助方法，它首先比较两个字符串的长度，然后逐个字符的通过引用指针的方式进行比较，由于无法明确的区隔是否和语言别有关系，内部处理异常复杂。有没有更快速的方法呢？…
默认在ashx中是不能正常使用Session的(能存入不能取出)，查阅相关文档，说明只有实现IRequiresSessionState接口后ashx才能正常使用Session，代码如下：