在MFC中加载C#DLL [英] loading C# DLL in MFC

查看:93
本文介绍了在MFC中加载C#DLL的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经用C#编写了一个DLL,该DLL具有要在MFC中使用的静态类.你能告诉我这可能吗?如果是这样,如何在Visual Studio .net中引用DLL.
预先感谢.

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.

推荐答案



看看这个msdn论坛线程.有一些链接可能会为您提供解决方案:

http://social.msdn.microsoft.com/论坛/en-US/csharpgeneral/thread/f5a2e721-728f-498e-a398-43237e16bd75 [
Hi,

have a look at this msdn forum thread. There are some links that might point you to a solution:

http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/f5a2e721-728f-498e-a398-43237e16bd75[^]


实现的最常用技术.本机(非托管可执行文件)可访问的.NET程序集正在使用COM.相关参考可以从JF2015的答案中找到.

COM存在某些问题.该技术正在逐渐过时.主要问题是开销.特别是,通常它需要在系统注册表中注册组件-注册表污染的主要来源之一. .NET和Microsoft试图摆脱这种局面,转而采用本地方法来实现组件依赖关系和版本控制.而且,COM方法几乎不适用于Unix(带有Mono或其他产品).

考虑到所有这些,从托管程序集直接导出到非托管可执行文件将非常有吸引力.但是该怎么做呢?

正式地,据说程序集不能导出一个废弃的方法,因此.NET程序集不能被本机(非托管)应用程序(MFC之类)使用.
这是一个微妙的谎言.如果您查看标准IL,则有一种方法可以将方法导出为非托管(本机)方法.确实,这不能与C#一起完成.那么该怎么办?对!

诀窍是执行几个附加的构建步骤以自动完成该技巧.这些步骤可以很好地嵌入到项目中(请参阅MSBuild上的Microsoft文档-非常全面).步骤如下:

1)编译.NET Assembly后,将其反汇编为IL代码;
2)打开IL文件并转换文本以标记非托管入口点;
3)将修改后的代码重新编译回可执行程序集;现在它导出了一些非托管方法.

这需要对IL有良好的了解(但不需要编程技能).请注意,当该工具已经可用时,根本不需要进行IL编程.

我们需要另一个技巧:如何标记要导出为非托管的方法.自然地,那些应该是一些使用通用数据类型作为参数的静态函数.但是通常我们不需要全部导出,而只需导出一部分.

为此,我们可以创建一个特殊属性,并使用该属性标记装配体:
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:
[assembly:ExportToManaged(typeof(MyClass1))] 
[assembly:ExportToManaged(typeof(MyClass2))]



这意味着应该将所有类MyClass1MyClass2的静态函数导出为非托管函数.另外(或另外),可以通过属性标记单独的方法(在这种情况下,只有那些方法将被导出为非托管方法-甚至更好).

与反汇编的IL代码一起使用的文本处理实用程序应执行文本搜索以找到属性,并对指定的方法进行修改.

这些是对原始文章的引用:

Emilio Reale的非托管代码可以包装托管方法" .

Selvin的如何将.NET功能自动导出到不受管理的程序中" .

由于经常发生在体面的严肃出版物上,因此这些CodeProject文章获得的票数不是很好(我建议有兴趣的每个人都支持作者).

读者的留言中发现了新作品: 用于不受管理的出口的C#项目模板",作者:Robert Giesecke,2010年1月11日


这些作者100%的信用.


我尝试仅使用略有不同的方法(因此,这将是纯粹的派生工作),但是我的代码(大约在2006年)尚未投入使用.后来,由于更加关注我开发的托管平台,我对该主题失去了兴趣.如果我有时间进行我的小改进,并且仍然有兴趣,我可以将其发布为衍生作品-不过现在还不确定.



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.


这篇关于在MFC中加载C#DLL的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆