We Keep Coding

Using Lua with C#/Mono

I'm programming a computer game in C#/Mono using OpenTK library. I want to use Lua for scripting for the game, so also those who know nothing about C# can edit the scripts, levels, etc. However, the problem is, that I can't find any way how to use Lua with C#/Mono. I found amazing LuaInterface, however it doesn't work on Mono. I've tried it and it works on Windows, but it doesn't on linux (Ubuntu). Replacing lua51.dll with linux alternates doesn't simply work.
I'd like to ask if there's any suitable way for using LuaInterface with Mono (I didn't find any source codes of LuaInterface to edit and rebuild it; I also heard that old versions of LuaInterface do work on Mono, however I didn't find them anywhere for download), or if there's any other suitable library for C#/Mono that you used before and you know it works. I've been searching for a long time, but I didn't find anything and I don't want to spend weeks programming it myself.
I guess it'd be however possible to use C# for scripting rather than Lua, but I don't like that idea very much, although I don't know why.

There is a feature in .Net (which is also included in Mono) called Dynamic Language Runtime.
I don't know about Lua being supported, but there are DLR implementations of Python and Ruby - both of these work on Mono as well as on Microsoft CLR.
Check out this question for information about using C# as scripting language.
EDIT: Actually, there is an IronLua project, but I don't know how complete it is.

You can use lua grammar and this answer as way to find compiler generator which creates c# code. As I think it is the best and the easiest way to make support for external language support. Why? You can fast add any events for grammatic constructions and add any language extensions you want.

What is the best way to port a C++ library to C#?

I have a (header only) C++ library that I am looking to port to C#. It is a wrapper of the win api which I have made for a certain purpose. I want to port it to C# because I want to develop it further using C#. What is the most efficient (and easiest?) way to port it. Please note that I do not want something hectic because I don't want to spend more time porting the library than it took to make that library in the first place. So is there a way?

It depends very much on how big your lib is, how it is structured, how your memory allocation looks like, how much you made use of libs not available in C# (like the C++ std lib), how much C++ template programming you have used etc.
Different strategies may be
try to port (parts of) it automatically by some code generator of your own
do not port it to C#, instead use C++/CLI (something I did very successfully in the past)
do it manually because the C++ concepts you have used so far don't map well to C#
"Header only" does not seem to make a real difference. In fact, things may technically get a little bit easier when you have just one C++ file for each class to be ported to one C# class file.

A couple of ways I can think of.
Manual conversion to C# dll with possible code generation help of T4.
Change your c++ library to a managed dll so you can use it in your c# project.
Of course, you might use interop with your c++ library in your C# project. But in that case, I am not sure about purpose of your c++ library since you said it's a wrapper.
Since you already have c++ library that you can fully control, I would try to go with #2 first.

Converting C++ solution to a class library

this might be a simple question, but as I have zero experience in C++ and my boss has given me a C++ solution work with I need to ask this question.
I have a C++ solution that needs to be turned into a .NET class library which can then be used in another .NET solution done in C#.
Is this even possible???
Cheers

You have to wrap all C++ classes that should be visible in .NET in C++/CLI classes.
Read this
There are also some automated tools to do this, but I never used these (I don't really trust them). Depends on how many C++ classes do you have, and how complex they are. Writing the wrappers is mostly straight-forward once you get used to some oddities of C++/CLI.

It depends of the output of the C++ solution. Is it an application (*.exe) or a library (*.dll)?
If it is a library (*.dll) you can use Platform Invoke Tutorial to call its functions out of managed code. A lot of examples of calling Win32 native functions can be found at http://pinvoke.net/.
If your result is an application it could be possible, that it has a COM interface. In that case you could use the COM interop to communicate with your application.
Last but not least you could write with C++/CLI a managed wrapper around your C++ functionality. But this is a lot of work and has many pitfalls.

Accessibility: Managed vs Unmanaged code

I'm about to begin working on a Accessibility project for Windows (targeting XP through 7) and would like some advice on the pros an cons of using managed code vs unmanaged code. Basically the software will need to be able to read text from open windows, access menus, and other common functions programs like a JAWS or another screen reader would be able to do. The question is, can I do this with C# or do I need to use C++?
For the last two years I've been developing a lot of C# code so it seems the quickest way to get started would be to play around with the System.Windows.Automation namespace. On the other hand, I haven't done much C++ or COM programming in quite a while and would have to spend some time refreshing before using unmanaged code.
What are the limitations of using C# code for Accessibility software? Are they severe enough to justify putting in a fair amount of time to refresh my C++ and COM skills because I'd run into a lot of things that just wouldn't be possible (or much more difficult) with managed code? Is the Automation namespace compatible with older applications (not using .NET or WPF)?

Definitely managed code
Even if you run into situations where you're comfortable using COM/unmanaged you can use COM/unmanaged for those modules.
.NET offers seamless interop between managed and unmanaged code.
with .NET 4.0 and C# 4.0 interop is even better ..
And above all else make sure you design a loosely coupled system so that there's always room for plugging in another module in an entirely different technology..
Just my two cents..

What are the best practices when using SWIG with C#?

Has anybody out there used the SWIG library with C#? If you have, what pitfalls did you find and what is the best way to use the library? I am thinking about using it as a wrapper for a program that was written in C and I want to wrap the header files where I can use them in my .NET application.
Edit: Some clarification on target OS's.
I plan on running the application on Linux and Windows, therefore the reason I am looking into SWIG. P/Invoke is not an option.

For my last project, here's the entire C# SWIG configuration file:
%module mdProject
%{
#include "mdProject.h"
%}
I compiled it in SWIG with:
swig -csharp -c++ -I../../Include mdProject.i
This generated a Project.cxx which I compiled and linked directly into the 'main' DLL, so I didn't need a second C++ 'helper' DLL. SWIG also generated a bunch of C# files which I compiled into a .NET DLL. My other wrappers (Java, PHP, etc) do use a helper DLL.
As #patrick mentioned, SWIG uses P/Invoke, so if you have a problem with that, you'll need to find another solution.
If you use types that stray from the ordinary (voids, structures, etc), you will have to do some extra work to get it right, but for the average API using int's, char*'s etc, it's fine.

I think the mistake the earlier posters did was read the docs and not look at the examples.
A few hours ago I needed to interface some C++ classes to C#. I looked in my Swig dir (I already had it for other work), found the directory Examples/csharp/class, browsed the code, loaded the solution, grokked it, copied it, put in my code, it worked, my job was done.
With that said, generated P/Invoke code isn't a solution for all needs. Depending on your project, it may be just as simple to write some simple API wrappers yourself or write managed C++ (Look up SlimDX for a superb example of this).
For my needs, it was simple and easy - I had mystuff.dll, and now in addition I can ship mystuffnet.dll. I'll agree that the doc is difficult to get into.
Edit: I noticed the OP only mentioned C. For that, you don't really need Swig, just use the usual C#/C DLLImport interop syntax. Swig becomes useful when you want to let C++ classes be invoked from C#.

I did attempt to use SWIG to wrap a project C++ for using in .NET a few years ago.
I didn't get very far as it was a massive giant pain to produce the configuration that SWIG required. At the time I just wanted a solution, not to learn another language/api/etc. SWIG may be easier to use these days, I couldn't tell you.
We ended up using Managed C++ to wrap the C++ project. It worked really well.
If you're just invoking functions straight out of a dll, I'd suggest not worrying about either of the above, and just using P/Invoke