方法 1
使用 x509 证书 类来读取该证书从一个.cer 文件，然后设置 ClientCertificates 属性。方法 2
使用 CryptoAPI 调用来获得证书从证书存储区，然后将 x509 证书 类设置为您接收到来自证书存储区的证书。然后，您可以设置 ClientCertificates 属性。发送客户端证书的要求
在使用 ASP.NET 应用程序，请确保完成以下要求：- LOCAL_MACHINE 注册表配置单元中，而不是在 CURRENT_USER 注册表配置单元，必须安装客户端证书。若要确认客户端证书的安装位置，请按照下列步骤操作：
- 单击 开始、 单击 运行，键入 mmc，然后单击 确定。
- 在 文件 菜单上单击 添加/删除管理单元。
- 在 添加/删除管理单元 对话框中单击 添加。
- 在 添加独立管理单元 对话框中单击 证书，然后单击 添加。
- 在 证书管理单元 对话框中单击 计算机帐户，然后单击 下一步
- 选择计算机 对话框中单击 完成。
- 在 添加独立管理单元 对话框中单击 关闭，然后单击 确定。
- 展开 证书 （本地计算机），展开 个人，然后单击 证书。
- 您必须授予 ASP.NET 用户私人密钥以便客户端证书的帐户权限。若要为 ASP.NET 用户帐户权限的客户端证书的私钥，使用 $ WinHttpCertCfg.exe 工具。有关详细的信息请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
823193 (http://support.microsoft.com/kb/823193/ ) 如何获得 Windows HTTP 5.1 证书和跟踪工具有关如何使用此工具，请访问下面的 Microsoft 开发人员网络 (MSDN) 的网站的详细信息：WinHttpCertCfg.exe，证书配置工具 http://msdn2.microsoft.com/en-us/library/aa384088.aspx (http://msdn2.microsoft.com/en-us/library/aa384088.aspx)
使用.cer 文件
方法 1 会更易于使用，但方法要求您拥有一个.cer 文件。如果您没有安装的.cer 文件，使用 Microsoft Internet 资源管理器导出.cer 文件。
下面的源代码介绍如何获取证书的.cer 文件可以使用与 HttpWebRequest class.
//WebProxy proxyObject = new WebProxy("Your Proxy value",true);
//GlobalProxySelection.Select = proxyObject;
// Obtain the certificate.
try
{
//You must change the path to point to your .cer file location.
X509Certificate Cert = X509Certificate.CreateFromCertFile("C:\\mycert.cer");
// Handle any certificate errors on the certificate from the server.
ServicePointManager.CertificatePolicy = new CertPolicy();
// You must change the URL to point to your Web server.
HttpWebRequest Request = (HttpWebRequest)WebRequest.Create("https://YourServer/sample.asp");
Request.ClientCertificates.Add(Cert);
Request.UserAgent = "Client Cert Sample";
Request.Method = "GET";
HttpWebResponse Response = (HttpWebResponse)Request.GetResponse();
// Print the repsonse headers.
Console.WriteLine("{0}",Response.Headers);
Console.WriteLine();
// Get the certificate data.
StreamReader sr = new StreamReader(Response.GetResponseStream(), Encoding.Default);
int count;
char [] ReadBuf = new char[1024];
do
{
count = sr.Read(ReadBuf, 0, 1024);
if (0 != count)
{
Console.WriteLine(new string(ReadBuf));
}
}while(count > 0);
}
catch(Exception e)
{
Console.WriteLine(e.Message);
}
//Implement the ICertificatePolicy interface.
class CertPolicy: ICertificatePolicy
{
public bool CheckValidationResult(ServicePoint srvPoint,
X509Certificate certificate, WebRequest request, int certificateProblem)
{
// You can do your own certificate checking.
// You can obtain the error values from WinError.h.
// Return true so that any certificate will work with this sample.
return true;
}
}
使用 CryptoAPI 调用
如果您必须获取该证书从证书存储区，CryptoAPI 函数用于获取该的证书，然后将其存储在 x509 证书 的类对象。X509CertificateCollection 类枚举存储区中的所有证书，然后将其置于 X509CertificateCollection 类对象中。如果您要获取某个特定证书，必须更改类代码使用 CertFindCertificateInStore 函数获取特定的证书。此函数被声明 Wincrypt.h 文件中。 或者，您可以枚举 X509CertificateCollection 函数来查找所需的证书。
下面的代码示例使用从 CertEnumCertificatesInStore 函数返回的集合中的第一个证书
using System.Net;
using System.IO;
using System.Text;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Runtime.InteropServices;
namespace SelectClientCert
{
/// Sample that describes how how to select client cetificate and send it to the server.
class MyCerts{
private static int CERT_STORE_PROV_SYSTEM = 10;
private static int CERT_SYSTEM_STORE_CURRENT_USER = (1 << 16);
///private static int CERT_SYSTEM_STORE_LOCAL_MACHINE = (2 << 16);
[DllImport("CRYPT32", EntryPoint="CertOpenStore", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern IntPtr CertOpenStore(
int storeProvider, int encodingType,
int hcryptProv, int flags, string pvPara);
[DllImport("CRYPT32", EntryPoint="CertEnumCertificatesInStore", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern IntPtr CertEnumCertificatesInStore(
IntPtr storeProvider,
IntPtr prevCertContext);
[DllImport("CRYPT32", EntryPoint="CertCloseStore", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern bool CertCloseStore(
IntPtr storeProvider,
int flags);
X509CertificateCollection m_certs;
public MyCerts(){
m_certs = new X509CertificateCollection();
}
public int Init()
{
IntPtr storeHandle;
storeHandle = CertOpenStore(CERT_STORE_PROV_SYSTEM, 0, 0, CERT_SYSTEM_STORE_CURRENT_USER, "MY");
IntPtr currentCertContext;
currentCertContext = CertEnumCertificatesInStore(storeHandle, (IntPtr)0);
int i = 0;
while (currentCertContext != (IntPtr)0)
{
m_certs.Insert(i++, new X509Certificate(currentCertContext));
currentCertContext = CertEnumCertificatesInStore(storeHandle, currentCertContext);
}
CertCloseStore(storeHandle, 0);
return m_certs.Count;
}
public X509Certificate this [int index]
{
get
{
// Check the index limits.
if (index < 0 || index > m_certs.Count)
return null;
else
return m_certs[index];
}
}
};
class MyHttpResource
{
String m_url;
public MyHttpResource(string url){
m_url = url;
}
public void GetFile(){
HttpWebResponse result = null;
try{
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(m_url);
req.Credentials = CredentialCache.DefaultCredentials;
///Method1
//req.ClientCertificates.Add(X509Certificate.CreateFromCertFile("D:\\Temp\\cert\\c1.cer"));
///Method2
///Uses interop services
MyCerts mycert = new MyCerts();
if(mycert.Init() > 0)
req.ClientCertificates.Add(mycert[0]);
result = (HttpWebResponse)req.GetResponse();
Stream ReceiveStream = result.GetResponseStream();
Encoding encode = System.Text.Encoding.GetEncoding("utf-8");
StreamReader sr = new StreamReader( ReceiveStream, encode );
Console.WriteLine("\r\nResponse stream received");
Char[] read = new Char[256];
int count = sr.Read( read, 0, 256 );
Console.WriteLine("HTTP Response...\r\n");
while (count > 0)
{
String str = new String(read, 0, count);
Console.Write(str);
count = sr.Read(read, 0, 256);
}
}
catch(WebException e)
{
Console.WriteLine("\r\nError:");
#if (DEBUG)
Console.WriteLine(e.ToString());
#else
Console.WriteLine(e.Message);
#endif
}
finally
{
if ( result != null ) {
result.Close();
}
}
}
}
class CertSample
{
static void Main(string[] args)
{
try
{
if (args.Length < 1)
{
Console.WriteLine("No url is entered to download, returning.\n");
Console.WriteLine("Usage: CertSample <urltoget>\n");
Console.WriteLine(" e.g: CertSample https://servername \n");
return;
}
MyHttpResource hr = new MyHttpResource(args[0]);
hr.GetFile();
}
catch(Exception e)
{
Console.WriteLine(e.ToString());
}
return;
}
}
}
有关更多的信息，请访问下面的 Microsoft 开发人员网络 (MSDN) 的网站：
http://msdn2.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate(vs.71).aspx)
摘自：http://apps.hi.baidu.com/share/detail/16502796
HttpWebRequest和HttpWebResponse类是用于发送和接收HTTP数据的最好选择。它们支持一系列有用的属性。这两个类位 于System.Net命名空间，默认情况下这个类对于控制台程序来说是可访问的。请注意，HttpWebRequest对象不是利用new关键字通过构 造函数来创建的，而是利用工厂机制（factory mechanism）通过Create()方法来创建的。另外，你可能预计需要显式地调用一个“Send”方法，实际上不需要。接下来调用 HttpWebRequest.GetResponse()方法返回的是一个HttpWebResponse对象。你可以把HTTP响应的数据流 （stream）绑定到一个StreamReader对象，然后就可以通过ReadToEnd()方法把整个HTTP响应作为一个字符串取回。也可以通过 StreamReader.ReadLine()方法逐行取回HTTP响应的内容。
这种技术展示了如何限制请求重定向（request redirections）的次数， 并且设置了一个超时限制。下面是HttpWebRequest的一些属性，这些属性对于轻量级的自动化测试程序是非常重要的。
l AllowAutoRedirect：获取或设置一个值，该值指示请求是否应跟随重定向响应。
l CookieContainer：获取或设置与此请求关联的cookie。
l Credentials：获取或设置请求的身份验证信息。
l KeepAlive：获取或设置一个值，该值指示是否与 Internet 资源建立持久性连接。
l MaximumAutomaticRedirections：获取或设置请求将跟随的重定向的最大数目。
l Proxy：获取或设置请求的代理信息。
l SendChunked：获取或设置一个值，该值指示是否将数据分段发送到 Internet 资源。
l Timeout：获取或设置请求的超时值。
l UserAgent：获取或设置 User-agent HTTP 标头的值
C# HttpWebRequest提交数据方式学习之前我们先来看看什么是HttpWebRequest，它是 .net 基类库中的一个类，在命名空间 System.Net 下面，用来使用户通过HTTP协议和服务器交互。
C# HttpWebRequest的作用：
HttpWebRequest对HTTP协议进行了完整的封装，对HTTP协议中的 Header, Content, Cookie 都做了属性和方法的支持，很容易就能编写出一个模拟浏览器自动登录的程序。
C# HttpWebRequest提交数据方式：
程序使用HTTP协议和服务器交互主要是进行数据的提交，通常数据的提交是通过 GET 和 POST 两种方式来完成，下面对这两种方式进行一下说明：
C# HttpWebRequest提交数据方式1. GET 方式。
GET 方式通过在网络地址附加参数来完成数据的提交，比如在地址 http://www.google.com/webhp?hl=zh-CN 中，前面部分 http://www.google.com/webhp 表示数据提交的网址，后面部分 hl=zh-CN 表示附加的参数，其中 hl 表示一个键(key)， zh-CN 表示这个键对应的值(value)。程序代码如下：
- HttpWebRequest
req = - (HttpWebRequest)
HttpWebRequest.Create( - "http://www.google.com/webhp?hl=zh-CN"
); - req.Method
= "GET"; - using
(WebResponse wr = req.GetResponse()) - {
-
//在这里对接收到的页面内容进行处理 - }
C# HttpWebRequest提交数据方式2. POST 方式。
POST 方式通过在页面内容中填写参数的方法来完成数据的提交，参数的格式和 GET 方式一样，是类似于 hl=zh-CN&newwindow=1 这样的结构。程序代码如下：
- string
param = "hl=zh-CN&newwindow=1"; - byte[]
bs = Encoding.ASCII.GetBytes(param); -
- HttpWebRequest
req = - (HttpWebRequest)
HttpWebRequest.Create( - "http://www.google.com/intl/zh-CN/"
); - req.Method
= "POST"; - req.ContentType
= "application/x-www-form-urlencoded"; - req.ContentLength
= bs.Length; -
- using
(Stream reqStream = req.GetRequestStream()) - {
-
reqStream.Write(bs, 0, bs.Length); - }
- using
(WebResponse wr = req.GetResponse()) - {
-
//在这里对接收到的页面内容进行处理 - }
在上面的代码中，我们访问了 http://www.google.com/ 的网址，分别以 GET 和 POST 方式提交了数据，并接收了返回的页面内容。然而，如果提交的参数中含有中文，那么这样的处理是不够的，需要对其进行编码，让对方网站能够识别。
C# HttpWebRequest提交数据方式3. 使用 GET 方式提交中文数据。
GET 方式通过在网络地址中附加参数来完成数据提交，对于中文的编码，常用的有 gb2312 和 utf8 两种，用 gb2312 方式编码访问的程序代码如下：
- Encoding
myEncoding = Encoding.GetEncoding("gb2312"); - string
address = "http://www.baidu.com/s?" - +
HttpUtility.UrlEncode("参数一", myEncoding) + -
"=" + HttpUtility.UrlEncode("值一", myEncoding); - HttpWebRequest
req = - (HttpWebRequest)HttpWebRequest.Create(address);
- req.Method
= "GET"; - using
(WebResponse wr = req.GetResponse()) - {
-
//在这里对接收到的页面内容进行处理 - }
在上面的程序代码中，我们以 GET 方式访问了网址 http://www.baidu.com/s ，传递了参数“参数一=值一”，由于无法告知对方提交数据的编码类型，所以编码方式要以对方的网站为标准。常见的网站中， http://www.baidu.com/ （百度）的编码方式是 gb2312, http://www.google.com/ （谷歌）的编码方式是 utf8。
C# HttpWebRequest提交数据方式4. 使用 POST 方式提交中文数据。
POST 方式通过在页面内容中填写参数的方法来完成数据的提交，由于提交的参数中可以说明使用的编码方式，所以理论上能获得更大的兼容性。用 gb2312 方式编码访问的程序代码如下：
- Encoding
myEncoding = Encoding.GetEncoding("gb2312"); - string
param = - HttpUtility.UrlEncode("参数一",
myEncoding) + - "="
+ HttpUtility.UrlEncode("值一", myEncoding) + - "&"
+ HttpUtility.UrlEncode("参数二", myEncoding) + - "="
+ HttpUtility.UrlEncode("值二", myEncoding); -
- byte[]
postBytes = Encoding.ASCII.GetBytes(param); -
- HttpWebRequest
req = (HttpWebRequest) - HttpWebRequest.Create(
"http://www.baidu.com/s" ); - req.Method
= "POST"; - req.ContentType
= - "application/x-www-form-urlencoded;charset=gb2312";
- req.ContentLength
= postBytes.Length; -
- using
(Stream reqStream = req.GetRequestStream()) - {
-
reqStream.Write(bs, 0, bs.Length); - }
- using
(WebResponse wr = req.GetResponse()) - {
-
//在这里对接收到的页面内容进行处理 - }
从上面的代码可以看出， POST 中文数据的时候，先使用 UrlEncode 方法将中文字符转换为编码后的 ASCII 码，然后提交到服务器，提交的时候可以说明编码的方式，用来使对方服务器能够正确的解析。
以上列出了客户端程序使用HTTP协议与服务器交互的情况，常用的是 GET 和 POST 方式。现在流行的 WebService 也是通过 HTTP 协议来交互的，使用的是 POST 方法。与以上稍有所不同的是， WebService 提交的数据内容和接收到的数据内容都是使用了 XML 方式编码。所以， HttpWebRequest 也可以使用在调用 WebService 的情况下。
C# HttpWebRequest提交数据方式的基本内容就向你介绍到这里，希望对你了解和学习C# HttpWebRequest提交数据方式有所帮助
摘自：http://crm.xingfa.com/HelpDesk/Archiver.asp?ThreadID=8587 感谢作者
我们来简单地看看SQL SERVER索引是如何工作的，关于索引的一些概念就不说了。
聚簇索引：
(图A)
我们来看图A,聚簇索引的结构图。
数据页就是数据库里实际存储数据的地方，可以看到是按页1页1页存的。
假设那个列是”LastName”。
因为是聚集索引,所以它是按照顺序排下来的。可以看到，索引是一棵树，首先先看一下这棵树是怎么形成的。
先看Page100和Page110的最上面，由它们形成了Page141,Page141的第一条数据是Page100的第一条数据，Page141的最后一条数据是Page110的第一条数据。同理由Page120和Page130形成Page145,Page141和Page145形成根Page140.
好了，然后来看看它是如何查找数据的。
我们来找”Rudd”这个姓。
首先它会从根即Page140开始找,因为”Rudd”的值比”Martin”大(只要比较一下他们首字母就知道了,按26个字母顺序R排在M的后面)，所以会往”Martin”的后面找，即找到Page145,然后在比较一下”Rudd”和”Smith”,”Rudd”比”Smith”小，所以会往左边找即Page120,然后在Page120逐行扫描下来直到找到”Rudd”。
如果不建索引的话，SQL SERVER会从第一页开始按顺序每页逐行扫描过去，直到找到”Rudd”。显然如果对于一个百万行的表来说，效率是极其低下的，如果建了索引，非常快就能找到。
非聚簇索引：
(图B)
看图B，非聚簇索引的结构图。
聚簇索引和非聚簇索引的区别就是：聚簇索引的数据物理存储顺序和索引顺序一致的，也就是它的数据就是按顺序排下来的。非聚簇索引的数据存储是无序的，不按索引顺序排列。
从图B可以看到数据页里是无序的。那么它的索引是如何建立的呢？
再看图B，它是把这个索引列的数据复制了一份然后按顺序排下来，再建立索引。每行数据都有一个指针。
我们再来找”Rudd”.首先从索引页的根开始找，查找原理跟聚集索引是一样的。在索引页的Page61找到”Rudd”,它的指针是470501，然后在数据页的Page5找到470501，这个位置就是”Rudd”在数据库中的实际位置,这样就找到了”Rudd”。
好了,索引的基本工作原理就是这样，可能实际上要复杂些。
在前面说过了索引能极大的提高数据的检索速度，那为什么不在每一个列上建索引呢？初学者可能会困惑这个问题，而且通常不知道哪些列该建索引，哪些不该建， 甚至于会把like模糊查询的列也作为索引列，其实like是不使用索引的，只有等于,大于,IN等操作符会使用索引。SQLSERVER对于数据的插入，更新和删除，都要更新相应的索引。这无疑会大大增加更新时间。另外，如果某个数据页已满，这时如果要在该页插入数据时，就会造成页分裂产生碎片(后面还会说到)，而影响性能。所以仅当查询的性能比更新的性能更重要时才建索引。
考虑建索引的列
1. 主键
2. 外键
3. 频繁检索的列和按排序顺序频繁检索的列
通常where 后面的条件引用的列都是考虑建索引的列，模糊查询除外(如like查询)
不考虑建索引的列
1.很少或从来不在查询中引用的列
2.只有两个或若干个值的列(比如只有男和女两个值的列)
3.小表(行数很少的表，这时候SQL SERVER花费在索引上的时间比直接扫描表的时间还更长)
SQL SERVER对于建立索引的列，都要付出一定的代价来维护这个索引。另外SQLSERVER会自动分析是否使用该列的索引，比如对于只有男和女两个值的列，如果给它建立索引，SQLSERVER自行分析后，会认为改列使用索引查找的效率不大，因为返回结果集的百分比比较大，于是SQLSERVER会将统计数据记录下来，当下次查找该列时，就会根据该统计数据来决定是否要使用改列的索引。
对于返回结果集百分比比较大的列(比如有100万的数据，而查找的结果将返回50万)，SQLSERVER就可能不会使用该列上的索引，而采用全表扫描的方法。可自行测试，插入2000条数据，有1999条数据是一样的，比如ForumID为2的有1999条，ForumID为3的只有一条，这时使用
SET SHOWPLAN_TEXT ON –显示执行计划，可查看查询语句使用了哪些索引
GO
SELECT * FROM Posts WHERE ForumID=2
会发现没有使用ForumID列的索引。
SELECT * FROM Posts WHERE ForumID=3
则使用了ForumID列的索引
进行大批量插入或更新应先删除索引最后再重建索引，避免每插入或更新一条数据时都要更新相应的索引，而影响更新速度。
复合索引(指两列或多列组成的索引，通常where后面由多个列组成的条件时，可以把这些列建成一个复合索引)
1) 只有当WHERE子句中指定索引键的第一列时才使用该索引。
例子:
CREATE INDEX Posts_INDEX
ON Posts(ThreadID,ForumID)
如果SELECT * FROM Posts WHERE ForumID=2 则查询不会使用Posts_INDEX索引
而 SELECT * FROM Posts WHERE ThreadID=10 则会使用Posts_INDEX索引
2) 索引不应过大(<= 8个字节为最好，int型相当于4个字节，SmallInt相当于2个字节)。
3) 首先定义最具唯一性的列(顺序不一样，索引是不一样的)
比如:A列有30%的数据是重复的，B列有10%的列是重复的，C列有25%的数据是重复的，这时候建立索引的列的顺序应当是 B C A
建立索引还有一个比较重要的选项:填充因子。下一篇继续。
建SQL SERVER索引的时候有一个选项，即Fillfactor(填充因子)。
这个可能很少人会去注意它，但它也是比较重要的。大家可能也都知道有这个东西，但是如何去使用它，可能会比较迷糊。另外，即使你理解了它的原理，也不一定能使用好它，这个还要具体分析索引字段的更新频率等等。
记得看书知道有这么个东西，但是都是看的迷迷糊糊的，不知道干吗的，好象设置不设置都一样的。其实，像索引这些东西，当数据达到几十万上百万的时候，它的效果就表现的很明显。
填充因子定义：索引中叶级页的数据充满度。它的作用：当系统新建或重建索引时，在每一个索引页上预先留出一部分空间。使得系统在新增索引信息时能够保持索引页不分裂。它的目的是使索引的页分裂最小并对性能微调。
(图A)
看图A，通过前面说的我们知道数据是按页存的，根据定义，填充因子是指图A中的Page100(Page110,Page120,Page130)的数据的充满度。如果按默认，填充因子是为0(0和100%是一样的)，即完全充满。如果设置60%，则Page100的数据只充满空间的60%，会有40%的剩余空间。
填充因子只在创建索引时执行；索引创建后，当表中进行数据的添加、删除或更新时，不会保持填充因子。即创建索引完后添加数据，比如添加”COM”,则会添加在Page100的”CON”的前面，此时Page100的剩余空间将小于40%。因为充满度只有60%，所以”Barr”和”CON”之间会有空隙，所以”COM”将直接插入他们之间，不会照成数据移动和页分裂。如果充满度是100%即整页充满数据，则会照成”CON”及它后面的数据都向后移动1位，然后在”CON”前面插入”COM”，而Page100会大约一半的行(后半部)移到新页中以便为新行腾出空间(这种重组称为页拆分。页拆分会降低性能并使表中的数据存储产生碎片.)，在这些移动的过程中一方面速度明显下降，另一方面会产生碎片。添加完数据后要使填充因子继续保持60%则需要重建索引。
有人将填充因子比喻成下面这个例子：
为了给一个班的10个同学排一下顺序，我们可以给每一位同学一个编号，如:
a. 从1,2,3,4,5,6,7,9,10。这时，我们说填充因子是100.
此时,如果又来了新同学,而其排名要在中间某位置的话,我们就要改变许多个同学的号码,如新同学排第5位,就需要4号以后的同学号码都加1，再将新同学编为5号才行.
b.我们又可以给同学这样编号：1,3,5,7,9,11,13,15,17,19
也同样完成了顺序的排列.我们说这时填充因子是50%,此时如果来了新同学,又是排在第5位的话,那么我们只需将其号码编为8就行了.其它同学都不用变.
可见,填充因子大的时候,点用的号码空间小,耗费资源少,小的时候,占用资源加大,但操作方便,迅速.
填充因子大的时候,插入或修改记录后重新索引的工作会很大,磁盘IO操作增加,性能必然降低,但其占用空间小.填充因子小的时候,索引文件占用磁盘及内存空间相对要大,但是,系统本身重新索引所需IO操作减少,性能提高,只是多占用一些存储空间. 孰轻孰重要自已决定。
通常只有当不会对数据进行更改时(例如，在只读表中)才会使设置100%。另外,只有当在表中根据现有数据创建新索引，并且可以精确预见将来会对这些数据进行哪些更改时，将填充因子选项设置为另一个值才有用。所以填充因子不是很容易设置的。
摘自：http://www.360doc.com/showWeb/0/0/56113730.aspx
|
之前使用.net 和Java通过Web Service调用,都是传递的简单类型。最近由于项目需要，需要之间传递自定义对象 做了一个简单的例子，可以调用成功。 在。net中定义一个简单对象 |
代码
/**//// <summary>
/// 身份证件号码
/// </summary>
public string IdentityNumber
...{
get...{ return m_IdentityNumber; }
set...{ m_IdentityNumber = value; }
}
private string m_IdentityNumber;
}
在WebService中发布：
代码
[SoapRpcMethod
(Action="http://tempurl.org/GetUserInfoByPerson",
RequestNamespace="http://tempurl.org",
ResponseNamespace="http://tempurl.org")
]
public Person GetUserInfoByPerson()
...{
Person p = new Person();
p.IdentityNumber ="1234234342";
return p;
注意在使用Java客户端调用的时候，要导入6个jar的包：axis.jar，commons-discovery-0.2.jar，commons-logging-1.0.4.jar,jaxrpc.jar,saaj.jar,wsdl4j-1.5.1.jar
在java客户端，注册自定义对象的序列化/反序列化器。
核心代码如下：
代码
public class Person implements Serializable ...{
/** *//** * */
public Person() ...{ }
private static final long serialVersionUID = -6414428095965735488L;
public String IdentityNumber;
}
调用的代码：
代码
QName qn = new QName("Person");
call.registerTypeMapping(Person.class, qn, new BeanSerializerFactory(Person.class, qn), new BeanDeserializerFactory(Person.class, qn));
call.setOperationName(new QName("http://tempurl.org", "GetUserInfoByPerson"));//设置请求的命名空间及方法名
String str = "http://localhost/test/testservice.asmx";//web服务的URL地址
call.setTargetEndpointAddress(new java.net.URL(str));
call.setUseSOAPAction(true);
call.setSOAPActionURI("http://tempurl.org/GetUserInfoByPerson");//设置SOAPAction
call.setReturnClass(Person.class);
Person p = (Person)call.invoke(new Object[]...{s});
System.out.println("Get WebServices result is: "+p);
System.out.println("Get WebServices result is: "+p.IdentityNumber);
在Java客户端可以获取Person的对象
摘自：http://blog.csdn.net/zhoufoxcn/archive/2009/04/27/4127799.aspx
为你的类库生成类似于MSDN的帮助文档
.net开发人员都知道大名鼎鼎的MSDN帮助文章，对VS2008的MSDN帮助文档，微软是这么定义的：
“MSDN Library for Visual Studio 2008 是权威的开发人员文档。我们将继续为您提供有关 Visual Studio 2008 发行版本地帮助的最新信息，同时，我们还增强了帮助选项，包括联机 F1 主题、搜索、索引以及联机或脱机使用目录的能力。有关本文档库改进功能的更多信息，请单击右侧的链接或访问新增功能页面。”
下面是MSDN的截图：
有没有想过为你的程序也生成类似的文档便于别的开发阅读你提供的类库的API文档呢？早期的开发人员可能知道NDoc这个工具，这是一个类似于JavaDoc的工具，它能将程序代码中的XML注释提取出来生成帮助文档，非常方便。
什么？你不知道什么是XML注释？看下图：
XML注释可以在别人在VS中编写代码获得智能感知效果时看到，如下图：
有时候因为某些原因不能提供程序源代码，这样就不能方便查看类库中的类和对应的方法了。早期的.net开发人员可以用NDoc来生成类库的API文档，不过NDoc不支持.net 2.0了（据说是作者知道微软要推出类似的工具停止了更新的），网上虽然有一些在NDoc的基础上开发的支持.net 2.0的版本，但是在使用过程中偶尔会出现一些问题。
微软推出了一款小软件就支持这种功能，支持生成CHM格式或者Hxs格式的文档，这款软件就是Sandcastle，它可以从http://download.codeplex.com/网站上下载，下载地址是：
http://sandcastle.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=13873（如果英文不好的朋友可可以在http://download.csdn.net/zhoufoxcn下载）
从网上下载这个软件之后采用默认安装之后（假设默认安装在C:\Program Files目录下），在其安装目录下的Examples\generic会看到一个名为SandcastleGui.exe的文件，这个文件就是Sandcastle的图形化用户界面。这个软件的界面很简单，如下图所示：
Sandcastle是根据程序集和对应的XML注释文档来生成帮助文档的。不过在默认情况下是不会生成程序的XML注释文档的，需要在VS中做一下配置，在要生成帮助文档的项目上点击鼠标右键然后选择查看属性，这样就会出现项目属性配置界面，再点击“生成”选项卡，如下图所示：
选择XML文档注释，这样每次编译成功时就会生成相应的XML文档注释，默认是与生成的程序集文件在同一个目录下。
运行Sandcastle，分别添加程序集和XML文档注释，如果程序集有依赖的程序也添加一下，并且填写保存文件的名称，如果没有问题的话就会生成相应的API文档了，如果有问题就会在日志窗口看到错误信息，如下图所示。
从上图窗口中可以成功生成了NS.Common.chm文档，文档路径为：c:\Program Files\Sandcastle\Examples\NS.Common\vs2005\chm\NS.Common.chm，大小为126,213 bytes。打开c:\Program Files\Sandcastle\Examples\NS.Common\vs2005\chm\文件夹，确实可以看到一个chm文件，打开这个chm文件，会看到如下效果：
看到这个界面是不是跟MSDN有些相似呢？至此，大功告成了。顺便提一下，这个软件是公开源代码的，如果有那位朋友有兴趣和时间并且English不错的话，可以将它汉化成中文的那就更好了，不过这个工具操作非常简单，即使不汉化也容易上手。
注：Sandcastle支持将多个程序集的XML文档注释生成一个chm文件的功能，可以将多个程序集和对应XML文档注释分别放在两个文件夹下，然后用AddFolder功能一次性将文件夹下的文件添加到项目中，这样就可以将多个程序集的XML注释合并生成一个CHM文档了。
周公
于2009-4-26 01:26
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhoufoxcn/archive/2009/04/27/4127799.aspx
转自：http://www.itqun.net/content-detail/104196.html
set statistics profile on
set statistics io on
set statistics time on
一个查询需要的CPU、IO资源越多，查询运行的速度就越慢，因此，描述查询性能调节任务的另一种方式是，应该以一种使用更少的CPU、IO资源的方式重写查询命令，如果能够以这样一种方式完成查询，查询的性能就会有所提高。
如果调节查询性能的目的是让它使用尽可能少的服务器资源，而不是查询运行的时间最短，那么就更容易测试你采取的措施是提高了查询的性能还是降低了查询的性 能。尤其是在资源利用不断变化的服务器上更是如此。首先，需要搞清楚在对查询进行调节时，如何测试我们的服务器的资源使用情况。
在开始我们的例子前，先运行下面的这二条命令（不要在正在使用的服务器上执行），这二条命令将清除SQL Server的数据和过程缓冲区，这样能够使我们在每次执行查询时在同一个起点上，否则，每次执行查询得到的结果就不具有可比性了：DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
输入并运行下面的Transact-SQL命令：
SET STATISTICS IO ON
SET STATISTICS TIME ON
一旦上面的准备工作完成后，运行下面的查询：
SELECT * FROM [order details]
显示结果：
SQL Server parse and compile time: （SQL Server解析和编译时间：）
CPU time = 10 ms, elapsed time = 61 ms. ……（1）
SQL Server parse and compile time: （SQL Server解析和编译时间：）
CPU time = 0 ms, elapsed time = 0 ms. ……（2）
（所影响的行数为 2155 行） ……（3）
Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9.
（表：Order Details，扫描次数 1，逻辑读 10，物理读 1，提前读取 9） ……（4）
SQL Server Execution Times:
（SQL Server执行时间：）
CPU time = 30 ms, elapsed time = 387 ms. ……（5）
标志（1）表示SQL Server解析“ELECT * FROM [order details]”命令并将解析的结果放到SQL Server的过程缓冲区中供SQL Server使用所需要的CPU运行时间和总的时间。
标志（2）表示SQL Server从过程缓冲区中取出解析结果供执行的时间，大多数情况下这二个值都会是0，因为这个过程执行得相当地快。
标志（5）表 示执行这次查询使用了多少CPU运行时间和运行查询使用了多少时间。CPU运行时间是对运行查询所需要的CPU资源的一种相对稳定的测量方法，与CPU的 忙闲程度没有关系。但是，每次运行查询时这一数字也会有所不同，只是变化的范围没有总时间变化大。总时间是对查询执行所需要的时间（不计算阻塞或读数据的 时间），由于服务器上的负载是在不断变化的，因此这一数据的变化范围有时会相当地大。（由于CPU占用时间是相对稳定的，因此可以使用这一数据作为衡量你的调节措施是提高了查询性能还是降低了查询的性能的一种方法。）
标志（4）是SET STATISTICS IO的效果
Scan Count：在查询中涉及到的表被访问的次数。在我们的例子中，其中的表只被访问了1次，由于查询中不包括连接命令，这一信息并不是十分有用，但如果查询中包含有一个或多个连接，则这一信息是十分有用的。（一 个循环外部的表的Scan Count值为1，但对于一个循环内的表而言，其值为循环的次数。可以想象得到，对于一个循环内的表而言，其Scan Count值越小，它所使用的资源越少，查询的性能也就越高。因此在调节一个带连接的查询的性能时，需要关注Scan Count的值，在进行调节时，注意观察它是增加还是减少了。）
Logical Reads: 这是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的 数据。我们知道，SQL Server在可以对任何数据进行操作前，必须首先把数据读取到其数据缓冲区中。此外，我们也知道SQL Server何时会从数据缓冲区中读取数据，并把数据读取到大小为8K字节的页中。那么Logical Reads的意义是什么呢？Lo
gical Reads是指SQL Server为得到查询中的结果而必须从数据缓冲区读取的页数。在执行查询时，SQL Server不会读取比实际需求多或少的数据，因此，当在相同的数据集上执行同一个查询，得到的Logical Reads的数字总是相同的。（SQL Server执行查询时的Logical Reads值每一次这个数值是不会变化的。因此，在进行查询性能的调节时，这是一个可以用来衡量你的调节措施是否成功的一个很好的标准。如果 Logical Reads值下降，就表明查询使用的服务器资源减少，查询的性能有所提高。如果Logical Reads值增加，则表示调节措施降低了查询的性能。在其他条件不变的情况下，一个查询使用的逻辑读越少，其效率就越高，查询的速度就越快。）
Physical Reads：物 理读，在执行真正的查询操作前，SQL Server必须从磁盘上向数据缓冲区中读取它所需要的数据。在SQL Server开始执行查询前，它要作的第一件事就是检查它所需要的数据是否在数据缓冲区中，如果在，就从中读取，如果不在，SQL Server必须首先将它需要的数据从磁盘上读到数据缓冲区中。我们可以想象得到，SQL Server在执行物理读时比执行逻辑读需要更多的服务器资源。因此，在理想情况下，我们应当尽量避免物理读操作。下面的这一部分听起来让人容易感到糊涂 了。在对查询的性能进行调节时，可以忽略物理读而只专注于逻辑读。你一定会纳闷儿，刚才不是还说物理读比逻辑读需要更多的服务器资源吗？情况确实是这样， SQL Server在执行查询时所需要的物理读次数不可能通过性能调节而减少的。减少物理读的次数是DBA的一项重要工作，但它涉及到整个服务器性能的调节，而 不仅仅是查询性能的调节。在进行查询性能调节时，我们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所需要的数据是在数据缓冲区中还是在磁盘 上，唯一我们能够控制的数据是得到查询结果所需要执行的逻辑读的次数。
因此，在查询性能的调节中，我们可以心安理得地不理会SET STATISTICS IO命令提供的Physical Read的值。（减少物理读次数、加快SQL Server运行速度的一种方式是确保服务器的物理内存足够多。）
Read-Ahead Reads： 与Physical Reads一样，这个值在查询性能调节中也没有什么用。Read-Ahead Reads表示SQL Server在执行预读机制时读取的物理页。为了优化其性能，SQL Server在认为它需要数据之前预先读取一部分数据，根据SQL Server对数据需求预测的准确程度，预读的数据页可能有用，也可能没用。
在本例中，Read-Ahead Reads的值为9，Physical Read的值为1，而Logical Reads的值为10，它们之间存在着简单的相加关系。那么我在服务器上执行查询时的过程是怎么样的呢？首先，SQL Server会开始检查完成查询所需要的数据是否在数据缓冲区中，它会很快地发现这些数据不在数据缓冲区中，并启动预读机制将它所需要的10个数据页中的 前9个读取到数据缓冲区。当SQL Server检查是否所需要的全部数据都已经在数据缓冲区时，会发现已经有9个数据页在数据缓冲区中，还有一个不在，它就会立即再次读取磁盘，将所需要的 页读到数据缓冲区。一旦所有的数据都在数据缓冲区后，SQL Server就可以处理查询了。
总结：在对查询的性能进行调节时用一些科学的标准来测量你的调节措施是否有效是十分重要的。问题是，SQL Servers的负载是动态变化的，使用查询总的运行时间来衡量你正在调节性能的查询的性能是提高了还是没有，并不是一个合理的方法。
更好的方法是比较多个数据，例如逻辑读的次数或者查询所使用的CPU时间。因此在对查询的性能进行调节时，需要首先使用SET STATISTICS IO和SET STATISTICS TIME命令向你提供一些必要的数据，以便确定你对查询性能进行调节的措施是否真正地得到了目的。======================
1.测试前用二条命令清除SQL Server的数据和过程缓冲区，以保证测试条件相同：
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
2.SET STATISTICS TIME：看cpu时间