托管 CLR 与使用 ClrCreateManagedInstance - 有什么好处？答案

【问题标题】：Hosting CLR versus using ClrCreateManagedInstance - what are the benefits?托管 CLR 与使用 ClrCreateManagedInstance - 有什么好处？
【发布时间】：2010-10-22 12:00:30
【问题描述】：

如here 所述，我已成功实现 Win32 应用程序和托管 .Net dll 之间的互操作。但我也读到here 可以将整个 CLR 托管在非托管进程中。

所以我的问题是：你为什么要这样做？它比仅仅使用一个对象要复杂一些——以增加复杂性为代价，您可以获得什么好处？

编辑：我从 2 个第一个答案中了解到，您可以根据自己的需要自定义 CLR - 这意味着如果您正在编写一个简单的商业应用程序，您将永远不需要托管。托管适用于系统重的东西，例如浏览器或 SQL Server。

【问题讨论】：

标签： c# .net delphi interop

【解决方案1】：

托管 CLR 通常不是您在托管代码和 Win32 之间进行互操作的事情。互操作一般有3种方法：

运行时可调用包装器 (RCW) - 从 .NET 调用 COM 对象
COM 可调用包装器 (CCW) - 使 .NET 对象显示为 COM 对象
P/调用

这些从 .NET 的第一个版本开始就受到支持。托管 CLR 的全部意义在于允许您将 .NET 代码深度嵌入到非托管应用程序中。例如，有一个模块可以在 Win32 上的 Apache 中托管 .NET，从而允许它运行 .aspx 页面。

同样，SQL Server 希望人们能够使用托管代码编写扩展存储过程和函数。过去你可以用 C/C++ 编写这些，但如果他们托管 CLR，他们实际上可以允许人们用 C# 编写这些。让 CLR 进入一个可以安全嵌入的状态的工作确实推迟了时间线，因此诞生了诸如对内存和安全性的控制之类的东西。 SQL Server 有一些严格的稳定性要求，您不能让 .NET 摇摆不定。

托管 API 从 .NET 1.x 到 2.x 发生了显着变化，但由于 2.0 CLR 经历了 .NET 3.0、3.5 等，因此更加稳定。

【讨论】：

【解决方案2】：

Microsoft SQL Server 广泛使用它来代替安全性、程序集加载、内存管理、线程管理等等。关于这个主题的一本好书是“自定义 Microsoft .NET Framework 公共语言运行时”。

【讨论】：

【解决方案3】：

您可能有一个遗留应用程序，并希望允许第 3 方从您的应用程序中使用 .net 的设施，但特别是以一种受控方式例如控制从哪里加载程序集。 Here 就是一个例子。

【讨论】：

好链接，谢谢。不过，我的问题更多的是关于为什么需要更多控制权。