This is a Mono-compatible version of LuaInterface , which is a
binding of Lua to .NET.
Since 1.5.3, LuaInterface moved to a fully managed solution, where the
Lua C code was compiled as CIL, which was more convenient for
deployment with .NET applications, since it then only required a
single assembly and no messing around with native DLLs. Another reason
is that much of the overhead of going between Lua and C# is due to
P/Invoke, not reflection. This is one of the conclusions of the
excellent article by Fabio Mascarenhas and Roberto 
This is however not the best solution for using LuaInterface for
general Lua scripting that needs to still be able to use existing Lua
binary modules, and was not an option for Mono, since gcc does not
have a standard CLI backend ,
The background behind this effort is a general effort to bring Lua to
the popular Unity3D game editor by Alexander Gladysh and his company
LogicEditor (http://logiceditor.com). and this effort has been made
possible by his generous support.
The repository is here  which is the latest LuaInterface 2.0.3
modified to using P/Invoke to load the native Lua shared library.
There have been some fixes to property/field lookup and error
The suggested way to get things running is via the old-fashioned
./configure && make && ./install. There are some installation notes
in the readme, but the key thing here is that you will need a Lua
shared library, the headers to compile the luanet.so stub and the Mono
BTW, it still works on Windows, using the MS csc compiler (and if you
have .NET on your machine, you have csc.exe, which is a rare case of
MS giving away goodies with their operating systems) This version is
much better suited for integration with Lua distributions, such as
LuaDist, and I will provide compatibility with that distribution in
due course. So this helps to complete the feature set of the original
Lua for Windows.
A nice example to show how to access Lua from C# code is here 
The cool thing about bindings to managed frameworks like Mono or Java,
is that you can easily access any libraries built for these platforms,
without having to write any extra binding code. So for instance, here
is _yet another way_ to use GTK+ from Lua:
local label = Label()
label.Text = "Hello World!"
(WinForms applications still run on Mono, but the aesthetics of the
result leave a lot to be desired.)
The worm in the apple is that some of the nicest features (like using
a Lua function as a delegate in this example) depend on run-time code
generation, and some popular platforms (like MonoTouch for iOS) don't
allow this. There are however workarounds for this issue.
Thanks to Alexander and LogicEditor for their support; they are true
friends of Open Source for funding an MIT licensed project.
I actually half-suspected something was on its way, after you
name-dropped Boo a few minutes ago. :)
This will be a godsend if I can make use of it. I know we're supposed
to be adaptable and all, but since our own migration to Unity I've
been trying to stick around shader-ville as much as possible just
because I have fewer expectations of the language. :/
Any idea of how it works with a web player (with or without Chrome /
NaCl)? I've had Lua and LuaJIT plugins (nothing fancy, just pushing
arguments and maybe printing something) running in Windows and Android
players, and it was simple enough, but "we might want the web player
at some point" was always the sticking point, and I suspected
Alexander had run into something similar...
Anyhow, good work! I'll take a look at it when I've had some sleep. :)
On Tue, Jul 10, 2012 at 10:24 AM, Steven Johnson
<[hidden email]> wrote:
> I actually half-suspected something was on its way, after you
> name-dropped Boo a few minutes ago. :)
I actually like Boo, but when I was using it the compiler was so slow
that the equivalent C# compiled much faster, even if it was five times
as verbose! (Which is BTW why I am not a fan of Scala, I guess it's
short-attention span syndrome)
> Any idea of how it works with a web player (with or without Chrome /
Currently we've just been working on getting Lua going with the Unity
Editor. Already got an interactive prompt - man, it's cool to boss
visual objects around interactively - and Lua scripts can be reloaded
on the fly.
We'll know soon how everything pans out. I have concerns about those
restricted Mono platforms which don't allow code generation, but we
have a fallback plan to go with Lua interpreters written in C# like
Kopi. But that is second prize, since it will be slow.
Any idea of how it works with a web player (with or without Chrome / NaCl)? I've had Lua and LuaJIT plugins (nothing fancy, just pushing arguments and maybe printing something) running in Windows and Android players, and it was simple enough, but "we might want the web player at some point" was always the sticking point, and I suspected Alexander had run into something similar...
Well, my current understanding is that WebPlayer will require KopiLua to work. It should be possible to use native Lua/LuaJIT for other platforms.
We do not need WebPlayer at the moment, but support for it (and iPhone/Android) is planned at some point in future.
If someone wants to participate in sponsorship for these or other features, please contact me off-list. Regardless, we'd be happy to hear any feedback on this project.
On Tue, Jul 10, 2012 at 3:48 AM, steve donovan
<[hidden email]> wrote:
> Since 1.5.3, LuaInterface moved to a fully managed solution, where the
> Lua C code was compiled as CIL [...]
> The repository is here  which is the latest LuaInterface 2.0.3
> modified to using P/Invoke to load the native Lua shared library.
> [...] I will provide compatibility with that distribution in
> due course. So this helps to complete the feature set of the original
> Lua for Windows.
Would this fully replace 1.5.3 (used in LfW)? Particularly, would it
be loadable in a standard Lua interpreter (lua.exe) by providing a
luaopen_luanet (like in 1.5.3)? And if it's useful on Windows, is
MonoLuaInterface the right name?
On Wed, Jul 11, 2012 at 8:46 AM, David Manura <[hidden email]> wrote:
> Would this fully replace 1.5.3 (used in LfW)? Particularly, would it
> be loadable in a standard Lua interpreter (lua.exe) by providing a
> luaopen_luanet (like in 1.5.3)?
Good question. The original luanet.dll had two functions, one to
provide some C glue that can not be done in C#, and two to provide a
means to instantiate the CLR from a loadable C module. I could not
find a way to compile this COM-heavy code in gcc but I know you have
experience with porting LuaCOM to gcc. So yes, in theory it could be
done, and that would be the best solution for a Lua distribution, at
least on Windows (there is probably equivalent functionality available
There does not appear to be any direct C# support in CMake but the
compilation is straightforward and can be done with a custom command -
basically, identify the compiler used and choose the appropriate
preprocessor symbols for the platform.
> And if it's useful on Windows, is MonoLuaInterface the right name?
Well, every repo needs a name ;) It's still a LuaInterface fork, in
the modern positive sense of the word.