Click here to Skip to main content
15,038,345 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
I have written a DLL in C# which has a static class to be used in MFC. Can you tell me is this possible? If so, how can I reference the DLL in visual studio .net.
Thanks in advance.
Please see my update to my Answer: added reference to original work.


have a look at this msdn forum thread. There are some links that might point you to a solution:[^]
Shah Rukh Qasim 6-Jan-11 1:33am
OK, tell me that can we use GetProcAddress method with C# DLLs?
No. Not just "no", it's "of course not, ever, for a regular .NET Assembly!"

Please see my answer. I mean, if the assembly is modified as I described, yes, it will be accessible via LoadDLL and GetProcAddress.
@JF2015: In the first edition of my answer I forgot to credit your Answer (I'll vote 5).
Now I've fixed that. Also, added/improved motivation; will you take a look? -- pretty interesting...
Thank you.
Shah, my reply about GetProcAddress was inaccurate -- now clarified. Please see.
Sorry for the inconvenience.
The most usual technique to make a functionality of .NET Assembly accessible to native (unmanaged executables) is using COM. Relevant references can be found from the Answer by JF2015.

There are certain problems with COM. The technology is gradually becoming obsolete. Main problem is overhead. In particular, normally it requires registration of a component in the system registry -- one of the major sources of registry contamination. .NET and Microsoft are trying to go away from such things in favor of local approach to component dependency and versioning. Also, COM approach will hardly be available for Unix (with Mono or other product).

In view of all that, a direct export from managed assembly to the unmanaged executable would be quite attractive. But how to do this?

Officially, it is said that an assembly cannot export an umnanaged method, so .NET Assembly cannot be used by a native (unmanaged) application (MFC or something).

This is a subtle lie. If you look at the standard IL, there is a way to export a method as unmanaged (native). Indeed, it cannot be done with C# along. So, what to do? Right!

The trick is to do several additional build steps to automatically do the trick. These steps can be nicely embedded into the project (see Microsoft documentation on MSBuild -- very comprehensive). Here are the steps:

1) After .NET Assembly is compiled, disassemble into IL code;
2) Open IL file and transform the text to mark the unmanaged entry points;
3) Re-compile modified code back to executable assembly; now it exports few unmanaged method.

This needs good knowledge of IL (but no programming skills). Note, that when the tool is already available, IL programming is not required at all.

We need another trick: how to mark what methods to export as unmanaged. Naturally, those should be some static functions using common data types for parameters. But usually we need to export not all of them, only a part.

For this purpose, we can create a special attribute and mark an assembly with this attribute:

This will mean that all static functions of the classes MyClass1 and MyClass2 should be exported as unmanaged. Alternatively (or additionally), separate methods can be marked by the attribute (in this case, only those methods will be exported as unmanaged -- even better).

The text-processing utility working with the disassembled IL code should perform text search to find the attribute and perform the modification to the specified methods.

These are the references to the original articles:

"Unmanaged code can wrap managed methods" by Emilio Reale, 29 Aug 2004.

"How to Automate Exporting .NET Function to Unmanaged Programs" by Selvin, 22 Nov 2006.

As it often happens to a decent serious publication, these CodeProject articles collected not very good votes (I suggest everyone who is interested supports the authors).

New work found in a reader's Message: "C# Project Template for Unmanaged Exports" by Robert Giesecke, Jan 11, 2010.

100% credit to these authors.

I tried to use only slightly different approach (so it would be purely derivative work), but my code (circa 2006) is not operational yet. Later on, I lost interest to this topic due to deeper focus on managed platforms I developed. If I ever find time to put my minor improvements, and if still there is interest, I could post it as a derivative work -- not sure now though.
Updated. Added/improved motivation and added a credit to the Answer by JF2015.
JF2015 6-Jan-11 3:14am
Very Good Answer. It'd be great If you could find your old source and show it to us. Have my 5!
Espen Harlinn 6-Jan-11 3:16am
5+ Nice work ... interesting idea
This is pretty tricky technique. I think this is essentially the only one thing to be done with C#.

Another technique might be using a mixed-mode C++/CLI project, but... are you only asking about C# only?

Finally, I found original article -- please see the updated Answer. [EDIT] Found by now -- see updated Answer. [END EDIT]
Very funny there is a vote of "1". I almost proud of it: I noticed the best answers often irritate some people and got "1" or "2" (of course, worse answers also got "1" but not so often). Also, lamers hate when somebody offer them to think... sad -- not for me, for them.
Rajesh R Subramanian 6-Jan-11 4:07am
I agree about the 1-voting losers. I've had this happen to me in the past (even on the regular forums).
I know, Rajesh, I happened to notice some of your answers.
May be some will need counter-acting.
--Thank you.
Updated the Answer: added credits and reference to original work -- happen to be in CodeProject!
fjdiewornncalwe 6-Jan-11 15:32pm
+5. Thorough and accurate as usual.
Nuri Ismail 7-Jan-11 13:38pm
Wow, Great! +5
Thanks for good words, people. I did not expect such popularity.
Don't forget all credit goes to original inventor -- Selvin.
Edited, added two more references. I remembered I saw more than one.
Dalek Dave 8-Jan-11 8:29am
Excellent Answer!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900