We Keep Coding

Mono C# application instantiating C++ library classes with boost components

I have been researching for a while now if it is possible to write a C++ library with a class that can be instantiated in a mono application on Linux.
My requirement is that i need to use a boost algorithm and I need to instantiate one object and have it persistent for the life of the c# application and call a number of functions on it.
I'm happy to write wrapper classes, or use a COM component or whatever tech I need to make this work. But I'm not sure which technology will be best suited for my needs, or if the use of boost will be completely prohibitive.
Can anybody demystify this for me?
COM/ATL - SWIG - CLI - CXXI?
Which is right for me?

Check out the new CppSharp project.

Run F# code in C# - (Like C# in C# using Roslyn)

Is there a way to run F# code in C#? I have written an app in C# - I'd like to provide it the ability to execute F#, read Record objects, enumerate lists from F#. What is the current solution for this? I know in the future there will be probably be a way to do this via an update to Roslyn. Also, curious how to run F# code in F#, currently. Is there a way to do that easily?

Currently, you have to make the F# a library, and then call it from C#. Since F# is just .NET, using the F# library is (mostly) just like using any other C# library. You might want to look into FSharpX for this portion, however, as it provides some utilities to ease calling F# from C# and vice versa.
If you want to compile the F# dynamically from C#, you'll need to use the F# CodeDom implementation from the F# Power Pack. This will let you use CodeDom to compile F# on the fly, and then execute it from C#.
Note that Roslyn will not help here, even when it's released, as it won't support F# as a code model, only C# and VB.Net. It would potentially be possible to use Roslyn to manipulate and compile C# from within F#, but not the other way around.

In addition to the options that Reed already mentioned, there are a two other alternatives based on using the F# Interactive - you can either run it as a separate process or you could use the open-source release to reference it and call it directly (which is quite challenging, though).
So in summary, you have three options:
You can start the fsi.exe process and evaluate F# code in the F# Interactive environment (by sending F# code to the process by standard input). The F# binding for MonoDevelop is a good example how to do this (see InteractiveSession.fs).
The only difficulty is communication between the two processes, but I think this should be doable using a .NET remoting (or WCF) channel between the two. You can also just read the standard output from F# Interactive, but that might be a bit too simple.
You could use the open-source release of F# compiler & tools to reference relevant parts of the F# compiler and call them (as a library) to evaluate F# code. This would be the best option and it would give you pretty much the same options you get with interactive C# from Roslyn.
Sadly, this is not quite an easy task - I was playing with the idea of doing this and I made some progress (I can share that), but it is not done yet. The idea is to take the source code of fsi.exe (here), remove all UI and turn it into a library.
Using CodeDOM, you can invoke the F# compiler (fsc.exe) to compile F# code into a stand-alone application (or library), load it dynamically and run it. A disadvantage is that this will start a new instance of the compiler each time you use it and so it may be a bit slow (depends on your scenario)

Since the question has been asked, there has been a lot of exciting development :-)
You can now do this really easily using the F# Compiler Services project:
The F# compiler services package is a component derived from the F# compiler source code that exposes additional functionality for implementing F# language bindings, additional tools based on the compiler or refactoring tools. The package also includes F# interactive service that can be used for embedding F# scripting into your applications.

Need information on windows scripting and supporting scripting in my C# application

I'm trying wrap my head around all of the different scripting technologies for Windows (what are they, and which are the most common) and ultimately to figure out what type of scripting to add to my application.
I've read that with .NET 4 it's easy to make your program scriptable via dynamic languages like IronRuby and IronPython (or even VB or C# which might be more confusing for a user?) My understanding is that pre .NET 4 the way to add scripting support for your application was to make it a COM/OLE object so people could use vbscript, winbatch, shell scripts, or another scripting language (or really any language that supported COM) to control your application? What are the common scripting languages use? I've heard a lot of people talk about VB for Applications. Is that a dynamic language or a compiled language and to allow my application to be scriptable via VB for Applications would I have to support COM/OLE? I think I'm leaning towards supporting IronRuby and IronPython since it seems simple to implement support for them, but can those languages also be used to script Windows or other applications in general (and thus scripts for your application could have more features than what you laid out)? How would you go about designing your application to be scriptable?
I know that seems like a thousands questions, but really what I'm looking for is just an explanation of the scripting technologies for windows (what are the main differences, how frequently are they used) and which ones are the most common/standard to support when making your application scriptable?
Thanks in advance everyone!!

I think it depends on what you are trying to do. Are you trying to create dynamic objects in your apppool or view the values of something in your memory. If you need access to you objects then I would say maybe you could put a scripting window in your program. If you are just trying to configure certain aspects of you program you and look at adding modules to windows powershell for your admins. That seems to be what microsoft is doing for things like sharepoint and sql server. I would look up if powershell can fit your needs so that users can use the language they are confortable with and write there own scripts but if not then take a look at adding one of the dynamic languages to your app. If slashdot is to be believed today then Microsoft is not going to be persuing them as agressively.

Scrolling Game Development Kit 2 will actually compile code entered in the UI rather than interpret it as script. (It uses the C# compiler provided with the framework.) It can then run and reflect on that code at runtime. Have you considered a solution like that?

C++/CLI: why should I use it?

I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially C#).
Along the way I bumped into C++/CLI, and I want to know if there is any specific use for that language? Is it just suppose to be a intermediate language for transforming from native C++ to C#?
Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)

Yes, C++/CLI has a very specific target usage, the language (and its compiler, most of all) makes it very easy to write code that needs to interop with unmanaged code. It has built-in support for marshaling between managed and unmanaged types. It used to be called IJW (It Just Works), nowadays called C++ Interop. Other languages need to use the P/Invoke marshaller which can be inefficient and has limited capabilities compared to what C++/CLI can do.
If you need to interop with native C++, classes that have instance functions and need the new and delete keywords to create/destroy an instance of the class then you have no choice but use C++/CLI. Pinvoke cannot do that, only the C++ compiler knows how much memory to allocate and how to correctly thunk the this pointer for an instance function.
The .NET framework contains code that was written in C++/CLI, notably in System.Data and WPF's PresentationCore. If you don't have unmanaged interop needs or don't have to work with a legacy code base then there are few reasons to select C++/CLI. C# or VB.NET are the better choices. C++/CLI's feature set got frozen around 2005, it has no support for more recent additions like lambdas or Linq syntax. Nor does the IDE support many of the bells and whistles available in the C# and VB.NET IDEs. Notable is that VS2010 will initially ship without IntelliSense support for C++/CLI. A bit of a kiss-of-death there.
UPDATE: revived in VS2012, IntelliSense support is back. Not in the least thanks to C++/CX, a language extension that simplifies writing WinRT apps in C++. Its syntax is very similar to C++/CLI. The Windows Forms project templates were removed, the designer however still works. The new debugging engine in VS2012 doesn't support C++/CLI, you have to turn on the "Managed Compatibility Mode" option in Tools + Options, Debugging, General.

First C# is not a 'derivitive' of .NET. .NET is not a language, it is an application framework and class library based on the CLR, for which a number of languages exist.
That said, the most compelling reason to use .NET is that it is a well designed class library and a much easier way to develop for Windows than Win32 or MFC. However I personally decided that I'd rather learn a new language altogether than learn extensions to an old one, and because C# was designed from the ground up to work with .NET, I suggest that is the language of choice for .NET.
C++/CLI is useful is you want to use .NET with some legacy code, and I have used it for creating Windows Forms GUIs and gluing them to existing application code. Its other raison d'etre is that it is the only .NET language that supports mixed managed and native code in a single load module, so it is good for both performance and reuse of legacy code.
With respect to the number of languages, Microsoft want every Windows application to be based on .NET because it is better for the security and stability of their OS. The only way that will happen is by supporting multiple languages. Think of .NET as an application platform or OS API, and then the question makes less sense; there will be many languages for .NET for the same reason as there are many languages for any platform. Those reasons are many, including commercial advantage, application fit, politics, supporting existing developers, choice and no doubt more.

Microsoft has changed its stance on this a few times. It was originally intended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.
Then a few years ago, they realized that this simply wasn't what their customers wanted. Developers who are moving to .NET anyway generally jump to a language like C#, and the rest have reasons to keep their code in the native world, so they stay with C++.
So now, Microsoft intends for C++/CLI to be a "bridge" between native C++ code and managed code written in some .NET language. It's no longer a language they recommend you switching your entire codebase to.

It's indeed mainly intended as intermediate language to easily link .net code with native, unmanaged C++. Do yourself a favour, don't use it if you don't need to. C++/CLI syntax is a mess.
Regarding your second question ... I think today C# is the dominant language in .net, but not everyone likes its style and paradigms. .net's architecture makes adding new languages easy (see F#, which aims at functional programming).

I've used C++/CLI to create .NET API's for some unmanaged C++ libraries. Passing and marshalling of parameters takes some getting used to (depending on used types), but once you've got the hang of it, it's really a nice way to bridge the gap between the managed and unmanaged world.

I have not looked at C++/CLI but it harnesses the .NET world - think of it as a in-between C++ and C# where you have the best of both worlds. It could be useful in situations where you want to use C++ that can easily access .NET objects and it's core BCL. Have a look here at this article discussing the primers of C++/CLI. Unfortunately, I have not heard of a Managed C++ application as it has ruffled a lot of C++ friends on the syntax side of things and lost gathering of followers who went back to the unmanaged world of C++.
Hope this helps,
Best regards,
Tom.

for me, i have to use it when there is no other way to reuse c++ class

This post is old but the most important message in my oppinion is missing: You use it for being able to see and manipulate the source code of C++ frameworks you use in C#. Examples: You don't use compiled OpenCV binaries, instead you got the OpenCV sourcecode in your solution and can add simple some Extensions, or deep check how some behavior exists. Or in finanicial math you could QuantLib Sources, and so on. This is much better than having already compield libraries that act as black boxes in a lot of ways. C++/Cli in .NET solves this.

Just so you know. Unless you specify the code to be compiled as unmanaged, when compiling with CLR support it will be compiled as managed code.
While CLI C++ is nice. I find it a pain to code in. There is just something about it that makes me not want to program in it. It isn't even the "^". It is like using a broken .net. I spent 40 minutes coding something fully managed in it that took me 10 minutes in C#. I mean, sometimes I just give up and use C# because it frustrates me when coding in it. I mean if you are going to use .net you might as well use C#(over CLI C++).

Adding scripting functionality to .NET applications

I have a little game written in C#. It uses a database as back-end. It's
a trading card game, and I wanted to implement the function of the cards as a script.
What I mean is that I essentially have an interface, ICard, which a card class implements (public class Card056: ICard) and which contains a function that is called by the game.
Now, to make the thing maintainable/moddable, I would like to have the class for each card as source code in the database and essentially compile it on first use. So when I have to add/change a card, I'll just add it to the database and tell my application to refresh, without needing any assembly deployment (especially since we would be talking about 1 assembly per card which means hundreds of assemblies).
Is that possible? Register a class from a source file and then instantiate it, etc.
ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);
The language is C# but extra bonus if it's possible to write the script in any .NET language.

Oleg Shilo's C# Script solution (at The Code Project) really is a great introduction to providing script abilities in your application.
A different approach would be to consider a language that is specifically built for scripting, such as IronRuby, IronPython, or Lua.
IronPython and IronRuby are both available today.
For a guide to embedding IronPython read
How to embed IronPython script support in your existing app in 10 easy steps.
Lua is a scripting language commonly used in games. There is a Lua compiler for .NET, available from CodePlex -- http://www.codeplex.com/Nua
That codebase is a great read if you want to learn about building a compiler in .NET.
A different angle altogether is to try PowerShell. There are numerous examples of embedding PowerShell into an application -- here's a thorough project on the topic:
Powershell Tunnel

You might be able to use IronRuby for that.
Otherwise I'd suggest you have a directory where you place precompiled assemblies. Then you could have a reference in the DB to the assembly and class, and use reflection to load the proper assemblies at runtime.
If you really want to compile at run-time you could use the CodeDOM, then you could use reflection to load the dynamic assembly. Microsoft documentation article which might help.

If you don't want to use the DLR you can use Boo (which has an interpreter) or you could consider the Script.NET (S#) project on CodePlex. With the Boo solution you can choose between compiled scripts or using the interpreter, and Boo makes a nice scripting language, has a flexible syntax and an extensible language via its open compiler architecture. Script.NET looks nice too, though, and you could easily extend that language as well as its an open source project and uses a very friendly Compiler Generator (Irony.net).

You could use any of the DLR languages, which provide a way to really easily host your own scripting platform. However, you don't have to use a scripting language for this. You could use C# and compile it with the C# code provider. As long as you load it in its own AppDomain, you can load and unload it to your heart's content.

I'd suggest using LuaInterface as it has fully implemented Lua where it appears that Nua is not complete and likely does not implement some very useful functionality (coroutines, etc).
If you want to use some of the outside prepacked Lua modules, I'd suggest using something along the lines of 1.5.x as opposed to the 2.x series that builds fully managed code and cannot expose the necessary C API.

I'm using LuaInterface1.3 + Lua 5.0 for a NET 1.1 application.
The issue with Boo is that every time you parse/compile/eval your code on the fly, it creates a set of boo classes so you will get memory leaks.
Lua in the other hand, does not do that, so it's very very stable and works wonderful (I can pass objects from C# to Lua and backwards).
So far I haven't put it in PROD yet, but seems very promising.
I did have memory leaks issues in PROD using LuaInterface + Lua 5.0, therefore I used Lua 5.2 and linked directly into C# with DllImport. The memory leaks were inside the LuaInterface library.
Lua 5.2: from http://luabinaries.sourceforge.net and http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download
Once I did this, all my memory leaks were gone and the application was very stable.

The main application that my division sells does something very similar to provide client customisations (which means that I can't post any source). We have a C# application that loads dynamic VB.NET scripts (although any .NET language could be easily supported - VB was chosen because the customisation team came from an ASP background).
Using .NET's CodeDom we compile the scripts from the database, using the VB CodeDomProvider (annoyingly it defaults to .NET 2, if you want to support 3.5 features you need to pass a dictionary with "CompilerVersion" = "v3.5" to its constructor). Use the CodeDomProvider.CompileAssemblyFromSource method to compile it (you can pass settings to force it to compile in memory only.
This would result in hundreds of assemblies in memory, but you could put all the dynamic classes' code together into a single assembly, and recompile the whole lot when any change. This has the advantage that you could add a flag to compile on disk with a PDB for when you're testing, allowing you to debug through the dynamic code.

Yes, I thought about that, but I soon figured out that another Domain-Specific-Language (DSL) would be a bit too much.
Essentially, they need to interact with my gamestate in possibly unpredictable ways. For example, a card could have a rule "When this cards enter play, all your undead minions gain +3 attack against flying enemies, except when the enemy is blessed". As trading card games are turn based, the GameState Manager will fire OnStageX events and let the cards modify other cards or the GameState in whatever way the card needs.
If I try to create a DSL, I have to implement a rather large feature set and possibly constantly update it, which shifts the maintenance work to another part without actually removing it.
That's why I wanted to stay with a "real" .NET language to essentially be able to just fire the event and let the card manipulate the gamestate in whatever way (within the limits of the code access security).

The next version of .NET (5.0?) has had a lot of talk about opening the "compiler as a service" which would make things like direct script evaluation possible.