[.net] Easy Scripting in .NET

Started by
72 comments, last by ppp_vcf 16 years, 4 months ago
Yeah, the sample that comes with the DX9c SDK shows how to use C# scripts within native C++ code by using an intermediate managed C++ layer. It works amazingly well.

---------------------------Hello, and Welcome to some arbitrary temporal location in the space-time continuum.

Advertisement
So... exactly what are the uses of this? All i see is that you're compiling source code inside your source code.
Quote:Original post by deathtrap
So... exactly what are the uses of this? All i see is that you're compiling source code inside your source code.


LOL
Quote:Original post by deathtrap
So... exactly what are the uses of this? All i see is that you're compiling source code inside your source code.


ROFLMAO! :)
It's good to note that you can use a string in memory rather than a file on disk for your compile source.

FWIW - I'm using this type of scripting in a binary file editor. I allow the "scripts" to use the public classes/members of my own editor .exe by adding my .exe itself to the reference list.

I use the scripts mainly for loading/saving different file formats, but I'm thinking about letting them do some more advanced stuff adding on to the user interface.
Here is how to dynamically compile a boo script ( http://boo.codehaus.org/ ), you can sandbox the resulting assembly before running it too if need be.

// (compile with references to Boo.dll and Boo.Lang.Compiler.dll)using System;using System.IO;using System.Threading;using System.Reflection;using Boo.Lang.Compiler;using Boo.Lang.Compiler.IO;using Boo.Lang.Compiler.Pipelines;namespace BooRunner{    class App    {        [STAThread]        static int Main(string[] args)        {            string booscript = "print \"hello\"";                       return RunScript(booscript);        }               static int RunScript(string script)        {            BooCompiler compiler = new BooCompiler();            compiler.Parameters.Input.Add(new StringInput("<stdin>", script));            //or to run files:            //compiler.Parameters.Input.Add(new FileInput(Path.GetFullPath(filepath)));                       compiler.Parameters.Pipeline = new CompileToMemory();            //or to compile to a dll:            //compiler.Parameters.Pipeline = new CompileToFile();            //compiler.Parameters.OutputAssembly = "Script.dll";                       CompilerContext result = compiler.Run();                       if (result.Errors.Count > 0)            {                foreach (CompilerError error in result.Errors)                {                    Console.WriteLine(error.ToString(true));                }                return -1;            }            try            {                result.GeneratedAssemblyEntryPoint.Invoke(null, new object[1]);            }            catch (TargetInvocationException x)            {                Console.WriteLine(x.InnerException.ToString());                return -1;            }            return 0;                   }    }}
You can also embed mono in your project and use C# scripting via mono. Making your code little more platform independant.

http://www.mono-project.com/Embedding_Mono
http://www.go-mono.com/embedded-api.html

Probably possible to run mono on game consoles too. So if you plan on porting your game to consoles or other os than windows you should use it.
Quote:Original post by VizOne
The managed DX scripting example uses exactly this technique.


Here a code snippet how to setup a "sandbox"-AppDomain
*** Source Snippet Removed ***

Regards
Andre



Hello Andre,
Im using VB.NET 2005. Ive been unable to get the sandboxed version to work, although I have no problems with compiling and invoking scripts from the current appdomain.

With the sandboxed version, the call to myprovider.CompileAssemblyFromSource throws an exception that it cannot find the temporary binary file it's created. I even tried specifying an output file and i see it being created but it still complains with filenotfoundexception.

I'm thinking maybe it has something to do with how i'm trying to load the assembly. I'll keep trying, but if you have any more tips, it'd be much appreciated.
-Hypnotron
Washu wrote up an excellent article on Code Access Permissions which I suggest you should most definately read.

Also, a nice tutorial was just recently published here on Gamedev: Using Lua with C#. It goes over using the LuaInterface in .NET. Lua should be mentioned as it's been in the game industry for years.

I'd also like to make a self plug of my GakScript Scripting Engine which nicely wraps the CodeDom and adds multiple language plugin interfaces. Very easy to use and comes with a few simple examples of its use.

[Edited by - Rob Loach on June 4, 2006 5:11:48 PM]
Rob Loach [Website] [Projects] [Contact]
Quote:Original post by Rob Loach
Washu wrote up an excellent article on Code Access Permissions which I suggest you should most definately read.

Also, a nice tutorial was just recently published here on Gamedev: Using Lua with C#. It goes over using the LuaInterface in .NET. Lua should be mentioned as it's been in the game industry for years.

I'd also like to make a self plug of my GakScript Scripting Engine which nicely wraps the CodeDom and adds multiple language plugin interfaces. Very easy to use and comes with a few simple examples of its use.


Hello Rob. Thanks for the reply.

I understand the importance of code security, but with regards to loading scripts within the same appDomain (as I believe the article you link to suggests) it doesnt deal with the issue of script bloat. That is, you cannot unload assemblies from an AppDomain. However,you _can_ unload entire AppDomains so if you load scripts in an AppDomain you can free memory by unloading that domain.

Am I off base here?
-Hypnotron

This topic is closed to new replies.

Advertisement