C::B and interfacing native C++ via C++/CLI to .NET

[cacb]

Hi,

I code with native C++ in Code::Blocks and would prefer to stay miles away from Microsoft and their .NET framework. I have developed a number of useful tings in native C++, using C::B project files with MS VS2010 compiler on windows and gcc on Linux. That means I have typically 4 build targets per project. All is well.

However, sometimes I have to create interfaces so my code can be called by C# programs written by others. That means I need to write some C++/CLI code for interfacing to .NET. I could do it using MS visual studio 2010, but I much prefer the nice and clean setup of Code::Blocks. So I wonder, would it be possible/easy to create a C::B project for a DLL that allowed writing garbage collected "managed C++"? I have looked through the C::B C++ compiler settings, but found nothing similar to

"Common Language RunTime Support (/clr)" option found in VS2010. Not sure what other things might be needed in addition.

The idea would obviously be to continue develop in native C++ with C::B, but create thin interface DLLs with managed C++ in order to support C# client proprams.

Any ideas for this?

[tamahome]

To compile managed code, add the compiler option /clr for mixed native and managed. Or use /clr:safe for pure managed code.  This works for the cl.exe compiler.  I don't know about gcc.  Compiling and linking Managed code doesn't use any header files or libraries in the traditional sense.  To reference managed dll from c++/cli, use:
#using <mscorlib.dll>
using namespace System;
There is a slightly different syntax for handling managed code.  This should get you started:
http://msdn.microsoft.com/en-us/library/68td296t.aspx

[cacb]

Thanks for the above reply (I know I am very late in thanking you, apologies for that!).

I have a somewhat related question:
I am working on a C++ project where everything is portable across Windows and Linux, and I obviously use Code::Blocks. On Windows I use the VC2010 compiler from C::B, GCC on linux.

The functionality needs to be accessed (on Windows only) from a C# application, and for that I am writing the C++/CLI code (making that layer as thin as possible). This seems to work, although I use Visual C++ 2010 express for the C++/CLI code still.

Recently, I have started testing from C#, and found that I had to install yet another MS IDE to do it: MS Visual C# 2010 Express. Observe that the express versions of the C++/C# IDE are 2 different IDEs that cannot be integrated into one (unlike the pro version). On top of that, these IDEs are superficially similar, but many things are different, it is all rather confusing and frustrating.

Therefore: I was playing with the idea of abandoning the MS Visual C# 2010 Express IDE and use Code::Blocks as a C# IDE instead. Compiling C# from the command line is doable using the "csc" compiler http://www.youtube.com/watch?v=q0eoZDXMlVc
I can do without C# syntax highlighting, but using C::B global variables in pre/post build step is something I would like to have.

Would it work to simply pretend that C# was an odd C++ compiler and get it to work along the lines of
http://stackoverflow.com/questions/5604183/adding-compiler-to-codeblocks
and somehow get it associated only with files with .cs suffix?

I found this page talking about something similar, but it is 5 years old:
http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system

Pointers to most up-to-date explanations would be welcome.

[oBFusCATed]

You can try the new compiler path and you can modify the commands by going to
settings -> compiler -> your compiler -> other -> advanced

Also there is the monodevelop/sharp develop IDEs, probably they will be more suitable for C# code.

[cacb]

You can try the new compiler path and you can modify the commands by going to
settings -> compiler -> your compiler -> other -> advanced

Also there is the monodevelop/sharp develop IDEs, probably they will be more suitable for C# code.

Ok, I take it that the 5 year old explanation referred to is the most relevant. I shall look into it then.

I know there are other IDEs for C#, but it defeats the purpose of trying to limit the number of IDEs I have to relate to. I currently have to relate to 3 different IDEs (C::B, MSVC++ 2010 express, MSVC# 2010 express) and it becomes a mess. Replacing one of these 3 IDEs with a fourth achieves nothing. I was trying to standardise on using C::B.

[cacb]

Ok, I take it that the 5 year old explanation referred to is the most relevant. I shall look into it then.

I tried, but didn't succeed. Never mind then.