We Keep Coding

what are the possible ways to using c# code in c++

I'm just looking for a best way to re-use code written in c#, in my c++ projects. Creating a com\service doesn't look like a best option for my needs. How difficult it is to export c# code into a dll and use it in c++? can i get some suggestion or example? is this usual requirement or ? Please help me.
i use win7, VS2008, win7sdk
Thanks & Rgds, ~calvin

Executing managed code from an unnamaged executable is possible, though not quite easy. You can look into this article for an introduction and this book to go further.
I personally would avoid this kind of things in most cases and, if possible, switch the C++ project to C++/CLI to obtain an immediate compatibility with .Net assemblies for a minimal cost.

You can't export C# code into a native dll afaik. At least without very much pain in your buttocks. You should have thought beforehand and write the reusable part in C, thus creating a native DLL which could be used from all languages.
Also, you could try managed C++ - I personally hate it... but there you go

In case you need to use code written in C# C++, then you need to first see what all data types you would be passing from your C++ code to C# code.
1. Basic data types like int, enum etc can be passed from unmanaged to managed code.
2. in case you want to pass on class object, than you need to use marshalling.

If you can't use COM (if the .NET code is already written for example), then you can host the CLR, but this is a long road...
See these other articles
How to load CLR into process and Create a C# DLL That Can Be Imported in a Delphi App Using stdcall - Possible?

Should a WPF application be written in C++/CLI or C#?

WPF applications are, at its core, managed applications? Right? So, I have to choose between using managed C++ or managed C#. I experimented with managed C++ years ago. It seemed to be not quite be ready for primetime. I'm guessing Microsoft has put more effort into managed C# than managed C++. So, it seems like using managed C# is the best alternative between the two. Is this the case? What experiences have you had with WPF in either language? Thanks in advance.

Managed C++ has been replaced by C++/CLI, and "managed C#" is just C#.
I would strongly recommend you to use C# for a new project, and use C++/CLI only when needed. C# has a better support, has a larger user base, and is easier to work with inside Visual Studio 2010.
Additionally, keep in mind that C++ and C++/CLI are two different languages. For my first .Net project, I chose C++/CLI because I already knew C++, and this was a very bad idea: the learning curve from C++ to C++/CLI is similar to learning C# from C++: don't fall into that trap.

C++/CLI was only really made to support writing interop layers between unmanaged code (i.e. native C/C++) and managed code. For "heavy lifting", you should definitely use C# (or VisualBasic.NET).

You can use managed C++ for your backend but, on inspection, VS (I'm using 2010 Ultimate) doesn't have any in-built templates for a C++ WPF application - only C# or VB.
I'm sure you could force it to work if you wanted to, but I'd suggest you use C#.

C# is the most used, so if you have trouble, there is more online support for C#. C# also has better support by Microsoft. It's overall just a more finished product, even now. If you really don't care yourself, i'd go with C#.

In terms of the backend, they both run on the CLR and both capable of the job. Really it just comes down to what you're most comfortable with. If you're not sure, experiment with both.
Use whatever feels most productive.
Edit:
As has just been pointed out to me though, it seems support for WPF templates (and possibly even intellisense) just isn't there for C++. So in that case I guess I'd have to recommend C#.

IMO without a doubt C# (or VB/F#).
C++/CLI is great when crossing the border of managed world and a c++ library. Complexity is higher though as subtle issues arises from the fact that one combine a managed language and an unmanaged.
Compile times are longer though as well in C++/CLI especially since the code templates are modelled after how the C# compiler works not on how the C++ compiler works.

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++).

C# to Oxygene code converter

I know CodeGear made BabelCode that uses the Code DOM to convert C# to Delphi for .NET. I am curious if there are any other similar tools to convert C# to Delphi Prism? If not, what is involved in using the Code DOM to create one (yeah, that is open ended!)
Update: This is now built into Delphi Prism. Just paste or import your C# and you have Oxygene aka Delphi Prism Code.

It's in its early stages but Carlo just published a first revision of his open source "C# to Oxygene" tool:
http://code.remobjects.com/p/csharptoxy/

One option I saw was to use .NET Reflector on the C# compiled assembly. It has an Oxygene syntax. That is kind of the long way around and not exactly optimal.

Use BabelCode to convert your C# to Delphi, and then use Oxidizer to convert Delphi to Prism. Not a stellar idea, I realize, but it might at least be a little more automatable than going through Reflector. Good luck.

How should I convert Java code to C# code?

I'm porting a Java library to C#. I'm using Visual Studio 2008, so I don't have the discontinued Microsoft Java Language Conversion Assistant program (JLCA).
My approach is to create a new solution with a similar project structure to the Java library, and to then copy the java code into a c# file and convert it to valid c# line-by-line. Considering that I find Java easy to read, the subtle differences in the two languages have surprised me.
Some things are easy to port (namespaces, inheritance etc.) but some things have been unexpectedly different, such as visibility of private members in nested classes, overriding virtual methods and the behaviour of built-in types. I don't fully understand these things and I'm sure there are lots of other differences I haven't seen yet.
I've got a long way to go on this project. What rules-of-thumb I can apply during this conversion to manage the language differences correctly?

Your doing it in the only sane way you can...the biggest help will be this document from Dare Obasanjo that lists the differences between the two languages:
http://www.25hoursaday.com/CsharpVsJava.html
BTW, change all getter and setter methods into properties...No need to have the C# library function just the same as the java library unless you are going for perfect interface compatibility.

Couple other options worth noting:
J# is Microsoft's Java language
implementation on .NET. You can
access Java libraries (up to version
1.4*, anyways).
*actually Java 1.1.4 for java.io/lang,
and 1.2 for java.util + keep in mind that J# end of
life is ~ 2015-2017 for J# 2.0 redist
Mono's IKVM also runs Java on
the CLR, with access to other .NET
programs.
Microsoft Visual Studio 2005 comes
with a "Java language conversion
assistant" that converts Java
programs to C# programs
automatically for you.

One more quick-and-dirty idea: you could use IKVM to convert the Java jar to a .NET assembly, then use Reflector--combined with the FileDisassembler Add-in--to disassemble it into a Visual C# project.
(By the way, I haven't actually used IKVM--anyone care to vouch that this process would work?)

If you have a small amount of code then a line by line conversion is probably the most efficient.
If you have a large amount of code I would consider:
Looking for a product that does the conversation for you.
Writing a script (Ruby or Perl might be a good candidate) to do the conversion for you - at least the monotonous stuff! It could be a simple search/replace for keyword differences and renaming of files. Gives you more time/fingers to concentrate on the harder stuff.

I'm not sure if it is really the best way to convert the code line by line especially if the obstacles become overwhelming. Of course the Java code gives you a guideline and the basic structure but I think at the end the most important thing is that the library does provide the same functionality like it does in Java.