=== Program that uses StreamReader [C#] ===
using System;
using System.IO;
class Program
{
static void Main()
{
//
// It will free resources on its own.
//
string line;
using (StreamReader reader = new StreamReader("file.txt"))
{
line = reader.ReadLine();
}
Console.WriteLine(line);
}
}
=== Program that uses Dispose [C#] ===
using System;
using System.IO;
class Program
{
static void Main()
{
//
// Read a line from a file the old way.
//
StreamReader reader = new StreamReader("file.txt");
string line = reader.ReadLine();
reader.Close();
// You should call Dispose on 'reader' here, too.
reader.Dispose();
Console.WriteLine(line);
}
}
Why use using? 参照http://ryanfarley.com/blog/archive/2004/03/18/447.aspx 中作者解释
Even without understanding MSIL, you can clearly see what is going on here. The code was essentially translated to a try/finally block calling Dispose in the finally. If I were to take this same IL and convert it back to C# using Reflector then it would be exactly that, a try/finally block where Dispose is called in the finally.
So why use using at all? If all using does is translate to a try/finally block then why would you want to use it? Well, as I said at the beginning, it really does come down to a matter of preference. I think the code is more elegant but others may not and that is OK. However, take any peice of code that does not use using and tell me that Dispose is being called without looking in the finally block. You can't. There's no way you can guarantee that Dispose is being called without looking in the finally block to see. With using, there's nothing to look at. You know it is being called. You know that there's no way you could have forgotten to call Dispose and left some references to unmanaged resources out there somewhere. You know this because it is done automatically for you - and I think that is just cool.
To finish things up, it is important to understand that since the purpose of using is to create a scope for an object where Dispose is automatically called upon leaving the scope that this requires that the object actually implements IDisposable. Using an object that does not implement IDisposable will result in an error, just as manually calling Dispose for the object in a finally block would result in an error. For a list of objects in the framework that implement IDisposable you can look at the IDisposable definition in the docs. However, with that said, you should also implement IDisposable in your own classes that use unmanaged resources such as interop etc.
google翻译
即使不理解的MSIL,你可以清楚地看到这里发生了什么。该代码基本上转化为一个try / finally块中调用最终处置。如果我要采取同样的IL和它转换到C#中使用反射镜,然后便正是这样一个try / finally块丢弃在这里终于被调用。
那么,为什么用使用呢?如果全部采用所做的是翻译成一个try / finally块那你为什么要使用它?嗯,正如我在开始时说,它确实可以归结为一个见仁见智的问题。我认为代码更优雅,但其他人可能不会,这是确定。但是,采取任何的代码使用和不使用没有告诉在finally块找我,被调用Dispose的一块。你不能。有没有办法可以保证不被丢弃在finally块来看看寻找调用。与使用,有什么可看。你知道这是被调用。你知道,有没有你可能忘记调用Dispose,离开那里有些地方的非托管资源的引用方式。你知道这是因为它是为您自动完成 - 我认为这只是冷静。
要完成的事情了,重要的是要明白,自从使用目的是建立一个为在离开时自动Dispose的范围,这需要该对象实际实现IDisposable称为对象的范围。使用对象不实现IDisposable将导致一个错误,就像手动finally块中调用该对象的Dispose将导致错误。如需在框架中实现IDisposable对象的列表,你可以看看在docs IDisposable接口的定义。然而,随着中说,你也应该在自己的类实现IDisposable接口,使用非托管资源互操作等,
Server.MapPath() 探究 (转)
Server.MapPath(path)
The MapPath method maps the specified relative or virtual path to the corresponding physical directory on the server.
Parameters (MSDN:ms-help://MS.MSDNQTR.2003FEB.2052/iisref/htm/ref_vbom_serommp.htm)
用法:
1.Server.MapPath("/") 应用程序根目录所在的位置 如 C:\Inetpub\wwwroot\
2.Server.MapPath("./") 表示所在页面的当前目录
注:等价于Server.MapPath("") 返回 Server.MapPath("")所在页面的物理文件路径
3.Server.MapPath("../")表示上一级目录
4.Server.MapPath("~/")表示当前应用级程序的目录,如果是根目录,就是根目录,如果是虚拟目录,就是虚拟目录所在的位置 如:C:\Inetpub\wwwroot\Example\
注:等效于Server.MapPath("~")。
不知道是否正确,研究中......
另:以下几句等效
string filename=Server.MapPath("./") + @"\Web.config";
string filename=Server.MapPath("./") + "/Web.config";
string filename=Server.MapPath("") + @"\Web.config"
附一例子:修改web.config的某一节点的属性值
public void write()
{
string key1 = this.TextBox1.Text;
DataSet ds = new DataSet();
ds.ReadXml(Server.MapPath("")+"/web.config");
// 不是Tables[0]
ds.Tables[1].Rows[0][1] = key1;
ds.AcceptChanges();
ds.WriteXml(Server.MapPath("")+"/web.config");
ds.Dispose();
}