views:

85

answers:

4

I have a C# VS10 project. I want its part to be pure C. So I will have pure C library and A C# file that will have part with C code calling that pure Lib.

So I'll have C part of code - not precompiled DLL but C code and C# code files. So is it possible to have inside one C# file C code like we have C code inside C++ code?

like Inline C code inside C#...

(I know it can sound strange but I really need it)

Is it possible? Will I have posebilety to pass data from that C part to C#?

+2  A: 

You can use P/Invoke to call C methods from C#.

However, unless you have very good reasons, I highly recommend that use stick to C# and not use C.


It is not possible to mix C and C# code in the same file.

However, you can replicate any C code (except for calling CreateRemoteThread) in raw C# using unsafe code and/or P/Invoke.

SLaks
I ment part of code - not to use precompiled DLL but mix code C and C# inside one file (I know it can sound strange but I really need it)
Blender
That's completely impossible, unless you write your own compiler. You may be looking for the `unsafe` keyword, which allows you to use pointer arithmetic in C#. What are you trying to do?
SLaks
not to write wrapper for using x264 dll (problem - I know how to use lib from C and I do not want to write wrapper) and I really need that functions in my .net project
Blender
@Ole: Help us help you: please tell us *why* you believe you really need it.
Steven Sudit
A: 

You can use the DllImport attribute to call methods from your C library. This is known as Platform Invocation (or more commonly P/Invoke).

APShredder
+1  A: 

No, C# projects can't include source code from other languages.

What you can do, though, is use C++/CLI which can be linked directly with C code into a single .NET assembly. The most straightforward path is to use C++/CLI to do whatever you planned to do with C# -- it has access to all the .NET libraries that C# does. But you could also have both a C++/CLI project containing the C code, and a C# project, and use ILMerge to meld them into a single DLL.

Ben Voigt
Wait, doesn't ILMerge require both inputs to be pure IL?
Steven Sudit
You can compile most native C and C++ code to pure IL, using `/clr:pure`.
Ben Voigt
could you provide some links on tuts on such compiling with /clr:pure and than using compiled from C#?
Blender
I'm familiar with regular `/clr`, but had to avoid `/clr:pure` because it doesn't generate genuine C/C++ code. For one thing, it requires all functions to use `_clrcall`, which was a showstopper for me since the whole point of using C++ was to expose a `_stdcall` function. In general, pure mode can't do everything that C++ is capable of.
Steven Sudit
@Ole: Here's a pair of useful links: http://msdn.microsoft.com/en-us/library/ms173253(VS.80).aspx, http://msdn.microsoft.com/en-us/library/ms173265(v=VS.80).aspx
Steven Sudit
@Steven: Calling conventions are the responsibility of the JIT in .NET. I'd be somewhat surprised if the C++/CLI compiler doesn't automatically emit the proper attributes when it converts function pointers in C code into .NET delegates. Or are you talking about native exports? Naturally you can't have native exports from a DLL that contains no native code, but you can have shared source code between the native and managed DLLs. Did you report the lack of support for stdcall on Microsoft Connect? Post a link to the bug report and I'll see that it's escalated.
Ben Voigt
I'm talking about native exports, but there's no "naturally" about it. A .NET class exposed as a COM object has no native code, yet it can be called through what is essentially a C++ interface because it's wrapped appropriately. A pure CLR C++ assembly, however, does not support this, and is not likely ever to. After all, if we really want to export a `_stdcall` function, nothing stops us from using an impure CLR assembly. However, once we do, ILMerge is no longer an option, which is my point here.
Steven Sudit
C++/CLI doesn't support the `COMVisibleAttribute`? This other question suggests that it works ok... http://stackoverflow.com/questions/1256047/comvisible-in-c-cli
Ben Voigt
Anyway, portable library code isn't likely to do anything that is incompatible with `/clr:pure`.
Ben Voigt
@Ben: Here you are likely correct. I think the only area where there might be some trouble is in memory management.
Steven Sudit
@Ben: And, to clarify, yes, C++/CLI supports COMVisibleAttribute. I mention it as an example of how pure CLI can still be callable from non-CLR sources *if* there is special support for it. I still can't expose a C# (or pure C++/CLI) static method so that someone using `LoadLibrary`/`GetProcAddress` can reach it, though.
Steven Sudit
I've actually heard rumors that native exports are possible using ilasm. If true, then it would be natural for the C++/CLI compiler to work the right magic in `/clr:pure` mode. But maybe ilasm emits mixed-mode assemblies when those directives are used.
Ben Voigt
+1  A: 

There's a CIL backend for gcc and a few other attempts to build C to CIL compilers. These will produce standard .Net libraries which can be called from C#, but they will be in separate projects. (You'd need to compile the C project into a library and reference it - although you could later merge them into a single assembly if required.) Unfortunately the tools available for C to CIL development are almost severely lacking, so I'd question whether it's worthwhile rather than just wrapping it up with p/invoke. You're also going to get a performance slowdown using it, which is half the reason to use p/invoke rather than writing managed code anyway.

Mark H
I like this Idea, could you please provide more information on this topic? (links)
Blender
I'm not familiar with using it. There's some information here: http://mono-project.com/Gcc4cil which may help. This project actually calls the native code I believe (produces a managed wrapper) rather than rebuilding the entire code in CIL.
Mark H
As Ben points out elsewhere, VC++ has support for generating CIL. I would think that MS tools would be the first choice when doing .NET.
Steven Sudit