当前位置:主页   - 电脑 - 网站开发 - ASP.Net
CLR 全面透彻解析:托管和本机代码互操作性
来源:网络   作者:   更新时间:2012-02-25
收藏此页】    【字号    】    【打印】    【关闭

CLR 全面透彻解析:托管和本机代码互操作性目录

  托管和本机代码互操作适用哪种场合?

  互操作技术:三种选择

  互操作技术:P/Invoke

  互操作技术:COM Interop

  互操作技术:C++/CLI

  互操作体系结构注意事项

  API 设计和开发人员体验

  互操作边界的性能和位置

  生存期管理

  托管和本机代码互操作适用哪种场合?

  有关使用托管和本机代码互操作适宜时机的论述并不多,现有的论述也以自相矛盾者居多。有时,指南还缺乏实践体验做依据。因此,我先声明我编写的这个指南以我们互操作团队的实践经验为基础,它已向各类内部和外部客户提供过帮助。

  在总结这一经验时,我们采纳了三种产品,由它们充当成功使用互操作和典型使用方式的上佳示例。提及互操作时,我首先想到的应用程序就是 Visual Studio Tools for Office,它是 Office 的托管扩展性工具集。它代表互操作的一种典型使用情况——一个想要启用托管扩展或加载项的大型应用程序。另一个就是 Windows Media Center,从一开始,它就是一个混合了托管和本机的应用程序。开发 Windows Media Center 主要使用的是托管代码和本机代码中内置的一些内容,即负责直接处理 TV 调谐器和其他硬件驱动程序的代码段。最后是 Expression Design,一个具备大型预置本机代码库的应用程序,它计划利用 Windows Presentation Foundation (WPF) 这一新的托管技术,提供全新的用户体验。

  这三个应用程序解释了使用互操作的三个最普遍的原因:让原有的本机应用程序具备托管扩展性;让应用程序的大部分内容能利用托管代码的优点,同时又能在本机代码中编写最基础的代码段;为现有本机应用程序注入全新的用户体验。

其它资源
来源声明

版权与免责声明
1、本站所发布的文章仅供技术交流参考,本站不主张将其做为决策的依据,浏览者可自愿选择采信与否,本站不对因采信这些信息所产生的任何问题负责。
2、本站部分文章来源于网络,其版权为原权利人所有。由于来源之故,有的文章未能获得作者姓名,署“未知”或“佚名”。对于这些文章,有知悉作者姓名的请告知本站,以便及时署名。如果作者要求删除,我们将予以删除。除此之外本站不再承担其它责任。
3、本站部分文章来源于本站原创,本站拥有所有权利。
4、如对本站发布的信息有异议,请联系我们,经本站确认后,将在三个工作日内做出修改或删除处理。
请参阅权责声明