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
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).
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.
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.
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.
Related
I am a python programmer looking to make my first mobile app. I'd like to make make an app for both iOS and Android that looks and feels native. I thought I'd start with a simple iPhone app, just to see how everyting works. Mono seems like the obvious solution. However, I was surprised to find that almost all of the example Monotouch code I found, as well as the answers here on Stackoverflow, relied heavily on the IOS frameworks, essentially making the code not cross-platform at all. For example, I was looking into using a timer. All the examples I read use NSTimer. Surely this is possible to do in C# itself so that that part is cross platform? But then, why do all these people use NSTimer?
So, my question is, how cross platform is Mono development for IOS/Android? Is it still worth considering for smallish apps, or only for very large apps with lots of business logic?
Your question is too general. I'll answer it for two scenarios:
Specific examples
If you are looking for how do create timers, create arrays, traverse lists, then why not just look for regular .NET examples and compile this into a single class library that can be in both projects.
Sharing code as a whole
If you just mean in general sharing of code between the two platforms, you should look at frameworks that already have the templates and examples created for you. Two such patterns are http://www.monocross.net/ (MVC) and mvvmcross (MVVM). This can help you architect your project from the beginning to support cross-platform development (iOS, Droid, Wp7, desktop, etc).
There are timers, arrays, and strings in the .NET Base Class Library. As you have seen, there are some in the Cocoa library that MonoTouch wraps. For example you have your regular run of the mill string in .NET, but in monotouch you also have the option of NSString. I think to answer your question, the reason people may use the iOS specific types sometimes, is either because they weren't trying to make that code cross-platform and it was a matter of preference, or they had to do something specifically that required the use of that type which wouldn't be the case for everyone.
Mono's purpose isn't just to help with cross-platform development. I come from a C#/.NET background so even if I was building an app with one screen and two buttons, I would use MonoTouch because I would rather use C# with the .NET BCL than Obj-C. But that is my own personal choice and enough of a deciding factor, for me.
EDIT
I added the links.
I think the key point is that in order to use Mono and NOT use platform specific types etc like NSSTring you need a platform specific wrapper (abstraction layer) that lets you write code that only uses Mono types.
i.e. You are asking about using Mono but what you actually need are MonoTouch and MonoDroid (the frameworks referenced by #valdetero, depend on having those wrappers underpinning them).
iam developing WPF product. I want to protect my .net source code from reverse enginering
Please advice me
You would use an obfuscator. There are a lot of them on the market, just google.
For example, Visual Studio used to ship with the Dotfuscator Community Edition. I never used it, so I can't say anything about its quality.
This blog post shows the possible ways to try to prevent reverse engineering: http://blogs.msdn.com/b/ericgu/archive/2004/02/24/79236.aspx
In the end it will always be possible to reverse engineer the code. Obfuscation can help but your code will never completely be protected.
The only way to fully protect the code is by not deploying it but instead keeping it on a server.
Obfuscating your assemblies will ensure that it is difficult (if not impossible) to reverse-engineer your compiled assemblies. Obfuscators use techniques like symbol renaming, string encryption, control flow obfuscation to try to obfuscate the meaning of the original code. In some cases, it is even possible to totally hide the code from decompilers (however, decompilers are constantly evolving to overcome this).
Take a look at Crypto Obfuscator.
DISCLAIMER: I work for LogicNP, the developer of Crypto Obfuscator.
You can use FxProtect obfuscator. It successfully supports WPF and Silverlight obfuscation.
You can try it... .NET Obfuscator
Can I write programs in JavaFx or Flex with other languages (not ActionScript and JavaFX Script) like in Silverlight?
JavaFX can call Java and thus can call any code that generates Java classes. So you could in theory write code using JRuby or Groovy.
However, I would suggest that is not really how you could should JavaFx (or Flex). Rather you are really using these languages to build great UI using technologies that should be more reliable than AJAX/browser nightmares.
And that their real power comes when you are able to integrate them with back-end data sources (via REST/SOAP) that can be written in whatever language you want.
The question would be easier to answer if we understood why you would want to do this?
For JavaFX the answer is both yes and no, depending on what it is you want to achieve. JavaFX compiles to Java classes and in theory you can call the compiled JavaFX classes from any JVM language that can call Java classes. However, this isn't as simple as it sounds because some of the stunts they are pulling to implement the JavaFX language features make the implemented classes quite complex and the name mangling is not defined and subject to change. Any solution written this way would be very fragile.
However, much of the JavaFX functionality is based on pure Java libraries such as JMC (Java Media Components) for the media support and the scenegraph project (https://scenegraph.dev.java.net/) for the 2D scenegraph. These projects are written in Java and are much easier to call from Java and other JVM based languages.
I don't have any experience of Flex but as far as I know, you are stuck with MXML and ActionScript.
For flex you can only do MXML and Actionscript although there's an option to compile C/C++ code using Alchemy
I want to write a standalone GUI based app for administering one of the most popular enterprise middleware products from a very big company. But that big company already has a admin tool and its free.
But guess what , its very very slow , since its written on the java/Eclipse platform.
I want to write a very fast responsive GUI tool natively for windows.
I do not have much experience programming for windows , So what library(open source preferably) i can use on windows to get the job done.
Note: I need to write it in C, Not C++ , But if i dont have any choice I guess i can do with C++.
So I basically need to write a GUI app in C with some good GUI library.
Please help me out.
Thanks.
Edit : I do not know OOP and don't prefer using it.
Edit : So my choice is down to Win32API and Qt.
my requirement is that of a simple GUI , nothing fancy. I will be using simple windows ,buttons and menus. But I may need to do some processing , which means GUI should not take up much resources.
Based on this I m thinking of using Win32 API , even if I have to take the pain to hopefully satisfy the users.
its very very slow , since its written
on the java/Eclipse platform.
Are you sure that this is the reason for the application's slowness? I am no
fan of Java, but before you reach any conclusion, have you made sure that
writing the software in c makes it noticably faster? It could be that the
application is slow for reasons that are not under the control of the GUI programmer,
such as a slow database or bad network latencies.
Also, I don't mean to be rude here, but do
I want to write a very fast responsive
GUI tool natively for windows.
and
I do not have much experience
programming for windows
not contradict each other?
If you want to write a C GUI app, stick to Win32 or GTK+.
Win32 is blazingly fast, and will let you access everything available to Windows. Take a look at this tutorial.
GTK+ is extremely easy to use, cross platform, and provides tons of extra functionality. Start by downloading the all-in-one bundle, and move onto a tutorial and the documentation.
Personally I'd recommend going straight to Python if you need quick, responsive GUIs, and just need to wrap some lower level stuff.
Why are you limiting yourself to C? Windows Forms and WPF and SIlverLight are all viable UI frameworks that are responsive and have tons of books. There's a reason you can't find much info about writing GUI apps in C - people don't do it.
For plain C, cross platform, native look, simple, scriptable UI, I suggest to have a look at IUP: http://www.tecgraf.puc-rio.br/iup/
If you really have to use C then you can use GTK+. Otherwise, I'd suggest a C++ library like QT or wxWidgets. However, that being said I still think it would be preferable to build a .NET (Windows Forms or WPF) solution. They should provide a better UI experience than Java/Swing.
If you really want to do it in C, you could use the Win32 API. But it's hell working with it. The Object Oriented variant isn't much better either, but it takes away a bit of the pain (MFC).
I strongly recommend you to use C++ with the Qt library, which is both cross-platform and open-source (LGPL). C++ Qt GUI applications are as fast as native Win32 applications, although they take more memory. And you can't even start comparing the productivity gains - Qt is a great library, terrifically designed for GUI programming with tons of other useful tools.
Most GUI toolkits are written in C++, so restricting yourself to C will limit your options somewhat. One option that is cross platform and written in C is GTK; it's originally for X, but runs on Windows as well.
edit: Of course, you could always just program directly against the Windows API (formerly know as Win32) itself. For simple GUIs, it's not too bad.
GUI components map very well into Object oriented paradigm. Using C for GUI applications is a bad idea, I've been there and it's much more confortable to do it in an propper OO fashion with C++. Of course you can sort of do OO with C but it's ugly to say the least.
In my opinion, more than the GUI frameworks you need to really work on the design of the application you building.
For a normal GUI in C/C++ Win32 provides enough of controls for a decent looking application with good response time.
What you should really focus on is how to make it multi-thread based upon the time your modules take for execution.
Consider this small example: You have a DataBase connection monitoring in your GUI which is probed every second. Another module may be sending some big files to other applications. Now if an application is single threaded, your GUI is bound to have response problem. If you database connection is very slow due to some network/db issue your app will hang irrespective of the GUI frameworks or hardware chosen, if it was a single threaded app.
But if you write a good design and dedicate a separate thread for GUI handling and other threads for handing background tasks, you will have a really good GUI response. That way you can perform other tasks in background and GUI gets updated when notification is obtained. Remember, it wont happen magically and you need to sync you threads and update GUI.
Also, avoid creating threads for each and every task. You need to check things which can take more time like sending big files or faster tasks like checking/reading if config file exists or not.
By using third party GUI frameworks you are increasing your dependencies in your application and you would require to ship additional dlls etc with you main application. With win32 things are pretty neat.
At the moment I'm developing a web based application using Silverlight 3.0. For the business rules I'm looking for a rules engine that's both easy to use for me and my users, which will work with SL3. Is something like that available out of the box or will I need to roll my own?
I've Googled and looked around the various code sites (Codeplex, Code Project etc), but didn't see anything that suits my needs.
I did also have a good long look at NxBRE, but it's Rules syntax is too complex for 'dummy' users.
What about the rules engine that comes with Windows Workflow Foundation?
http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/08/09/WF-Rules-Engine-without-Workflow.aspx
For people who stumbled upon this thread looking to use NxBRE as a Rules Engine with Silverlight (SL), here is my two cents.
I tried referencing NxBRE dll in my SL project with no luck. SL does NOT allow dlls that are not built using SL CLR to be referenced in an SL project.
Fortunately NxBRE is an open source project so I downloaded the source files to build it using SL CLR.
SL does not support a lot of .NET types, namely objects in namespaces System.Xml.XPath, System.Xml.XPath etc. These are required for NxBRE to compile.
So I had NO luck using NxBRE with SL. These are my first impressions, if I find more by digging deeper I shall let you guys know.
Hope this is of help to someone out there.
Thanks
Sai Gudigundla
I've searched around a bit more, and decided that Rules Engines actually don't fulfill our requirements. We don't need rules, we want to do calculations on a property when the value of that property changes.
Thanks for your answers,
Cheers,
Frances
For those who might be interested: eventually we went for CSLA .Net for Silverlight
Back to the original rule engine question...
If you want to run the rule engine inside of Silverlight, you would need to find one that has been built to only use the limited subset of .NET that Silverlight supports. For example, Silverlight supports generic collections (List) but not untyped collections (List).
At this moment, I don't know of a .NET rule engine that has been (re-)targeted to the Silverlight CLR.
Furthermore, while there are interesting applications for client-side rule engines (for example: in the browser or on a mobile device), one should always consider whether the rule engine is more appropriately hosted on the back end. Take into consideration how frequently the rules are called, how much data is being moved around, etc.