FSharp.PowerPack.dll仍然是（为什么？他们是否会放弃它？）仅引用面向.NET 2.0的FSharp.Core.dll 2.0。同时FSharp.Core.dll 4.0与.NET 2.0不兼容。
当FSharp.Core.dll 2.0和4.0都在GAC中时，它是如何进行的？它加载4.0，因为它与当前的.NET框架兼容，然后告诉FSharp.PowerPack.dll所有内容都已加载。这可以在Visual Studio调试器中看到，当应用程序加载时和在Reflector中遍历依赖项时。
在我们需要以便携方式重新分发软件之前，一切都很好。当我们真正需要时，我们将FSharp.Core.dll 4.0（使用.NET 4.0发声）和FSharp.PowerPack.dll复制到应用程序本地代码库。然后它（突然！）抱怨没有满足FSharp.Core.dll 2.0 [来自PowerPack]的引用。
通过简单地重定向对现有版本的FSharp.Core.dll的引用，可以通过F# PowerPack Target Runtime主题中提到的残酷方式轻松解决问题。
问题是，当我们引用安装到GAC的程序集时，如果没有任何重定向，一切正常。对于GAC，似乎对FSharp.Core.dll 2.0本身的存在感到满意，然后它只是抛弃它，使用4.0版本用于所有目的。这背后的逻辑是什么？
Jeffrey Richter的 CLR通过C＃似乎对此一无所知...
答案 0 :(得分：4)
首先，您需要知道CLR 4.0从CLR 2.0引入了单独的GAC。 CLR 4.0的GAC看到了旧版本，但反之亦然。
现在，在CLR 4.0 GAC中，是重定向 - FSharp.Core的发布者策略文件，它将任何请求重定向到加载版本2.0到4.0。这包含与链接到的配置文件基本相同的内容。
在CLR 2.0 GAC中没有这样的重定向，显然是因为4.0不在GAC中，并且无论如何都不兼容。
要自己看看，在加载FSharp.Core时使用融合日志查看器（fuslogvw） - 它应该显示重定向。
另请查看我的CLR 4.0 GAC中的pub.config文件，该文件位于C：\ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ policy.2.0.FSharp.Core \ v4.0_2.0.0.0__b03f5f7f11d50a3a < / p>