Does it make sense to integrate scripting languages to C# apps?

Question

I have been thinking about integrating Ruby into my app, but some of my friends at work told me that C# is already very high level. But to me it seems like it has more baggage for doing very quick things.

What do you guys think?

Also if I do integrate, then does it make sense to limit it so that you can do just about anything using the existing functionality of the app, but not extend it?

Reason for this is, scritping languages aren't known for performance, and if you say give people to write Filters like Blur, Contrast, etc, then those would be way slower than they should be and degrade the experience of the client of the scripter, right?

Answer 1

I've integrated (lua) scripting into applications, and I've also used c# itself as a "scripting language", by compiling dynamic assemblies on-the-fly from code provided by the user. I've also implemented "plug-in" systems using user-provided assemblies that conform to specific interfaces or base classes.

There are lots of things to consider, from security, to performance, to end-user confusion to consider. I don't think that you could make a blanket statement like "scripting languages don't belong in applications", or even "scripting languages belong in applications". Any given specific case needs careful consideration of all the options and the consequences of those options before running off and doing something that you might regret later.

Answer 2

Hi Joan, there may be a performance hit for a given feature when implemented through a script interface rather than natively through your app, but if you would like to allow your users to script your app and it allows them to implement a feature that is useful to them that is not supported natively in your app, then it seems like a good idea to me. If you end up with a particular user script that is very popular you could always release it as a native feature of your app in a later release if you can improve on its performance. Hope this helps!

Answer 3

I like being able to write scripts to extend the functionality of an application. Even better when the scripting language is a well known one.

I would not limit the functionality a script can do based on concerns about performance. You don't know how something will behave on future hardware for example; however, you should limit what it can do for security / functionality.

If you have performance concerns, then I would implement extension points via script but also via plugins that would allow compiled code to be executed and ran.

Edit

In general I don't think it introduces anymore vulnerabilities then extending an application via a plug in for example. As for specific vulnerabilities, I really couldn't say without knowing more about your application is. But take web browsers for example. IE has had plenty of security flaws because scripts could access more resources then they should have been.

Forcing extensions to be done via compiled code does allow you to leverage mechanisms to help prevent attacks. You could inspect an assembly for example (Assuming .net here). easily looking for malicious code (Yes you could do this with scripting as well) , or you could prevent access to certain resources cia Code Access Security. You could also leverage code signing, and only load plugins from trusted publishers.

Answer 4

Depending on what you're trying to accomplish, you may like what PowerShell has to offer. You can make your application be a custom PowerShell scripting host, or just provide cmdlets that manipulate the application.

In either case, your users benefit from a rich, powerful, sensible scripting language with built-in .NET/COM/WMI support, but they don't have to be developers to use it.

You're also building on a skill that your users might already have. If they don't already have it, they can learn it for your application, and then benefit from it in the future.

Exchange Server 2007 implements a custom scripting host, if you want to see an example of how that works out.