在 C# 上的 silverlight 功能中的 ruby
刚刚发现您可以在 SilverLight 应用程序中使用 Ruby 或 Python。
链接此处
..我想知道是否可以通过使用这些语言而不是 C# 来绕过一些 SilverLight 限制。
我知道 SilverLight 应用程序内的 Ruby 引擎已被精简，就像 .NET CLR 一样，所以我想知道即使没有完整 Ruby 或 Python 引擎的所有功能：
我还能做点什么吗 通过使用这些动态 我不会的语言 在 C# SilverLight 中？
.
如果我们需要下载构建的东西 由社区延长削减 down Ruby 实现（以支持 例如互操作调用？），什么是 对部署有何影响？
.
如果没有，如果你什么也做不了 除此之外，你无法使用 C# 和这些引擎 动态的典型好处 语言，而不是真正规避 的一些限制 SilverLight 的 CLR，为什么会 选择在 SilverLight 中使用 Ruby 应用程序？
我的兴趣点之一是套接字的使用，SilverLight 中的套接字使用在每个版本中都在改进，但由于服务器端需要 xml 授权文件，它仍然会很麻烦。ruby 是否能够使这一过程变得不必要？
谢谢，
里克
Having just found out that you can use Ruby or Python inside a SilverLight application..
link here
..I wonder if its possible to bypass some of the SilverLight limitations with use of these languages instead of C#.
I know that the Ruby Engine inside the SilverLight application is trimmed down, just as the .NET CLR is, so I would like to know that even without all the functionality of a full Ruby or Python Engine:
Can I still be able to do something
with the use of these dynamic
languages that I wouldn't be able to do
in C# SilverLight?.
If we need to download something built
by the community to extend the cut
down Ruby implementation (to support
Interop calls for instance?), what's
the impact on deployment?.
If not, if you cannot do anything
you wouldn't be able to with c#, with these engines, besides
the typical benefit of a dynamic
language, and not really circumventing
some of the restrictions of the
SilverLight's CLR, why would one
choose to use Ruby in a SilverLight
application?
One of my interest points is use of sockets, socket usage in SilverLight is improving in each version, but it can still be troublesome because of the xml authorization file required on the server side..would ruby be able to make this unnecessary?
Thanks,
Ric
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我怀疑你无法解决这个问题。请记住，施加限制的不是语言，而是运行时。准确地说，是 Silverlight 本身。由于在这种情况下 C# 和 Ruby 都被编译为 CIL，因此您或多或少拥有完全相同的功能（除了类型系统中的一些差异）。
I suspect you won't be able to work around that. Keep in mind that it's not the language imposing the limitations here but the runtime. TO be precise, it's Silverlight itself. Since both C# and Ruby are compiled to CIL in this case you're left with more or less the exact same capabilities (except some differences in the typing system).
我不确定你在说什么。无论使用哪种语言，您仍然在相同的“沙箱”、安全模型和 Silverlight 中相同的缩减库中运行。假设您的代码不违反任何语言的安全模型，您可以扩展您认为“有限”的位。
您也许可以使用另一种语言以不同的方式做事，但相同的基本限制仍然适用。
I'm not sure what you're getting at. Regardless of language you are still running inside the same "sandbox", security model and limited with the same cutdown libraries in Silverlight. You can extend the bits that you feel are "limited", assuming your code doesn't violate the security model, with any language.
You might be able to do things differently using another language, but the same basic constraints still apply.
您需要确保文件包含在 xap 中或使用 silverlight 3 slvx 系统来流式传输 C# 或 VB 等中定义的程序集。ruby
语言应该是完整的 ruby 实现，以便您可以使用 ruby 提供的所有语言功能，例如元编程等
所有源文件都需要包含在 xap 中才能工作。
如果您使用 ruby，那么您也会获得格式塔，并且您可以像今天在 html 页面中包含 javascript 文件一样包含 ruby 源文件。
You need to make sure the files are included in the xap or use the silverlight 3 slvx system to stream the assemblies defined in C# or VB etc.
The ruby language should be a complete ruby implementation so you can use all the language features ruby offers like metaprogramming etc.
All source files need to be included in the xap to work.
If you're using ruby then you get gestalt too and you can include ruby source files in the same way as you include javascript files in an html page today.
在 .NET 中使用动态语言的最佳方案之一是让用户使用自己的代码扩展应用程序，这就是我在 Silverlight 应用程序中使用 IronPython 的主要原因。能够在 Silverlight 的有限 .NET 运行时中使用它真是太好了。它确实很容易集成（尽管我很难让 C# 扩展方法对 Python 可见），而且它对用户来说非常强大。
One of the best scenario for the usage of dynamic languages in .NET is to let the users extend the application with their own code, so that's the main reason I use IronPython in my Silverlight application. It's so nice to have that available in the limited .NET runtime of Silverlight. It's really easy to integrate (although I had a hard time making C# extension methods visible to Python) and it can be very powerful for the users.