前段时间一直忙公司的一个项目，天天加班，以至于N久都没有更新博客了。
最近终于有时间继续研究我的Silverlight了，比较开心。
当然主题还是延续前面对我的Web象棋的探索了，哈哈。
经过两个的摸索终于摸索出了一个基本的Silverlight与WCF的简单通信方式，以及开发与部署方式希望能给和我一样一直在摸索的战友们一点启发。
首先既然说道Silverlight与WCF通信的基本的开发方式，就先说说在VS2008下怎么创建相应的工程了。也就是开发工程选择什么样的结构了。
方式1、先创建Silverlight工程，再创建相应的WCF。该种工程结构的参考主要来源于
Silverlight消费WCF，该例子中是将WCF服务以在Silverlight工程中创建Silverlight-enabled WCF Service方式引入。
该博文的作者例子挺详细的，我比着葫芦画个瓢还挺成功。哈！
当然这个例子显而易见开发模式比较简单明了，并且部署方式也很简单，对于小的应用应该来数是非常合适了。不过这个例子自我感觉有个比较不理想的地方就是，开发者开发的WCF服务，和Web App的Silverlight工程都被糅合在了一起，
首先从工程结构上来说是比较混乱的。服务方和消费者都被混在了一个工程里面。
这样开发最重要的一点缺陷就是WCF服务必须和Silverlight工程一起宿主在IIS服务上，而不能体现WCF本身可以宿主在Console App或是Windows Service只中这些比较特别的宿主内。
方式2、单独分别创建Silverlight工程和WCF工程。如下图：
在该项目里面创建了一个Silverlight工程，和WCF Service工程。看起来好像不过是简单的一个工程的分离，但是这个分离却出现了N多千奇百怪的问题。
问题1：默认创建出的WCF工程，在其Web.config文件中生成的
<endpoint address="" binding="wsHttpBinding" contract="WcfService1.IService1">
需要将其中的binding改为basicHttpBinding
同样，在Silverlight工程中引入WCF服务后，生成的ServiceReferences.ClientConfig中的
<client>
<endpoint address="http://66pw92x.chn.corp.ad/WCFService/Service1.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService1"
contract="ServiceRef.IService1" name="BasicHttpBinding_IService1" />
</client>
也需要将binding改为basicHttpBinding
问题2：分别在IIS上创建一个WCF工程虚拟目录，将工程内的WCF工程部署在IIS上后，必须要重新更新Silverlight工程的WCF的引用，该引用需要引入在IIS部署后的WCF工程的链接。
且应该重新编译Silverlight.Web工程，使更新后服务在Silverlight工程的部署包中更新。
问题3：部署完成WCF工程后，同样在IIS上创建Silverlight工程的虚拟目录。且将Silverlight工程部署该处。运行。。。。。。
始终出现的是脚本异常，奇怪，在开发环境上都OK的怎么部署上就不能运行，用Fiddler跟踪该Web请求发现出现的提示是无法访问跨域策略文件clientaccesspolicy.xml 和crossdomain.xml文件。
进过网上查找的解释，的确Silverlight访问其他虚拟目录下的服务或是其他域下的服务是必须通过跨域策略文件来确认是否能够访问的，如果不存在该文件或该文件配置的域不可访问，则Silverlight是无法消费该服务的。
OK，那就按网上办法添加策略文件了，将策略文件添加在哪里呢？应该是WCF服务的域根目录比较科学。那就加在我创建虚拟目录的根下。运行，结果依旧，任然无法找到策略文件。到底怎么回事，仔细看看Fiddler上的请求发现他请求的居然是整个IIS的根目录（GET /clientaccesspolicy.xml HTTP/1.1）（服务的请求URL为POST /WCFService/Service1.svc HTTP/1.1）。原来这个请求不是对WCF的虚拟目录的请求，而是对IIS提供的整个域的策略文件的请求。明白了，把两个文件拷贝到我本地的C:\inetpub\wwwroot下。运行，。。。。。。。。。。。。
终于大功告成！！
整个工程终于可以正常运行了。整个耗时10个小时，最后一点问题耗时5个小时。吐血！！！
这个开发方式终于可以流畅了。
对这个开发方式的总结，虽然比第一个开发方式多了不少的麻烦，但是如果搞清楚了，并且解决，那就能带来就是工程结构清晰，并且能够体现WCF工程任意宿主的优势。
希望这个总结能给还在摸索中的战士们一点帮助。
下次继续Silverlight消费WCF的 Duplex poll Service。希望能早日成功，更新Blog了，哈！
