下面是VS2010中的新增特性(网上copy过来的)：
·对多显示器的支持
·支持调用继承树
·新特性支持TDD
·新特性支持Office开发
·全新的Quick Search功能
·Call hierarchy高亮对象的引用
·直接使用一个未定义的对象
·提供更方便的javascript脚本编写
·HTML snippets超越智能提示
·可以进行自定义开始页
·C# 4.0的语言新特性
·提升了SharePoint开发功能
·特性聚焦：分析和调试并行应用程序
·正式包含F#函数式语言

下载完后，迫不及待开始安装：

和期望比较不一样的是，安完需要的组件，供占5个多GB的硬盘空间，还是比较苗条了。选完需要安装的组件，俺很慎重的按下了Install按钮……

漫长的安装过程，中途机器重启了两次，一次是在.NET Framework 4.0安装过后，一次是在整体安装完毕过后。

安装完毕，俺怀着激动的心情，启动了VS2010，跳出不规则的Splash Window.

整体使用感觉相当不错，此前还担心WPF实现的IDE界面会拖慢运行速度，看来这样的担心是多余的。跟VS2008相比，感觉VS2010的反应速度会快很多。看来这方面的优化还是做足了功夫的。另外，令人满意的是VS2010的扩展功能，内置的Extention Manager能够看到很多的在线扩展，选择你想要的，可以在线安装和卸载。这种方式让VS2010的扩展更加丰富和强大，值得表扬！

另外，还有很多的关于.NET Framework 4.0 以及 VS2010的新特性还没来得及体验，比如dynamic，并行编程，新版的ADO.NET Entity Framework，新引入的F#语言，等等……
无意中也发现，ReSharper 5.0 也随着VS2010的发布而发布了，看来步调相当一致啊~这款功能强大的工具，自从VS2005开始，俺就一直用，现在不装反而不习惯了。于是卸掉之前的ReSharper 4.5，升级到5.0版。ReSharper 5.0本身也支持VS2008和VS2010，这样机器上的两个IDE可以和谐共存，并同时使用ReSharpter 5.0，简直太完美了。

总体感觉：VS2010和VS2008相比，确实是一大进步，或者说，确实是个飞跃…… 打算用段时间就把VS2008从机器中清理掉，嘿嘿……

你可能也对下列文章感兴趣

• 2009年05月26日 -- Visual Studio 2010 Beta1 is available for download (0)
• 2009年07月13日 -- Visual Studio IDE配色方案 (9)
• 2010年02月13日 -- Happy New Year！2010 (20)
• 2010年01月4日 -- Happy New Year 2010 & 2009回顾 (9)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace CommonLib
{
    public static class EntityValidator
    {
        public static ValidateResult Validate(this T target,
                                              Predicate predicate,
                                              string errorMessage)
        {
            var result = new ValidateResult(target);
 
            if (!predicate(target))
            {
                result.Errors.Add(errorMessage);
            }
 
            return result;
        }
 
        public static ValidateResult Validate(this ValidateResult target,
                                              Predicate predicate,
                                              string errorMessage)
        {
 
            if (!predicate(target.Entity))
            {
                target.Errors.Add(errorMessage);
            }
 
            return target;
        }
    }
 
    public class ValidateResult
    {
        internal List Errors { get; set; }
        internal T Entity { get; private set; }
        public bool HasErrors
        {
            get { return Errors.Count > 0; }
        }
 
        internal ValidateResult(T entity)
        {
            Errors = new List();
 
            Entity = entity;
        }
 
        public string[] ErrorMessages { get { return Errors.ToArray(); } }
    }
}

有了这个实体验证的方法，代码可以简洁多了，并且再也不用在业务逻辑判断中，写入复杂的if…else语句块，取而代之的代码，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12

ValidateResult validateResult =
                        content.Validate(c => !string.IsNullOrEmpty(c.Name), "Name为空")
                               .Validate(c => c.MobilePhone.Length == 11 , "MobilePhone长度不正确")
                               .Validate(c => c.Age >= 10), "年龄不在规定范围")
                               .Validate(c => c.Height <= 200 && c.Height >= 180, "身高不符合标准");
 
                    if (validateResult.HasErrors)
                    {
                        log.Info("实体验证失败:");
                        validateResult.ErrorMessages.ForEach(p => log.Info(p));
                        return null;
                    }

怎么样？这样的链式编程的代码，比起一大串的if…else组合语句，简洁、明了多了，并且还可以提高代码阅读的效率，强烈推荐各位同学使用。

你可能也对下列文章感兴趣

• 2009年11月14日 -- 常用扩展方法收集&整理(置顶-不断更新) (35)
• 2009年09月28日 -- 扩展方法使用小结 (0)

Linq to Sql中默认采用的模式就是延迟执行，所谓延迟执行，其实就是在获取对象本身时，并不会获取和其关联的其他对象，只有在访问其关联对象的时候，程序才会去加载关联对象的数据到内存中。这样的好处是程序不会在初次访问的时候，就加载大批量的数据，而是以一种延迟加载的方式进行处理，相对而言，对于系统和网络的性能开支会减小很多。对于一个默认的Linq to Sql查询，延迟加载就是其默认的设置，不过，在某些情况下，延迟加载并非完全“智能”，不但没有实现其本意，反而增大了网络流量和性能开支。下面我们以SQL Server中的演示数据库NorthWind来试验一下：

1
2
3
4
5
6
7
8
9
10
11
12
13

LinqTestDataContext ctx = new LinqTestDataContext();
ctx.Log = Console.Out;
 
var result = ctx.Orders.Where(p => p.OrderID == 10251);
 
foreach (var t in result)
{
	Console.WriteLine("OrderID:" 
		+ t.OrderID 
		+ "-" 
		+ "OrderDate:" 
		+ t.OrderDate.Value.ToString("yyyy-MM-dd"));
}

通过Linq to sql查询所有OrderID为10251的订单信息，并输出订单编号和订单日期。通过显示Linq的日志输出，我们可以看到后台生成的SQL语句如下：

1
2
3
4
5
6

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry]
FROM [dbo].[Orders] AS [t0]
WHERE [t0].[OrderID] = @p0

输出的SQL看来还比较正常。下面我们再来改一下我们的程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 foreach (var t in result)
            {
                Console.WriteLine("OrderID:" + t.OrderID 
		+ "-OrderDate:" 
		+ t.OrderDate.Value.ToString("yyyy-MM-dd") 
		+"-CustomerName:"
		+ t.Customer.ContactName);
                foreach(var m in t.Order_Details)
                Console.WriteLine("ProductID:" 
		+ m.ProductID 
		+ "-Price:" 
		+ m.UnitPrice 
		+ "-Amount:" 
		+ m.Quantity);
            }

出了输出订单相关信息外，还输出其关联对象：客户姓名、订单中的产品编号、单价、数量

再来看看输出的SQL语句：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry]
FROM [dbo].[Orders] AS [t0]
WHERE [t0].[OrderID] = @p0
 
 
SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactT
itle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Coun
try], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[CustomerID] = @p0
 
 
SELECT [t0].[OrderID], [t0].[ProductID], [t0].[UnitPrice], [t0].[Quantity], [t0]
.[Discount]
FROM [dbo].[Order Details] AS [t0]
WHERE [t0].[OrderID] = @p0

我们可以看到，对于我们修改后的代码，程序向数据库请求了三条SQL语句，当然，这还不是最坏的情况，但是我们在这里的确看到延迟加载似乎“变了味道”，不但没有节省开支，反而增大了网络浏览。怎样才能改善这样的情况呢？

关于立即加载

其实我们知道，有很多扩展方法会导致延迟加载失效，而开始立即执行。当我们在调用诸如：ToList、ToDictionary、ToLookup或者ToArray之类的扩展方法之后，程序会将最终的结果存放到某个临时的变量集合中，并让所有的数据一次性的加载完成。

另外，还有一种方式，通过设置DataContext的DeferredLoadingEnabled属性为false,显示的关闭默认的延迟加载方式。

1
2

LinqTestDataContext ctx = new LinqTestDataContext();
ctx.DeferredLoadingEnabled = false;

这些方式虽然比较方便，但是还是有一定的局限性。例如，简单的使用ToList只能解决一些简单的查询问题，而对于复杂的查询需求，ToList还是不能解决延迟取得子对象所引发的多次查询问题。并且，在大量数据被加载到内存中的时候，对内存的需求也是很大的。不过，幸好Linq to sql给我们提供了另外一套不错的方法。

使用DataLoadOptions实现对加载对象的优化

Linq to Sql提供DataLoadOptions，用以立即加载关联的对象数据，其中包含两种方法：

LoadWith方法，用于立即加载与主对象相关联的数据

AssociateWith方法，用于对关联对象的数据进行筛选，并加载

有了DataLoadOptions，我们就可以用如下的方式优化我们的查询中需要加载的对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

            LinqTestDataContext ctx = new LinqTestDataContext();
            ctx.Log = Console.Out;
 
            DataLoadOptions dl = new DataLoadOptions();
            dl.LoadWith<order>(p =&gt; p.Customer);
            dl.LoadWith<order>(p =&gt; p.Order_Details);
            ctx.LoadOptions = dl;
 
            var result = ctx.Orders.Where(p =&gt; p.OrderID == 10251).ToList();
 
            foreach (var t in result)
            {
                Console.WriteLine(&quot;OrderID:&quot; + 
		t.OrderID 
		+ &quot;-OrderDate:&quot; 
		+ t.OrderDate.Value.ToString(&quot;yyyy-MM-dd&quot;) 
		+&quot;-CustomerName:&quot;
		+ t.Customer.ContactName);
                foreach(var m in t.Order_Details)
                Console.WriteLine(&quot;ProductID:&quot; 
		+ m.ProductID 
		+ &quot;-Price:&quot; 
		+ m.UnitPrice 
		+ &quot;-Amount:&quot; 
		+ m.Quantity);
            }

对于我们开发者而言，需要注意的是，对于同一个DataContext实例，DataLoadOptions只能设定一次，并且一旦设定，就无法更改。

接下来，运行程序，看看优化后，程序向数据库服务器请求的的SQL：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry], [t3].[OrderID] AS [OrderID2], [t3].[ProductID], [t3]
.[UnitPrice], [t3].[Quantity], [t3].[Discount], (
    SELECT COUNT(*)
    FROM [dbo].[Order Details] AS [t4]
    WHERE [t4].[OrderID] = [t0].[OrderID]
    ) AS [value], [t2].[test], [t2].[CustomerID] AS [CustomerID2], [t2].[Company
Name], [t2].[ContactName], [t2].[ContactTitle], [t2].[Address], [t2].[City], [t2
].[Region], [t2].[PostalCode], [t2].[Country], [t2].[Phone], [t2].[Fax]
FROM [dbo].[Orders] AS [t0]
LEFT OUTER JOIN (
    SELECT 1 AS [test], [t1].[CustomerID], [t1].[CompanyName], [t1].[ContactName
], [t1].[ContactTitle], [t1].[Address], [t1].[City], [t1].[Region], [t1].[Postal
Code], [t1].[Country], [t1].[Phone], [t1].[Fax]
    FROM [dbo].[Customers] AS [t1]
    ) AS [t2] ON [t2].[CustomerID] = [t0].[CustomerID]
LEFT OUTER JOIN [dbo].[Order Details] AS [t3] ON [t3].[OrderID] = [t0].[OrderID]
 
WHERE [t0].[OrderID] = @p0
ORDER BY [t0].[OrderID], [t2].[CustomerID], [t3].[ProductID]

可以看出，之前的分三次向数据库提交sql的情况，现在被程序优化为一条带LEFT JOIN的关联查询，而获取关联数据。三次SQL请求，被优化为一次，从而减少了数据库和网络流量开支，由此看来DataLoadOptions的好处不言而喻。

一点小结

延迟加载与立即加载，并无孰优孰劣之区别，在某些情况下，需要我们根据自己的需求和实际情况来选择来进行选择。

你可能也对下列文章感兴趣

• 2010年06月19日 -- 启用Lazy Load插件 (13)
• 2004年12月22日 -- 动态加载并显示图片 (0)
• 2004年12月20日 -- 动态加载位图 (0)
• 2004年10月26日 -- 从文件装载图象 (0)
• 2004年10月26日 -- 动态加载DLL (0)

回想一下，在小到普通的应用程序，大到企业级项目中，我们常常会遇到需要定时轮询和调度的场景，简单点的需求是每隔固定的秒数或者分钟、小时进行轮询，复杂点的是每周的某个时刻，或者每月，或者每年才执行一次，又或者更复杂的情景，某些天需要执行，某些天不执行。用Windows自带的计划任务，能够实现简单的逻辑，如果要用程序实现这样的逻辑，想必也很复杂了。其实，用Quartz能很好的应付这些情况。

Quartz.NET的核心模块分为几个部分，Scheduler、Job、JobDetail、Trigger

Scheduler:实现调度的主体，负责调度任务的开始、结束，Scheduler中包含已注册的JobDetail和Trigger,并且，当Trigger中的条件得以触发时，Scheduler负责执行和Trigger相关联的Job，实现任务的调度。
Job:需要被调度的任务，Job必须实现IJob接口的Execute方法，而Execute方法的内容，其实也就是我们需要根据不同的需求自己实现的业务逻辑。
JobDetail:包含对Job的具体描述，包括Job的名称、所属的Group名称、以及Job的Type描述，用以Quartz.NET通过反射实现对Job的调用。
Trigger:触发器，描述调度的触发条件和时机。

Quartz.NET之所以没把Job和Trigger设计在一起，而是采用一种松耦合的方式，把Job和Trigger独立为两个不同的对象，原因是因为在Quartz.NET中，Job和Trigger可以建立一种一对多的关系，也就是可以对一个调度任务绑定多个Trigger，另外的好处是当某个Job的Trigger过期的时候，可以直接为Job绑定新的Trigger而不用重新定义和这个Trigger相关联的Job。

最初见到Quartz.NET，还是0.6的版本，一直躺在偶的硬盘里面，直到最近项目中遇到很多需要定时轮询处理的情况，突然想到了Quartz.NET，打开它在sourceforge的大本营，才发现Quartz.NET已经更新到1.0.1版本了。

Quartz.NET为我们提供了简洁的API，通过简单的例子，我们就可以很快上手和使用

在Quartz.NET中，所有的Job都必须实现IJob接口：

1
2
3
4
5
6
7

namespace Quartz
{
    public interface IJob
    {
        void Execute(JobExecutionContext context);
    }
}

JobExecutionContext 包含运行时的一些上下文信息，还可以用来传递参数

编写我们自己的Job，实现IJob接口：

1
2
3
4
5
6
7
8
9
10
11
12

using Quartz;
 
namespace ExampleJob
{
    public class TestJob : IJob
    {
        public void Execute(JobExecutionContext context)
        {
            Console.WriteLine("Job executed!");
        }
    }
}

然后就可以通过Scheduler来调度任务了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 创建SchedulerFactory
ISchedulerFactory schedFact = new StdSchedulerFactory();
 
// 获取Scheduler实例
IScheduler sched = schedFact.GetScheduler();
sched.Start();
 
// 创建JobDetail
JobDetail jobDetail = new JobDetail("ExampleJob", "MyJobGroup", typeof(ExampleJob));
// 创建Trigger，每分钟触发一次
Trigger trigger = TriggerUtils.MakeMinutelyTrigger();
// 设定trigger的开始时间
trigger.StartTimeUtc = TriggerUtils.GetEvenHourDate(DateTime.UtcNow);
trigger.Name = "myTrigger";
sched.ScheduleJob(jobDetail, trigger);

这样，任务调度框架便会每分钟调度一次我们的Job，在控制台每分钟都能看到一句 ”Job executed!”，是不是很简单呢？

其实Quartz.NET还有很多方便开发人员的特性和高级功能，比如通过配置文件配置Job和Trigger，可以让你的调度程序更加灵活，以应对后续需求的变化，而不需要重新编译程序。另外，还有调度线程池、JobStore、Clustering等很多高级功能，等着我们去发现。

相关资源：

Quartz.NET 主页：http://quartznet.sourceforge.net

在sourceforge的Quartz.NET主页上，有入门教程供初学者查看：http://quartznet.sourceforge.net/tutorial/index.html

另外，博客园的张善友也把教程翻译成了中文的，供E文不好的同学学习和参考，地址：http://www.cnblogs.com/shanyou/archive/2007/08/25/QuartzNETtutorial.html

随机日志

• 2008年03月29日 -- Dynamic Plugins Manager (三) Demo (6)
• 2005年02月2日 -- RICHEDIT中插入GIF (2)
• 2010年04月22日 -- 发放腾讯微博邀请三枚 (29)
• 2004年12月28日 -- 关于Debug和Release之本质区别的讨论 (1)
• 2006年01月10日 -- 电影《爱有天意》（不可不信缘） (5)
• 2006年02月23日 -- 再谈非模态对话框的销毁 (4)
• 2006年07月17日 -- 闷热的夏天 (4)
• 2004年10月21日 -- 枚举注册表键名与键值 (2)
• 2010年02月13日 -- Happy New Year！2010 (20)
• 2010年06月14日 -- BurstNET和Linode VPS的UnixBench测试 (6)

1.Foreach方法
首先上场的是Foreach，在使用Linq的时候，太容易派上用场了。比如，在使用Linq to Sql查询后，我们常常需要遍历结果，然后输出，代码如下：

1
2
3
4
5
6
7

DataClassDataContext ctx = new DataClassDataContext();
var result = ctx.Products.Where(p => p.ProductID >= 10);
 
foreach (var product in result)
{
    Console.WriteLine(product.ProductName);
}

自从有了Foreach，可以节省不少的力气了：

1
2

DataClassDataContext ctx = new DataClassDataContext();
ctx.Products.Where(p => p.ProductID >= 10).ForEach(p => Console.WriteLine(p.ProductName));

Foreach代码如下:

1
2
3
4
5
6
7

public static void ForEach<T> (this IEnumerable<T> source, Action<T> action)
{
        foreach(var item in source)
        {
            action(item);
        }
}

2.In方法
判断某个类型的变量是否在一个序列中

1
2
3
4
5
6

string [] names = new string[] {"Andy", "Timothy", "Ben", "Rex", "Ven", "Ken"};
 
if(names.Contains("Timothy"))
{
    Console.WriteLine("Found!");
}

使用In方法:

1
2
3
4

if ("Timothy".In("Andy", "Timothy", "Ben", "Rex", "Ven", "Ken"))
{
    Console.WriteLine("Found!");
}

In方法代码如下:

1
2
3
4

public static bool <T>(this T t, params T[] c)
{
    return c.Contains(t);
}

3.WinForm下的控件选择器(摘自 博客园-鹤冲天 的博客 http://www.cnblogs.com/ldp615/archive/2009/11/08/1598596.html)

1
2
3
4
5
6
7
8
9
10
11
12

public static IEnumerable<T> GetControls<T>(this Control control, Func<T, bool> filter) where T : Control
{
	foreach (Control c in control.Controls)
 	{
		if (c is T&&(filter == null||filter(c as T)))
		{
 			yield return c as T;
 		}
 		foreach (T _t in GetControls<T>(c, filter))
 		yield return _t;
 	}
}

使用方法：

1

this.GetControls<Button>(null).ForEach(b => b.Enabled = false);  //禁用界面上所有Button控件

你可能也对下列文章感兴趣

• 2010年01月17日 -- 扩展方法收集–实体验证 (8)
• 2009年09月28日 -- 扩展方法使用小结 (0)
• 2010年06月23日 -- Objective-C 学习笔记(一) 第一个Hello World程序 (14)
• 2009年05月29日 -- C# IDE Mobile – Write your C# code anywhere! (0)

而这些特性，都为LINQ的推出，构建好了基础。其中一个比较不错的特性，就是扩展方法。扩展方法，顾名思义，就是在类型定义完成之后，再继续为其添加新的方法。这是相当方便的，比如对于一个已经封装好的Assembly来说，我们不用改动Assembly的代码，而通过扩展方法就能实现对其功能的扩展，而且在调用的时候，仅仅通过代码，你几乎判断不出这是扩展方法，还是Assembly本身的方法。

扩展方法在.Net 3.5中的应用也是非常普遍的，如果你仔细观察，就会发现我们常用的Linq to Object中的Where,Select,Average,Sum等方法，以及Linq to SQL中的Where,Select,Average,Sum等方法，其实都是扩展方法，他们分别定义于System.Linq.Enumerable类和System.Linq.Queryable类之中。

就扩展方法本身而言，也存在一些限制之处。对于编译器来说，如果扩展方法和被扩展类型的方法发生冲突的时候，在调用此方法的时候，究竟是调用被扩展类型的方法，还是扩展方法呢？通过一个例子，我们就能发现其中的区别。

   1:    class Program

   2:      {

   3:          static void Main(string[] args)

   4:          {

   5:              new TestClassA().Display("Test");

   6:              new TestClassB().Display("Test");

   7:              Console.ReadLine();

   8:          }

   9:      }

  10:  

  11:      class TestClassA

  12:      {

  13:          public void Display(int b)

  14:          {

  15:              Console.WriteLine("This is TestClassA.Display() ...");

  16:          }

  17:      }

  18:  

  19:      class TestClassB

  20:      {

  21:          public void Display(string s)

  22:          {

  23:              Console.WriteLine("This is TestClassB.Display() ...");

  24:          }

  25:      }

  26:  

  27:      static class TestClassExtention

  28:      {

  29:          static public void Display(this object o, string s)

  30:          {

  31:              Console.WriteLine("This is TestClassExtention.Display() ...");

  32:          }

  33:      }

程序输出：

可以看出,TestClassA的方法和扩展方法并没有冲突，因为他们的方法签名是不一样的，而TestClassB的方法和扩展方法有冲突，因为他们的都是接受一个string类型的输入参数。从结果可以看到，程序对Display的方法调用，TestClassB本身的Display方法，要“优先”于扩展方法Display被调用。因此，类本身的方法如果满足调用条件，那么这个方法会被优先执行，只有在类当中无法找到同样参数的方法时，扩展方法才有机会被执行。所以，我们可以得出这样的结论：扩展方法的优先级较低，也即扩展方法不会覆盖同名的类本身的方法。

另外，还有一个比较明显的区别，就是扩展方法要远远弱于类本身的方法，比如，在一个类中，类的方法可以访问自己的非公有成员，而扩展方法做不到这一点。

你可能也对下列文章感兴趣

• 2010年01月17日 -- 扩展方法收集–实体验证 (8)
• 2009年11月14日 -- 常用扩展方法收集&整理(置顶-不断更新) (35)

The page you are requesting cannot be served because of the extension configuration.
If the page is a script, add a handler. If the file should be downloaded, add a MIME map. 

这种错误应该是.svc文件没有映射到相关的handler上，因此IIS不知道怎么处理该请求。带着错误信息，在网上搜索了一把，终于找到了解决方法，看来搜索引擎很强大。

解决方法如下：

1.用管理员身份运行cmd命令行

2.切换到目录C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation

3.运行命令： servicemodelreg –i

这样，工具会自动把WCF相关的注册项安装到IIS7中，再打开浏览器访问WCF Service，一切正常。

细想了一下自己的装机过程，先装了VSTS和.net framework，后来发现IIS7没有在windows7里面默认安装，要到部署WCF的时候，才装好IIS7。这样在安装.net framework 3.0的时候，因为没有安装IIS7，所以一些注册项就没有起到作用。此方法可以将WCF的配置项重新配置到IIS7中，供同学们参考。

你可能也对下列文章感兴趣

• 2009年11月17日 -- 关于Win7 天气插件的问题 (4)

* 可以创建基于图形用户界面的程序

* 可创建方法和类

* 可以调用所有的.NET Compact Framework的类。

* 执行文件操作

* 运行进程

* 使用.NET 2.0中的范型

* 支持C#的控制语句，包括循环、条件判断……

IDE的使用非常简单，写入你的代码，然后可以立即运行，看到结果。

简单的例子，如下：

   1:  using System.Windows.Forms;

   2:  namespace TestNS

   3:  {

   4:      class TestCL

   5:      {

   6:         public static void Main()

   7:         {

   8:              MessageBox.Show("Hello Timothy!");

   9:         }

  10:      }

  11:  }

点击菜单下面的Debug->Run,运行结果截图如下：

IDE自带一些简单的功能， 包括插入代码模板，编辑(复制、粘贴、剪切)功能，还支持插件功能。

软件下载地址： http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile.zip

Code Sample: http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile_samples.zip

用户手册、帮助文档地址： http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile_manual/index.htm

作者主页：http://www.geocities.com/hrowson/wm5_software/index.htm

赶紧下载吧，write your C# code anywhere! 活活~~

你可能也对下列文章感兴趣

• 2010年06月23日 -- Objective-C 学习笔记(一) 第一个Hello World程序 (14)
• 2010年02月12日 -- WM6.5 短信聊天模式切换 (10)
• 2009年12月30日 -- 手机ROM更新至WM6.5-28011 (8)
• 2009年11月14日 -- 常用扩展方法收集&整理(置顶-不断更新) (35)
• 2009年10月29日 -- 手机刷机到WM 6.5-23502 (3)
• 2009年07月13日 -- Visual Studio IDE配色方案 (9)

容器的RegisterType函数包含多个支持泛型的重载，同时还包含了一一对应的非泛型重载。其中的重载函数，我们可以看到类似下面的声明：

   1:  RegisterType<TFrom, TTo>(LifetimeManager lifetime)

参数中的LifetimeManager类型，就是用来控制注册类型生命周期的。Unity中提供了几个继承自LifetimeManager的类作为注册类型的生命周期管理器。在目前的Unity 1.2版本中，共提供了3个LifetimeManager供我们直接在代码中调用。此外，我们也可以实现自己的LifetimeManager，不过必须实现LifetimeManager所必须的一些方法。

1.ContainerControlledLifetimeManager:

容器负责管理注册类型的生命周期，并且注册类型的生命周期和容器一致。当离开容器的作用域范围时，容器会被销毁，同时其中的注册类型也会被销毁。或者，当容器被显式销毁时，其中的注册类型也同样被销毁。但是在容器有效的作用域范围中，当我们使用Resolve方法，或者使用ResolveAll方法获取我们的注册类型的时候，容器会在第一次调用时，创建实例，但是在后面的调用中，我们始终只会得到相同的实例。我们可以利用这种Manager来实现Singleton模式。

2.ExternallyControlledLifetimeManager:

和上一种方式类似，不过容器在不会保留对注册类型的强引用，而只是保留弱引用。也就是说，如果这个注册类型没有在其他地方被强引用的时候，那么这个注册类型可能会被GC给干掉。

3.PerThreadLifetimeManager:

容器保证在每个线程中返回同一个对象实例，那么在不同的线程中，得到的实例是不同的。

下面我们可以试验一下不同的LifetimeManager的效果

a. 默认的情况，不显示的指明LifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType<INotify, EmailNotify>();

   9:  

  10:              INotify notify1 = container.Resolve<INotify>();

  11:  

  12:              INotify notify2 = container.Resolve<INotify>();

  13:  

  14:              Console.WriteLine("notify1:" + notify1.GetHashCode());

  15:              Console.WriteLine("notify2:" + notify2.GetHashCode());

  16:  

  17:              Console.ReadLine();

  18:          }

  19:      }

  20:  }

运行结果：

从结果我们可以看到，默认情况下不指定LifetimeManager的时候，每次我们获得的Instance其实不是同一个Instance.

b.使用ContainerControlledLifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType<INotify, EmailNotify>(new ContainerControlledLifetimeManager());

   9:  

  10:              INotify notify1 = container.Resolve<INotify>();

  11:  

  12:              INotify notify2 = container.Resolve<INotify>();

  13:  

  14:              Console.WriteLine("notify1:" + notify1.GetHashCode());

  15:              Console.WriteLine("notify2:" + notify2.GetHashCode());

  16:  

  17:              Console.ReadLine();

  18:          }

  19:      }

  20:  }

运行结果:

使用ContainerControlledLifetimeManager，在Container生命中期内，我们得到的Instance是同一个。

c.使用PerThreadLifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType<INotify, EmailNotify>(new PerThreadLifetimeManager());

   9:  

  10:              Thread thread1 = new Thread(new ParameterizedThreadStart(ThreadProc1));

  11:              Thread thread2 = new Thread(new ParameterizedThreadStart(ThreadProc2));

  12:  

  13:              thread1.Start(container);

  14:              thread2.Start(container);

  15:  

  16:              Console.ReadLine();

  17:          }

  18:  

  19:          static void ThreadProc1(object obj)

  20:          {

  21:              INotify notify1 = (obj as IUnityContainer).Resolve<INotify>();

  22:              INotify notify2 = (obj as IUnityContainer).Resolve<INotify>();

  23:  

  24:              Console.WriteLine("ThreadProc1 --- notify1:" + notify1.GetHashCode());

  25:              Console.WriteLine("ThreadProc1 --- notify2:" + notify2.GetHashCode());

  26:  

  27:          }

  28:  

  29:          static void ThreadProc2(object obj)

  30:          {

  31:              INotify notify1 = (obj as IUnityContainer).Resolve<INotify>();

  32:              INotify notify2 = (obj as IUnityContainer).Resolve<INotify>();

  33:  

  34:              Console.WriteLine("ThreadProc2 --- notify1:" + notify1.GetHashCode());

  35:              Console.WriteLine("ThreadProc2 --- notify2:" + notify2.GetHashCode());

  36:          }

  37:      }

  38:  }

运行结果：

 在结果中可以看到，同一个线程中连续两次获取到的是同一个Instance，而不同的线程中获取到的Instance不一样。

你可能也对下列文章感兴趣

• 2009年04月25日 -- Unity 学习笔记(2) — 配置文件的使用 (4)
• 2009年04月23日 -- Unity 学习笔记(1) — Unity简介及简单使用 (0)

   1:  using System.Configuration;

   2:  using Microsoft.Practices.Unity.Configuration;

此外，需要修改应用程序的配置文件：

在configSections节点中，加入Unity的section配置信息

<configSections>
...
<section name="unity"
type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>
<configSections>
...
<section name="unity"
type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>

其中name是section的名称，type就是处理该section的程序类型，Unity提供了UnityConfigurationSection，负责处理配置文件信息，它包含在程序集Microsoft.Practices.Unity.Configuration中

接下来，需要在configuration节点中增加Unity配置节点，格式如下：

   1:  <unity>

   2:      <typeAliases>

   3:        <typeAlias alias="" type="" />

   4:      <typeAliases />

   5:      <containers  >

   6:        <container>

   7:           <types>

   8:             <type type="" mapTo="" />

   9:           </types>

  10:           <instances>

  11:             <add name="" type="" value="" />

  12:           </instances>

  13:        </container>

  14:      </containers>

  16:  </unity>

unity的子元素，包含节点大致如上，其宗typeAliases是type别名，能够简化下面types中type的配置。containers节点中可以包含多个container的配置。container主要包含的子元素有types元素，instance元素，types元素可以包含多个type元素，用以添加注册类型，instance主要用来添加实例到容器中。type元素，主要包含四个属性：

name：表示注册类型的名称，此属性在配置中可选。

type:注册的源类型

mapto:注册的目标类型

lifetime:设置注册类型的生命周期

此外，还有instances元素，包括name,type,value,typeConverter四个属性。value表示注册实例的初始值，typeConverter是用以转换提供的值到实例的匹配类型的类型转换器。

具体的元素含义，可以参考Unity的帮助文档。

下面我们还是采用Monitor的例子，来实现用配置文件注册类型，配置文件示例：

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <configSections>

   4:      <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />

   5:    </configSections>

   6:  

   7:    <unity>

   8:      <containers>

   9:        <container>

  10:          <types>

  11:            <type type="UnityDemo.IMonitor,UnityDemo" mapTo="UnityDemo.Monitor,UnityDemo" />

  12:            <type type="UnityDemo.INotify,UnityDemo" mapTo="UnityDemo.EmailNotify,UnityDemo" />

  13:          </types>

  14:        </container>

  15:      </containers>

  16:    </unity>

  17:  

  18:  </configuration>

程序代码修改如下：

   1:  using System;

   2:  

   3:  using Microsoft.Practices.Unity;

   4:  using Microsoft.Practices.Unity.Configuration;

   5:  using System.Configuration;

   6:  

   7:  namespace UnityDemo

   8:  {

   9:      class Program

  10:      {

  11:          static void Main(string[] args)

  12:          {

  13:              IUnityContainer container = new UnityContainer();

  14:              UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

  15:              section.Containers.Default.Configure(container);

  16:  

  17:              IMonitor monitor = container.Resolve<IMonitor>();

  18:              monitor.Alarm();

  19:  

  20:              Console.ReadLine();

  21:          }

  22:      }

  23:  }

编译运行结果：

使用配置文件，还有许多方便的地方，比如对于程序的扩展而言，新增的模块不再需要修改已编译好的程序，而只需要修改配置文件就可以方便的实现新模块的注册，对于系统的稳定性和可维护性都非常有好处。

你可能也对下列文章感兴趣

• 2009年04月28日 -- Unity 学习笔记(3) — 生命周期管理 (0)
• 2009年04月23日 -- Unity 学习笔记(1) — Unity简介及简单使用 (0)
• 2004年12月26日 -- 得到指定文件的信息 (2)
• 2004年11月29日 -- 判断是否为文件夹或者文件 (0)
• 2004年10月26日 -- 从文件装载图象 (0)

在平常的软件编码过程中，程序的逻辑往往很复杂，尤其是大型项目的开发中，一个模块常常会去引用其他的模块，假设我们有一个监控器类，用来监控CPU的温度，当温度达到预警的范围时，监控器有一个报警的方法，方法里面通过短信提醒器，以发送短信的方式通知维护人员。于是就出现了下面这样一段最为常见的代码：

   1:  public class Monitor

   2:  {

   3:         public void Alarm()

   4:         {

   5:                 SMSNotify notify = new SMSNotify();

   6:                 notify.Send();

   7:          }

   8:  }

在Monitor类中，直接引用到了一个短信提醒器的类，这是最为不灵活和最不易于扩展的一种方式。或许我们想到了面向接口编程，利用多态的好处，可以提供灵活的不同子类的实现，增加代码扩展性等等。但是说到底，接口一定是需要实现的，也就是如下语句迟早要执行：

   1:  public void Alarm()

   2:  {

   3:         INotify notify = new SMSNotify();

   4:         notify.Send();

   5:  }

这样看来，在实现INotify这个接口的时候，仍然需要具体的类来实现，而这样的代码在程序编译的时候就已经固定下来，如果以后需要使用新的提醒器，仍旧需要修改源代码并重新编译。并且在我们的Monitor类中，明显依赖SMSNotify类，二者之间的耦合度非常紧密。因此Ioc(控制反转)模式被提出用来解决这种问题，也即把接口的具体实现延缓到运行时，接口的实现类是在运行时被装载的。这样，就算有了新的实现类，也不需要更改调用者的代码(可以在Unity中使用配置文件的方式实现)。这种Ioc模式可以被形象的比喻为：接口就像一个空壳，而在具体实现时，向这个空壳注入内容，而让它成为一个真正的实体。这种模式也被形象的称为：依赖注入。通过使用Unity，我们能构建松耦合的软件，并且对象之间相互关联的细节，我们也不必关心，可以交由依赖注入容器全权负责。

前面也提到了依赖注入常用的三种形式：构造器注入、属性注入和方法调用注入，我们可以通过例子来实现这三种形式的注入。还是以上面的场景为例，我们的几个类和接口如下图：

1.Constructor Injection

IMonitor接口定义：

   1:  public interface IMonitor

   2:  {

   3:      void Alarm();

   4:  }

Monitor类：

   1:  public class Monitor : IMonitor

   2:  {

   3:      private INotify notify;

   4:  

   5:      public Monitor(INotify n)

   6:      {

   7:          notify = n;

   8:      }

   9:  

  10:      public void Alarm()

  11:      {

  12:          notify.Send();

  13:      }

  14:  }

INotify接口定义：

   1:  public interface INotify

   2:  {

   3:      void Send();

   4:  }

EmailNotify类：

   1:  public class EmailNotify : INotify

   2:  {

   3:      public void Send()

   4:      {

   5:          Console.WriteLine("Send Email Notify...");

   6:      }

   7:  }

SMSNotify类：

   1:  public class SMSNotify : INotify

   2:  {

   3:      public void Send()

   4:      {

   5:          Console.WriteLine("Send SMS Notify...");

   6:      }

   7:  }

可以看到，在Monitor类的构造函数里面，传入的参数是一个INotify接口类型，Alarm方法，调用了实现类的Send方法，但具体调用哪一个实现类的Send方法，只有在注入实体后才知道。Unity容器中，通常使用RegisterType和Resolve方法来分别注册和获取实例，并且这两个方法有很多泛型和非泛型的重载，具体的类型和参数，可以参考Unity的官方帮助文档。

现在我们向Monitor的构造函数注入实现INotify接口的实例:

   1:  static void Main(string[] args)

   2:  {

   3:      IUnityContainer container = new UnityContainer();

   4:      container.RegisterType<IMonitor, Monitor>().RegisterType<INotify, SMSNotify>();

   5:  

   6:      IMonitor monitor = container.Resolve<IMonitor>();

   7:      monitor.Alarm();

   8:  

   9:      Console.ReadLine();

  10:  }

代码中我们注入的INotify实例是SMSNotify类的实例，然后调用monitor.Alrarm()，里面会调用notify.Send().
运行查看结果：

上面是针对单个构造函数的情况，如果有多个构造函数，需要指明哪个构造函数是需要被注入的,也即需要在指定被注入的构造函数加上attribute:InjectionConstructor

   1:  public Monitor(INotify n, string name)

   2:  {

   3:      notify = n;

   4:  }

   5:  

   6:  [InjectionConstructor]

   7:  public Monitor(INotify n)

   8:  {

   9:      notify = n;

  10:  }

运行后可得到一样的结果.

2.Property Injection

通过属性注入，我们需要加上attribute: Dependency，使得Unity容器在获取类对象实例时，自动实例化该属性所依赖的对象，并注入到属性中。

修改Monitor类,实现下面的代码：

   1:  public class Monitor : IMonitor

   2:  {

   3:      [Dependency]

   4:      public INotify Notify { get; set; }

   5:  

   6:      public void Alarm()

   7:      {

   8:          Notify.Send();

   9:      }

  10:  }

再在Main函数里面，修改原有的代码，这次我们让容器注入EmailNotify实例：

   1:  container.RegisterType<INotify, EmailNotify>();

运行查看结果：
还有一个比较方便的地方，可以为Dependency特性指定名称，这样，在注入时，会将RegisterType所指定的对应名称的实体进行注入，例如：

   1:      public class Monitor : IMonitor

   2:      {

   3:          [Dependency("SMS")]

   4:          public INotify Notify { get; set; }

   5:  

   6:          public void Alarm()

   7:          {

   8:              Notify.Send();

   9:          }

  10:      }

修改Main函数，在RegisterType函数中指定注入名称:

   1:              container.RegisterType<INotify, EmailNotify>("Email");

   2:              container.RegisterType<INotify, SMSNotify>("SMS");

运行查看结果：

3.Method Call Injection

Method Call Injection注入的时机和Constructor Injection有一定的区别，构造函数注入，是在容器创建实例的时候，而方法调用注入，是在方法被调用的时候。实现方法调用注入，需要在指定注入的方法前加上attribute: InjectionMethod

修改Monitor类的代码如下：

   1:      public class Monitor : IMonitor

   2:      {

   3:          private INotify notify;

   4:  

   5:          [InjectionMethod]

   6:          public void GetNotify(INotify n)

   7:          {

   8:              notify = n;

   9:          }

  10:  

  11:          public void Alarm()

  12:          {

  13:              notify.Send();

  14:          }

  15:      }

在程序运行时，容器会自动实例化GetNotify方法所依赖的对象，并自动调用该方法，将其注入到方法中。

Main函数如下：

   1:          static void Main(string[] args)

   2:          {

   3:              IUnityContainer container = new UnityContainer();

   4:              container.RegisterType<IMonitor, Monitor>();

   5:              container.RegisterType<INotify, EmailNotify>();

   6:  

   7:              IMonitor monitor = container.Resolve<IMonitor>();

   8:              monitor.Alarm();

   9:  

  10:              Console.ReadLine();

  11:          }

运行查看结果：

你可能也对下列文章感兴趣

• 2009年04月28日 -- Unity 学习笔记(3) — 生命周期管理 (0)
• 2009年04月25日 -- Unity 学习笔记(2) — 配置文件的使用 (4)

利用SQL脚本内置的几个函数，我们能灵活的对日期进行计算和比较。常用的几个函数：GETDATE(),DATEDIFF(),DATEADD()

GETDATE() 当然顾名思义，得到当前的日期，返回类型是DateTime类型。

DATEDIFF ( datepart , startdate , enddate ) 用于判断在两个日期之间存在的指定时间间隔的数目。

第一个参数是指定时间间隔的类型,例如mm(月),dd(天)，yy(年),ms(毫秒）,ss(秒），不同的间隔类型，返回的结果也不一样。

DATEADD (datepart , number, date ) 用于日期运算的函数，将传入的日期，加上指定时间间隔数目的日期。

例如，计算得到本年的第一天：

Select DATEADD(yy, DATEDIFF(yy,0,getdate()), 0)

我们来分析下这个SQL语句就可以知道，首先从最里面的getdate()开始，getdate()得到当前日期和时间，外层的datediff，计算当前日期和1900-01-01 00:00:00之间的时间间隔，返回单位是以年来统计的，如果我们分开看DATEDIFF(yy,0,getdate()),0)的结果，返回就是:109。返回的109，传递给最外层的DATEADD函数，将1900-01-01 00：00：00加上109年，得到的结果，自然就是2009-01-01 00:00:00了，也即本年的第一天。

同样，灵活的利用这几个函数的组合，我们可以得到不同的结果：

得到当月的第一天：Select DATEADD(mm, DATEDIFF(mm,0,getdate()), 0)

得到当前季度的第一天：Select DATEADD(qq, DATEDIFF(qq,0,getdate()), 0)

得到当天的起始时间： Select DATEADD(dd, DATEDIFF(dd,0,getdate()), 0)

得到上个月最后一天： Select DATEADD(ms,-3,DATEADD(mm, DATEDIFF(mm,0,getdate()), 0))

得到上个月的第一天： Select DATEADD(m,-1,DATEADD(mm, DATEDIFF(mm,0,getdate()), 0))

其原理就是得到当月第一天，再减去三毫秒(SQL的时间以3毫秒为一个单位)，这样以当前为2月，得到的结果就是：2009-01-31 23:59:59.997

得到去年的最后一天： Select DATEADD(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate()), 0))

得到本月的最后一天： Select DATEADD(ms,-3,DATEADD(mm, DATEDIFF(m,0,getdate())+1, 0))

得到本年的最后一天： Select DATEADD(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate())+1, 0))

得到本月的第一个星期一： Select DATEADD(wk, DATEDIFF(wk,0,DATEADD(dd,6-datepart(day,getdate()),getdate())), 0)

随机日志

• 2005年01月11日 -- 定制自己的EXE文件 (0)
• 2004年12月29日 -- 堆和栈的区别 (0)
• 2006年07月16日 -- 今天把Blog界面更新了 (0)
• 2009年10月25日 -- WordPress下的第一篇日志 :-) (7)
• 2006年07月17日 -- VC雕虫小技：模拟MSN闪屏效果 (1)
• 2009年04月21日 -- WAP Access is available! (0)
• 2010年05月2日 -- Ubuntu 10.04 LTS 安装手记及体验 (14)
• 2007年09月23日 -- 本本拆机攻略 (1)
• 2007年07月18日 -- 新书推介 (0)
• 2005年06月21日 -- MyDetective V1.0 (1)

以往的部署WCF Service的方式，大家一般会想到以下几种：
1. 使用WinForm或者控制台程序作为宿主
2. 使用Windows Service作为宿主
不管我们用怎样的方式来作为WCF Service的宿主，少不了的麻烦，都是需要单独编写Host程序，除此之外，就该轮到WAS了。WAS在Vista中，其实是由一个单独的Windows Service来实现的，如果我们仔细找找，就能找到，Windows Service的名称，就叫做"Windows Process Activation Service"。由此看来，WAS的进程和IIS进程在物理上是隔离开的，能为我们提供一个灵活、稳定的WCF Service宿主环境。WAS内部的工作机制，大致和ASMX WebService类似。

简单了解了WAS的特性，下面我们用一个netTcpBinding的WCF示例来演示怎样利用WAS来Host WCF Service:

首先，我们需要查看Vista的组件中，是否打开了WAS的功能，打开控制面板，打开“程序和功能”对话框，在"打开/关闭 Windows功能"对话框中，确保下面图中的功能项被打开：

其实在这一部操作之后，windows会自动帮我们在IIS中做好配置，不过为了放心，我们还是打开IIS确认一下设置是否正确。

首先是检查IIS站点中的绑定：

确保net.tcp方式，绑定到808端口

打开站点的高级设置，确认"已启用的协议"中，填有"net.tcp"，没有的话，可以补上。

然后是建立应用程序目录，这个目录等下会用来部署WCF的Service端程序。建立好目录后，也在"高级设置–已启用的协议"中，填上net.tcp

到这里，基本的host环境我们已经设置好了。下面来实现我们的服务端和客户端。

建立Contract
[code]
[ServiceContract]
public interface IService1
{
[OperationContract]
string SayHello(string value);
}
[/code]

实现简单的Service类
[code]
public class Service1 : IService1
{
public string SayHello(string value)
{
return string.Format("Hello,{0}", value);
}
}
[/code]

建立svc文件
[code]
<%@ ServiceHost Language="C#" Debug="true" Service="WCFLibrary.Service1" CodeBehind="./App_Data/Service1.cs" %>
[/code]

服务端的WCF配置
[code]










bindingConfiguration="NetTcpBinding" contract="WCFLibrary.IService1">






















[/code]

其实endpoint只需要一个即可，为了方便通过svcutil.exe生成客户端代理，需要通过另外一个endpoint的mexTcpBinding来暴露元数据。这样当服务在发布好的时候，我们可以通过
Svcutil.exe net.tcp://Timothy-T61/WCFService/HelloService.svc/mex 来生成客户端代理了。

完成服务端的编写，直接将服务端程序，部署到刚才在IIS中添加的应用程序目录中。

客户端的wcf配置如下：
[code]









bindingConfiguration="ClientBinding" contract="WCFLibrary.IService1" />

[/code]

客户端拖放一个按钮，添加如下代码:
[code]
private void button1_Click(object sender, EventArgs e)
{
ClientProxy client = new ClientProxy();
MessageBox.Show(client.SayHello("Timothy!"));
}
[/code]

一切就绪，运行程序，点击按钮:

没有单独编写host程序，通过WAS，我们的服务端正常运行了。

随机日志

• 2010年06月23日 -- iPhone更新至OS 4.0 (4)
• 2009年02月22日 -- SQL中的日期计算 (0)
• 2007年09月22日 -- .NET开发常见问题两则 (1)
• 2005年01月31日 -- 根据文件句柄，获取文件名 (2)
• 2008年07月3日 -- Linq to SQL 的更新冲突与管理 (0)
• 2004年09月7日 -- 自增操作的反汇编分析 (0)
• 2005年10月31日 -- MVP有感 (0)
• 2004年10月16日 -- 屏蔽WIN、ALT+TAB、CTRL+ESC键的低级键盘钩子 (0)
• 2010年07月3日 -- BlackBerry 系统刷至OS5.0.0.681 (2)
• 2005年11月11日 -- 半透明渐变的窗口效果 (0)

在测试表中，插入一条测试数据(如图)

测试代码如下：

[code]
namespace LinqTest
{
class Program
{
static void Main(string[] args)
{

TestDataContext db = new TestDataContext();

db.Log = Console.Out;
var result = from p in db.LinqTests
where p.ID == 1
select p;

var info = result.FirstOrDefault();

if(info != null) //插入断点
{
info.Age = 25;
db.SubmitChanges();
}

Console.ReadLine();

}

}

}
[/code]

在测试代码中，将DataContext的日志定向到Console的输出部分，这样方便我们观察Linq实际执行的SQL语句是什么。重现的时候，我们需要在注释的地方，插入断点进行测试。对于示例中的代码，在正常情况下，是不会有错误的。执行过后，我们可以在Console的输出中，看到实际执行的SQL语句(如图)

再进行第二次调试，首先，恢复Age的数据到以前的样子。下面我们运行到断点处，然后偷偷去SQL Server Management Studio中，手动修改数据，将原始数据中的Age，由24，改为22。然后回到VS2008的IDE，按F5继续运行程序，这个时候，你会发现异常出现了(如图)

再回到Console的输出，查看，执行的SQL语句和刚才的一样。这就是问题的所在，在正常运行状态下，Linq在运行时，会把数据库的数据缓存到实体对象中，这是一种理想化的情况，并且在更新时，Linq会默认把除更新字段外的所有字段，作为Update语句中的Where条件。但是，如果此时有另外的程序，在访问数据库，并修改数据库数据的时候，比如刚才把Age改为22。此时Linq缓存起来的数据和实际数据库中的数据产生了不一致的情况。Linq此时仍然把被修改过的字段，作为Update的Where条件，但是数据库中Age早就被我们改过了，不再是25，Where条件始终匹配不到原有的数据。这时，就会抛出所谓的：“System.Data.Linq.ChangeConflictException: Row not found or changed.”异常。

产生此异常，主要是Linq缓存数据和实际数据库数据不一致的情况造成。解决次问题的情况，主要有几种：

1.比较简单的方法，不使用Linq提供的SubmitChanges()方式提交更改，而直接执行SQL语句，例如：
db.ExecuteCommand("Update [dbo].[LinqTest] SET Age=25 Where ID = @p0", 1);
这样虽然比较方便，但是感觉又回到了直接写SQL的时代，毕竟Linq to SQL的目的，就是为了让我们看不见SQL，避免写复杂的SQL语句，而直接操作实体对象，这样也可以避免程序可读性差、不便于维护。所以除非万不得已，还是不太推荐使用此方法。

2.参考MSDN的资料，采用Linq提供的解决更新冲突的方法，在异常中捕获冲突，然后手动解决冲突：
[code]
try
{
db.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict);
}
catch (System.Data.Linq.ChangeConflictException ex)
{
foreach (System.Data.Linq.ObjectChangeConflict occ in db.ChangeConflicts)
{
//以下是解决冲突的三种方法，选一种即可

// 使用当前数据库中的值，覆盖Linq缓存中实体对象的值
occ.Resolve(System.Data.Linq.RefreshMode.OverwriteCurrentValues);

// 使用Linq缓存中实体对象的值，覆盖当前数据库中的值
occ.Resolve(System.Data.Linq.RefreshMode.KeepCurrentValues);

// 只更新实体对象中改变的字段的值，其他的保留不变
occ.Resolve(System.Data.Linq.RefreshMode.KeepChanges);
}

// 这个地方要注意，Catch方法中，我们前面只是指明了怎样来解决冲突，这个地方还需要再次提交更新，这样的话，值 //才会提交到数据库。
db.SubmitChanges();
}

[/code]

3. 这个方法也比较简单，也即MSDN中所说的Pessimistic Concurrency Control 。 我们可以来设定哪些字段需要放入Where条件，哪些字段不需要，这样就可以控制更新时候的条件匹配尺度。具体做法，就是在Linq to SQL Designer中，把一些字段的UpdateCheck属性设置为Never，这样，这些字段在更新的时候，就不会再出现在Where条件中了。其实比较推荐的做法，就是在表中设立主键，因为更新的时候，只要把主键作为Where条件，就可以单独的确立一行数据了。把除主键外的字段属性中UpdateCheck设置为Never即可。

关于Linq to SQL中如何管理更改冲突的更多资料，可以在MSDN找到

http://msdn.microsoft.com/zh-cn/library/bb399389.aspx

随机日志

• 2010年07月22日 -- WP-Reader-Wall 插件兼容 WordPress 3.0的修改 (8)
• 2009年12月25日 -- 手机版博客更新了插件 (8)
• 2005年11月14日 -- VC中用Flash Control播放FLASH (2)
• 2005年01月19日 -- 程序热键的实现 (0)
• 2005年12月27日 -- 诗篇23篇 (1)
• 2009年03月7日 -- Microsoft My Phone 体验 (0)
• 2005年06月16日 -- 设置网卡可以接收所有IP的数据(混杂模式) (0)
• 2007年02月8日 -- VC做的管理系统 (0)
• 2007年06月30日 -- 小福很受伤 (2)
• 2006年05月18日 -- MySnake 我的贪吃蛇 (1)

Parser Error
Description: An error occurred during the parsing of a resource required to service this
request. Please review the following specific parse error details and modify your source file
appropriately.

Parser Error Message: Could not load file or assembly 'Microsoft.ReportViewer.WebForms,
Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The system cannot find the file specified.

【解决方法】

进入你的开发使用机器的c:\windows\assembly目录查看，是否有以下程序集安装在GAC中（如图）：

由于资源管理器是使用了shell扩展来查看GAC中安装的程序集，所以我们无法看到这些程序集当前部署的真实目录在什么地方。我们可以直接在命令行模式中进行查看，进入X:\windows\assembly目录，然后查找和水晶报表相关的程序目录（如图）：

我们可以大致看到GAC的部署结构了。我们在浏览器中所看到的一个一个的assembly名称，其实对应于assembly目录下面的每一个目录命名。进入具体的目录，还有一级子目录，这个目录的命名，是根据发布到GAC的程序集的版本号加上后面的公钥标记组成。（见上图的下面的红色标记部分）

再进入子目录，我们就可以看到公有部署的程序集，所存在的真正位置了。（如图）：

接下来的工作就好办了，拷贝程序集到目标机器上，然后运行gacutil /i filename，将程序集安装到GAC即可。需要拷贝的程序集如下：

1) Microsoft.ReportViewer.Common.dll

2) Microsoft.ReportViewer.ProcessingObjectModel.dll

3) Microsoft.ReportViewer.WebForms.dll

随机日志

• 2004年12月21日 -- 用API实现繁体简体的转换 (0)
• 2007年12月23日 -- 意外 (0)
• 2008年03月29日 -- Dynamic Plugins Manager (二) 配置及实现分析 (0)
• 2006年07月16日 -- 今天把Blog界面更新了 (0)
• 2006年01月27日 -- 测试 Wireless Desktop Elite套件 (0)
• 2004年10月26日 -- 动态加载DLL (0)
• 2009年04月21日 -- WAP Access is available! (0)
• 2009年11月17日 -- 关于Win7 天气插件的问题 (4)
• 2010年07月6日 -- 相册搬迁到Linode (10)
• 2005年04月2日 -- 浏览对话框的调用实现 (2)