我可以在 .NET 2.0 应用程序中使用 .NET 4.0 库吗？
我在 .NET 2.0 应用程序中使用 .NET 4.0 库时遇到了一些问题。我想我的印象是，作为一个 Windows DLL，我的其他 .NET 应用程序将能够访问它。难道不是这样吗？在支持两种环境中的应用程序方面有什么建议吗？
编辑：我意识到我需要在目标系统上安装 .NET 4.0 Framework，是否还有其他原因导致此操作不起作用？
编辑：可能应该更具体。我们当前有一个用 .NET 2.0（确切地说是 ASP.NET）编写的大型/复杂应用程序。我们在 .NET 4.0 中编写了一组新的集成工具和工作流程项目。我们想要将 4.0 创建的库之一添加到 .NET 2.0 项目（当前在 VS2008 中）并利用它的一些方法。当我们这样做时，我们会遇到问题，通常是与内存相关的神秘错误。
看来厄威克和布莱恩·拉斯穆森最终都是正确的。由于我不太热衷于通过 COM 暴露事物（不确定这在技术上是否是 COM，但无论如何），我认为我会坚持两者不“兼容”的想法，并寻求其他方式，我认为我们根据我们的具体需求。从长远来看，我们将寻求将 .NET 2.0 代码升级到 4.0。
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?
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?
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
是的，这是完全可能的。您只需将 4.0 中编写的组件公开为 COM 对象。 2.0 托管应用程序仅将它们用作 COM 对象，并且不知道它们是本机的、2.0、4.0 还是其他对象。 COM 是两个运行时版本必须以相同方式实现的公共接口。
4.0 中新的进程内 SxS 支持意味着，当加载基于 4.0 的 COM 对象时，它会拉入所需的运行时，而不是尝试在 2.0 上运行，因此两个运行时都存在于管理自己对象的进程中。尽管不能直接在它们之间传递 CLR 对象，但可以传递 COM 接口，并且 CLR 会透明地将对象包装在 COM 接口中。
我不知道您是否可以为两个版本制作一个互操作程序集。但显然，您可以在 2.0 中用 C# 编写互操作程序集，将其导出到 .tlb，然后将其导入到 4.0 中的程序集中。这为您提供了两个描述相同 COM 接口的匹配互操作程序集。 （或者只是在每个版本的汇编项目中构建相同的 C# 源代码）。
额外更新：生成的应用程序是否基于 COM（无论会带来什么问题）？
这取决于你如何看待它。组件的作者将把它们制作为 COM 组件。因此主机应用程序需要定位它们并将它们作为 COM 组件加载。这意味着摆弄 GAC、注册表或 SxS 清单，这比仅仅告诉组件作者将其程序集放在某个目录中以便您可以通过反射加载它要干净得多。
它在运行时会产生影响：当主机引用一个组件时，将涉及到三个对象。主机具有对 RCW 的引用，RCW 具有指向由 CCW 实现的 COM 接口的指针，而 CCW 又保存对实际组件的引用。中间的 CCW 是一个引用计数的 COM 对象，主机的 RCW 有一个终结器，可以在 CCW 上调用
Release，当它被销毁时，它会释放GCRoot这就是让实际组件保持活动状态。这意味着，如果回调指针等的安排足够复杂，系统可能最终会出现循环引用计数问题，其中一个断开连接的对象“岛”都持有彼此的引用，因此它们永远不会被释放。
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.
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.
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).
Bonus Update: Will the resulting application be COM-based (with whatever problems that entails)?
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.
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
Releaseon the CCW, and when it is destroyed it deallocates theGCRootthat 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.
请注意，4.0 版不仅仅是附加程序集。此版本中运行时本身也发生了变化（新的并发 GC 模式、对线程池的大量更改、mscorwks.dll 现在称为 clr.dll 等）。
Please note that version 4.0 is more than just additional assemblies. The runtime itself has also been changed in this version (new concurrent GC mode, lots of changes to the thread pool, mscorwks.dll is now called clr.dll, etc.).
我刚刚发表了一篇基本上是丹尼尔建议的帖子。
如何从基于 .NET 2 的应用程序使用基于 .NET 4 的 DLL
源代码和说明位于：http://code.msdn.microsoft.com/Using-a-NET-4-Based- DLL-bb141db3
I've just published a post basically what Daniel suggested.
How to use a .NET 4 based DLL from a .NET 2 based application
Source Code and description at: http://code.msdn.microsoft.com/Using-a-NET-4-Based-DLL-bb141db3
这可能取决于您如何使用它。在.Net 4.0 中，您可以选择进程内并行执行 (InProc SxS)。这允许您在同一进程空间中托管两个不同版本的 CLR。这是 的解释。
我不知道你是否可以在你的情况下利用这一点。我没有直接的经验可以帮助你。
一些可以使用此功能的场景。
It may be possible depending on how you are using it. In .Net 4.0 you have the option of In Process Side by Side Execution (InProc SxS). This allows you to host two different versions of CLR in the same process space. This is explained here.
Whether you can take advantage of this in your situtaion I don't know. I have no direct experience to help you.
Some scenarios in which this can be used.
看起来 CLR 4 中添加的进程内并行功能在这种情况下没有帮助，因为他想在 .NET2.0 应用程序中使用 .NET4.0 库。据我了解，如果情况相反（在 .NEt4.0 应用程序中使用 .NET2.0），进程内 SxS 将很有帮助，因为 4.0 的 CLR 将与 2.0 中的并行工作。同样的过程..
Looks like the in-process side-by-side feature which was added to CLR 4 wouldn't help in this case since the he wants to use a .NET4.0 library in a .NET2.0 application. As far as I understand it, in-process SxS would be helpful if the case was the opposite (consuming a .NET2.0 in a .NEt4.0 application) as the CLR of the 4.0 will work side by side with 2.0 in the same process..
为 .NET 4 编译的程序集将包含对 .NET 2.0 中不存在的其他 .NET 4 框架库的引用。
如果您希望您的应用程序与 .NET 2.0 兼容，您可以使用 Visual Studio 2005 或
Your assembly compiled for .NET 4 will contain references to other .NET 4 framework libraries that are not present in .NET 2.0.
If you want to have your applications compatible with .NET 2.0 you can use Visual Studio 2005 or target your projects to .NET 2.0 if you are using Visual Studio 2008 or 2010. Of course, if you target your projects to .NET 2.0 you will not be able to take advantage of .NET 3.5/4 features.
我的应用程序也遇到了类似的问题，我无法引用使用 .net 4.0 组件的 API。
为了解决这个问题，我创建了一个新的类库项目，该项目引用我的 .net 4.0 项目，然后从我的 .net 2.0 项目中调用该新程序集。
我映射了从 .net 4.0 项目返回的数据以供我的 .net 2.0 项目使用。
这解决了我的问题。
I had a similar problem with my application where I was not able to reference an API, that was using .net 4.0 components.
To resolve this I created a new class library project that was referencing my .net 4.0 project and then called that new assembly from my .net 2.0 project.
I mapped the data coming back from .net 4.0 project to be used by my .net 2.0 project.
That resolved my issue.