将单独的 WCF 项目与 Silverlight 结合使用
我正在开发一个使用 WCF 的 Silverlight 应用程序。我需要将 WCF 项目与托管 Silverlight 项目的 ASP.Net 应用程序分开。我正在寻找一些关于如何组织解决方案的指导，并列出其他人在调试和部署过程中遇到的问题。
具体来说，我的问题是
我应该为 WCF 服务使用什么类型的项目？（WCF 项目、具有自托管 WCF 服务的 ASP.NET 项目，或者其他）
我需要什么才能获取它，以便当我按 F5 时我可以调试我的 Silverlight 项目和 WCF 服务吗？我是否需要一个跨域策略来调试该东西？
关于我为什么要这样做的一些背景信息：
我有一个遗留的 Web 应用程序，我正在逐渐将其转换为 Silverlight 应用程序。因为它是一个大型 Web 应用程序，所以它的某些功能将先于其他功能转换为 Silverlight。
旧版 Web 应用程序中有大量不再使用的代码。不再使用的许多代码引用了第三部分程序集。这就是为什么我想摆脱旧的网络应用程序。显然我不想在其中托管将为未来版本保留的 WCF 服务。这就是我想要将 WCF 项目分开的原因。
I am working on a Silverlight application that uses WCF. I need to have my WCF project separate from the ASP.Net application that will host my Silverlight project. I am looking for some guidance on how I should organize my solution and list gotchas other people have experienced during debugging and deployment.
Specifically my questions are
What type of project should I use for the WCF service?(A WCF project, an ASP.NET project with self-hosted WCF services, something else)
What do I need to so to get it so that when I press F5 I can debug both my Silverlight project and my WCF service? Will I need a cross-domain policy just to debug the thing?
Some background info on why I want to do this:
I have legacy web application that I am gradually converting over to a Silverlight application. Because it is a large web application some of its features will be converted to Silverlight before others.
The legacy web application has lots of code in it that is no longer used. Much of the code that is no longer used references 3rd part assemblies. This is why I want to get rid of the old web application. So obviously I don't want to host WCF services that will be kept for future versions in it. That is my reason for wanting to make the WCF project separate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们正在做完全相同的事情。
2.a．您可以为 silverlight 项目和 wcf 项目提供解决方案。 silverlight 项目将在您的解决方案中提供对 wcf 服务的服务引用。这允许您使用 F5 进行调试。但是，当您进行部署时，您必须更改 app.config 服务 URI 以引用您的生产位置。
2.b.如果 wcf 服务和 silverlight 应用程序的完全限定域名不同，则仅需要跨域策略文件。我们的恰好不同。这是一篇关于何时使用策略文件的优秀文章： Clicky
祝你好运！
We're doing the exact same thing.
2.a. You can have a solution with your silverlight projects, and your wcf project. The silverlight project will have a service reference to the wcf service in your solution. That allows you to debug using F5. However, when you go to deploy, you will have to change your app.config service URIs to refer to your production location.
2.b. You will only need a cross-domain policy file if your fully qualified domain names are different for the wcf service and the silverlight app. Ours happen to be different. Here is an excellent article on when to use the policy file: Clicky
Good luck!
请记住，当您准备部署时，如果您的服务将托管在与应用程序不同的计算机上，则需要首先部署该服务。然后重新配置您的服务引用，最后在部署之前重新编译您的 Silverlight。否则，您的 Silverlight 应用程序将在本地计算机上查找该服务，而不是在您部署它的位置。
Just remember that when you get ready to deploy, if your service is going to be hosted on a different machine than your app, you need to deploy the service first. Then re-configure your service reference, and finally re-compile your Silverlight before deploying. Otherwise, your Silverlight app will look for the service on your local machine instead of where you deploy it.