We Keep Coding

Call C++ code from C# without creating dll?

I'm noob in C# and I already searched on the web. Anyway I'm still not sure about this and I do not have the total control of the code I have to implement, this is why I would like to be sure I needn't make any dll. I have a C++ file with a method, and I want to call this method from C# code. I just added "extern C" to the function.
When I just add the .h and .cpp files to the C# project they aren't detected. And of course, when I try to add it as reference, it doesn't work.
So do I absolutly have to make a dll ?

Your options for accessing the C++ code from C#:
Compile C++ as unmanaged DLL and access using p/invoke. This requires the C++ code be exposed using a C style API.
Compile C++ as unmanaged DLL and access using COM. This requires that you wrap your C++ in as COM objects.
Compile C++ as mixed/mode C++/CLI assembly and access the assembly as a managed reference. This requires that you wrap the original C++ as managed C++ ref classes.
All of these options, by necessity, involve the creation of another module/assembly. You cannot link the C++ code directly into your C# assembly.

You might like to try using the PInvoke Interop Assistant to generate the C# necessary to interact with the DLL via Platform Invoke. Be aware that this is imperfect though so YMMV.
Another alternative, if you have the knowledge and patience, is to make a COM component out of your native C++ DLL and consume that from C# by using the Type Library Importer to create a managed wrapper.

You won't be able to interact with .cpp/.h files since you need at least a binary object (assembly) for C# to interact with and C# won't generate any binaries from .cpp/.h. That's on the subject about adding these files as references to the project.
As for the argument that you don't have control over the code - well, don't make a DLL out of the actual .cpp/.h, but make your own thin DLL that has a wrapper object that just includes the headers, calls whatever method you would be calling and links to the appropriate .o files or .lib or whatever you have. If the interface changes you would just changed your thing wrapper which should be easy.

Is it possible to run unmanaged C++ normally from a managed C++/CLI project?

I'm in the process of wrapping a pure unmanaged VC++ 9 project in C++/CLI in order to use it plainly from a .NET app. I know how to write the wrappers, and that unmanaged code can be executed from .NET, but what I can't quite wrap my head around:
The unmanaged lib is a very complex C++ library and uses a lot of inlining and other features, so I cannot compile this into the /clr-marked managed DLL. I need to compile this into a seperate DLL using the normal VC++ compiler.
How do I export symbols from this unmanaged code so that it can be used from the C++/CLI project? Do I mark every class I need visible as extern? Is it that simple or are there some more complexities?
How do I access the exported symbols from the C++/CLI project? Do I simply include the header files of the unmanaged source code and will the C++ linker take the actual code from the unmanaged DLL? Or do I have to hand write a seperate set of "extern" classes in a new header file that points to the classes in the DLL?
When my C++/CLI project creates the unmanaged classes, will the unmanaged code run perfectly fine in the normal VC9 runtime or will it be forced to run within .NET? causing more compatibility issues?
The C++ project creates lots of instances and has its own custom-implemented garbage collector, all written in plain C++, it is a DirectX sound renderer and manages lots of DirectX objects. Will all this work normally or would such Win32 functionality be affected in any way?

You can start with an ordinary native C++ project (imported from, say, Visual Studio 6.0 from well over a decade ago) and when you build it today, it will link to the current version of the VC runtime.
Then you can add a single new foo.cpp file to it, but configure that file so it has the /CLR flag enabled. This will cause the compiler to generate IL from that one file, and also link in some extra support that causes the .NET framework to be loaded into the process as it starts up, so it can JIT compile and then execute the IL.
The remainder of the application is still compiled natively as before, and is totally unaffected.
The truth is that even a "pure" CLR application is really a hybrid, because the CLR itself is (obviously) native code. A mixed C++/CLI application just extends this by allowing you to add more native code that shares the process with some CLR-hosted code. They co-exist for the lifetime of the process.
If you make a header foo.h with a declaration:
void bar(int a, int b);
You can freely implement or call this either in your native code or in the foo.cpp CLR code. The compiler/linker combination takes care of everything. There should be no need to do anything special to call into native code from within your CLR code.
You may get compile errors about incompatible switches:
/ZI - Program database for edit and continue, change it to just Program database
/Gm - you need to disable Minimal rebuild
/EHsc - C++ exceptions, change it to Yes with SEH Exceptions (/EHa)
/RTC - Runtime checks, change it to Default
Precompiled headers - change it to Not Using Precompiled Headers
/GR- - Runtime Type Information - change it to On (/GR)
All these changes only need to be made on your specific /CLR enabled files.

As mentioned from Daniel, you can fine-tune your settings on file level. You can also play with '#pragma managed' inside files, but I wouldn't do that without reason.
Have in mind, that you can create a complete mixed mode assembly. That means, you can compile your native code unchanged into this file PLUS some C++/CLI wrapper around this code. Finally, you will have the same file as native Dll with all your exported native symbols AND as full-fledged .NET assembly (exposing C++/CLI objects) at the same time!
That also means, you have only to care about exports as far as native client code outside your file is considered. Your C++/CLI code inside the mixed dll/assembly can access the native data structures using the usual access rules (provided simply by including the header)
Because you mentioned it, I did this for some non-trivial native C++ class hierarchy including a fair amount of DirectX code. So, no principal problem here.
I would advise against usage of pInvoke in a .NET-driven environment. True, it works. But for anything non-trivial (say more than 10 functions) you are certainly better with an OO approach as provided by C++/CLI. Your C# client developers will be thankful. You have all the .NET stuff like delegates/properties, managed threading and much more at your finger tips in C++/CLI. Starting with VS 2012 with a somewhat usable Intellisense too.

You can use PInvoke to call exported functions from unmanaged DLLs. This is how unmanaged Windows API is accessed from .Net. However, you may run into problems if your exported functions use C++ objects, and not just plain C data structures.
There also seems to be C++ interop technology that can be of use to you: http://msdn.microsoft.com/en-us/library/2x8kf7zx(v=vs.80).aspx

Build native c++ for use as .net library

I have the c++ source code of functionality which is appealing to me.
What effort/work is involved/required in order to either reference this from a .net application or build this code as a .net assembly (preferably c#)?
This is my first attempt at porting code, so please breakdown your answer for me step by step.

There are several ways of doing it.
PInvoke
Create C++/CLI wrapper around your C++ native code (make static library out of C++ native code) and C++/CLI generated assembly can be easily utilized in .net application.
COM, i.e using interop (which is difficult among all the options)
In my suggestion easiest way is to use option 2, but you need to take care of proper marshaling.

Solution A:
If you have the source code, then compile the CPP program as a DLL file.
Use P/Invoke
Solution B (if the functionality you want is in a static library):
Create a stub function caller and compile THAT as a DLL
Same as solution A.2

Hook into a unknown function in a dll using C#

Is it possible to find out what functions are available in an arbitrary dll file and then call these functions using C# interop services.

You can analyze the exported functions of any native module (DLL or EXE) using tools such as dumpbin. Once you have the signatures of the exported functions, you can write P/Invoke wrappers for any of them you wish.
Alternatively, you can use a tool like the P/Invoke Interop Assistant to automagically do the grunt work for you.
However, all of that relies upon the native module having listed the functions you're trying to call in its export table. If what you're looking to hook into is not actually exported, then you will have to resort to old-fashioned spelunking with GetProcAddress, etc.

If the .dll is a managed assembly, then you can use the classes in System.Reflection to find and run arbitrary methods.
If it's a native Win32 dll, then you have a much harder road to hoe: you have to P/Invoke the Win32 APIs LoadLibrary and GetProcAddress and call the functions you want through an unsafe pointer.

So if the DLL you are refering to is a native DLL with C functione exports this is going to be range from easy to very difficult.
Easy: If you have the DLL and a C header file and even better with some documentation so that you know what arguments the exported functions expect, what calling convention is used. No problem use the .NET Interop services (PInvoke) as others have mentioned and call the functions you need.
Very Hard: If all you have is the DLL, you can discover the exports using DumpBin /exports filename.dll but then you are left with disasembling the code to try and determine the calling convention and what possible values and types the function expects. To be honest, if this stuff is Greek to you then this is not Very hard, it is borderline impossible without huge but interesting learning curve.

See P/Invoke: http://en.wikipedia.org/wiki/Pinvoke

You can use Dependency Walker to find the exported functions in the DLL.

If its an unmanaged, native dll, you will need to use a program such as dumpbin or PE Explorer. Both programs will show the export section of the dll.

I don't know about "arbitrary" dlls, but for .net assemblies, there's an excellent utility called "Reflector" that will tell you what functions are inside. you can then call them with reflection. I'm not familiar with "interop services".

Exporting functions from a C# class library

How would I export functions defined in a C# class library, while enabling them to be imported to and called from an unmanaged C++ application/DLL ?

Strictly speaking, you can't just export functions as you would in a classic .dll, as .NET .dll's aren't really .dll's at all. Your only three options are:
Use managed C++
Expose your C# classes as COM objects and consume them from your C++ code
Host the .NET runtime in your C++ project and interact with your C# classes through that.

Your C++ Apllication would have to start by hosting the CLR. There is nothing special required from the .NET DLL.

You would not. Not supported. You can pretty much only export COM objects from a C# class librarly.

You could also make a C++ wrapper for your C# library - a simple Managed C++ DLL that would import .NET methods and export them natively. This adds an additional layer, but it might be useful if C# library is a must have.
Another option is to tweak the compiled assembly to export the functions. A C# compiler cannot do this, but it takes a slight change of MSIL code to get the things done.
Have a look at this article - there're some links on how the stuff works, and a tool to automate it (though I haven't tried it myself).