我工作的公司创建了该应用程序，该应用程序是我们业务的核心，并依靠Web浏览器来执行某些"规则"，如果没有这些规则，则该应用程序对我们的客户来说就毫无用处。很抱歉，必须谨慎行事，NDA和许多其他事情使我无法确切地说出应用程序是什么。本质上，JavaScript控制某些定时事件(至少必须精确到至少第二个事件)，这些事件很难用ajax / postbacks等控制。

我的问题是：假设大多数代码实际上是C＃业务逻辑而不是asp.net控件，那么将ASP.NET应用程序转换为SilverLight有多困难？我刚听完Deep Fried字节，MS员工听起来好像没什么大不了的。这对于Web应用程序(或主要是Win32应用程序)是否适用？

我知道asp.net前端与SilverLight根本不同，但是有很多C＃代码我不想在必要时不必重写。我假设将javascript代码替换为silverlight是微不足道的(我知道错误的假设，但是我必须从某个地方开始)，因为它处理定时事件，因此我对此并不真正担心。我需要提出一种解决方案，以减轻这种问题，我希望这是一个中间立场：不采取任何措施，并看着我们受到客户的追捧，并以比网页更安全的方式重写整个应用程序仅前端验证。有没有人试图将ASP.NET代码转换为SilverLight项目？

如果您的应用程序大部分位于后端，则您仍应能够保持大部分代码不变，而仅替换前端。但是，Silverlight需要了解WPF，这与您的应用程序当前使用的HTML / JS截然不同。我想说的是，如果您的UI很薄，则应该很容易移植到Silverlight，但是UI中的业务逻辑越多，难度就越大。

将代码从ASP.NET移植到Silverlight并非易事。正如Nate指出的，这取决于ASP.NET应用程序中有多少基于AJAX，以及有多少基于服务器控件。

Silverlight是一种状态完整的客户端技术，这意味着一切都在浏览器内部的客户端上运行。 ASP.NET是一种服务器技术，它围绕请求/响应模型构建。由于这两个是完全不同的范例，所以这不是直截了当的。

但是，由于ASP.NET只是表单数据的HTML和HTTP POST，因此人们进行了实验，他们直接在ASP.NET页的顶部添加了Silverlight应用程序，并手动发送了确切的数据来手动构建HTTP POST请求ASP.NET应用程序的工作。这几乎就像为您自己的应用程序进行"屏幕抓取"。这可能有效，但不是最佳选择。您的ASP.NET应用程序将不得不针对每个请求经历整个页面周期，因此不会提高性能。

更好的替代方法是开始将用户在APS.NET应用程序中具有的所有功能包装为Web服务。您可以在ASPX页面旁边添加这些服务，然后逐步移植应用程序。您将基于这些服务从头开始构建的UI。

祝好运！

您使用了多少类库以及可能被视为"危险"的东西，例如pinvoke，文件系统访问和System.Diagnostics.Process？