我可以在 .NET 2.0 应用程序中使用 .NET 4.0 库吗? [英] Can I use a .NET 4.0 library in a .NET 2.0 application?

问题描述

我在 .NET 2.0 应用程序中使用我的 .NET 4.0 库时遇到了一些问题.我想我的印象是作为 Windows DLL，我的其他 .NET 应用程序将能够访问它.不是这样吗?在支持两种环境中的应用程序方面有什么建议吗?

I'm running into some problems using my .NET 4.0 libraries in .NET 2.0 applications. I guess I was under the impression that being a Windows DLL, my other .NET apps would be able to access it. Is this not the case? Any recommendations in terms of supporting applications in both environments?

编辑:我意识到我需要在目标系统上安装 .NET 4.0 Framework，是否还有其他原因导致这不起作用/不应该?

EDIT: I realize that I'd need to install the .NET 4.0 Framework on the target system, are there other reasons why this won't/shouldn't work?

编辑:可能应该更具体.我们有一个用 .NET 2.0(准确地说是 ASP.NET)编写的当前大型/复杂的应用程序.我们在 .NET 4.0 中编写了一组新的集成工具和工作流项.我们想将 4.0 创建的库之一添加到 .NET 2.0 项目(当前在 VS2008 中)并使用其中的一些方法.当我们这样做时，我们会遇到问题，通常是与内存相关的神秘错误.

EDIT: Probably should have been more specific. We have a current, large/complex, application written in .NET 2.0 (ASP.NET be exact). We have a new set of integration tools and workflow items we are writting in .NET 4.0. We wanted to add one of the 4.0 created libraries to the .NET 2.0 project (currently in VS2008) and make use of a few of it's methods. When we do this we run into problems, often cryptic errors relating to memory.

最后看来，Earwicker 和 Brian Rasmussen 都是正确的.由于我不太热衷于通过 COM 公开事物(不确定这在技术上是否是 COM，但无论如何)我想我会坚持认为两者不兼容"并寻找其他方式，我认为我们已经根据我们的特定需求.从长远来看，我们将考虑将 .NET 2.0 代码升级到 4.0.

It would appear that both Earwicker and Brian Rasmussen are correct in the end. As I'm not too keen on exposing things via COM (not sure if this is technically COM or not but regardless) I think I will stick to the idea that the two are not 'compatible' and look to other means, which I think we have based on our specific needs. Longer term we will look to move the .NET 2.0 code up to 4.0.

推荐答案

是的，这是完全可能的.您只需将在 4.0 中编写的组件公开为 COM 对象.2.0 托管应用程序只是将它们用作 COM 对象，并且不知道它们是本机、2.0、4.0 还是其他版本.COM 是两个运行时版本必须以相同方式实现的公共接口.

Yes, this is perfectly possible. You just expose the components written in 4.0 as COM objects. The 2.0 hosting application just uses them as COM objects and has no idea whether they are native, 2.0, 4.0 or whatever. COM is the common interface that both runtime versions have to implement identically.

4.0 中新的进程内 SxS 支持意味着当加载基于 4.0 的 COM 对象时，它会引入所需的运行时而不是尝试在 2.0 上运行，因此两个运行时都存在于管理自己的进程中对象.虽然你不能直接在它们之间传递 CLR 对象，但你可以传递 COM 接口，CLR 会为你透明地将你的对象包装在 COM 接口中.

The new in-process SxS support in 4.0 means that when the 4.0-based COM object is loaded, it pulls in the required runtime instead of trying to run on the 2.0, so both runtimes are present in the process managing their own objects. Although you can't directly pass CLR objects between them, you can pass COM interfaces, and the CLR transparently wraps your objects in COM interfaces for you.

我不知道您是否可以为两个版本制作单个互操作程序集.但很明显，您可以在 2.0 中用 C# 编写互操作程序集，将其导出为 .tlb，然后将其导入 4.0 中的程序集.这为您提供了两个描述相同 COM 接口的匹配互操作程序集.(或者只是在每个版本的程序集项目中构建相同的 C# 源代码).

I don't know if you can make a single interop assembly for both versions to work from. But clearly you could write an interop assembly in C# in 2.0, export it to a .tlb, and then import it into an assembly in 4.0. That gives you two matching interop assemblies describing identical COM interfaces. (Or just build the same C# source in each version's assembly project).

奖励更新:生成的应用程序是否基于 COM(无论会带来什么问题)?

Bonus Update: Will the resulting application be COM-based (with whatever problems that entails)?

这取决于你如何看待它.组件的作者将它们制作为 COM 组件.因此宿主应用程序需要定位并加载它们作为 COM 组件.这意味着在 GAC、注册表或 SxS 清单上胡闹，这比仅仅告诉组件作者将他们的程序集放在某个目录中以便您可以通过反射加载它要干净得多.

It depends how you look at it. Authors of components will be making them as COM components. So the host application needs to locate and load them as COM components. This means fooling around with the GAC, the registry or SxS manifests, which is a lot less clean than just telling component authors to drop their assembly in a certain directory so you can load it with reflection.

它在运行时会产生影响:当宿主引用一个组件时，将不会涉及一个而是三个对象.主机具有对 RCW 的引用，RCW 具有指向由 CCW 实现的 COM 接口的指针，而 CCW 又持有对实际组件的引用.中间的 CCW 是一个引用计数的 COM 对象，宿主的 RCW 有一个终结器，它在 CCW 上调用 Release，当它被销毁时，它会释放 GCRoot这使实际组件保持活动状态.

And it has an impact at runtime: when the host has a reference to a component, there will be not one but three objects involved. The host has a reference to a RCW, which has a pointer to a COM interface implemented by a CCW, which in turn holds a reference to the actual component. The CCW in the middle is a reference-counted COM object, and the host's RCW has a finalizer that calls Release on the CCW, and when it is destroyed it deallocates the GCRoot that is keeping alive the actual component.

这意味着 - 回调指针的排列足够复杂，等等 - 系统最终可能会遇到循环引用计数问题，其中一个断开连接的孤岛"对象都持有彼此的引用，因此它们永远不会得到解除分配.

This means that - with a sufficiently complicated arrangement of callback pointers, etc. - the system may end up with circular reference counting problems, where a disconnected "island" of objects are all holding references to each other and so they never get deallocated.

这篇关于我可以在 .NET 2.0 应用程序中使用 .NET 4.0 库吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！