我工作的公司创建了这个应用程序，它是我们业务的核心，并依赖于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项目？
答案 0 :(得分：1)
如果您的应用程序的大部分位于后端，您仍应该能够保持大部分代码完好无损，并且只能替换前端。但是，Silverlight需要了解WPF，这与您的应用当前使用的HTML / JS有很大不同。我想说如果你的UI非常薄，那么移植到Silverlight应该很容易，但是UI中的业务逻辑越多，它就越难。
答案 1 :(得分：0)
您使用类库以及可能被视为“危险”的事情有多大，例如pinvoke，文件系统访问和System.Diagnostics.Process？
答案 2 :(得分：0)
将代码从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。
祝你好运！