Question

我觉得这很明显，但我觉得最好问：

如果应用程序（exe）被编译为在.net 3.5上运行，如果它使用的dll是为.net 1.1编译的，那么DLL会自动使用2.0 CLR，即父项吗？

反之亦然？

如果是这样，兼容性问题呢？

Answer 1

没有。如果你的目标是3.5版本的框架，如果不存在3.5，它就不会奇怪地使用2.0。

但您可以使用assemblybinding中的app.exe.config bindingredirect来指定替换版本：

<configuration>

   ....

  <runtime>
    <assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentassembly>
        <assemblyidentity name="System" culture="neutral" publickeytoken="969db8053d3322ac" />
        <bindingredirect newVersion="2.0.0.0" oldVersion="1.0.5000.0" />
      </dependentassembly>
      <dependentassembly>
        <assemblyidentity name="System.Windows.Forms" culture="neutral" publickeytoken="969db8053d3322ac" />
        <bindingredirect newVersion="2.0.0.0" oldVersion="1.0.5000.0" />
      </dependentassembly>      
    </assemblybinding>
  </runtime>

</configuration>

请参阅Redirecting Assembly Versions

Answer 2

EXE文件决定了进程将使用的.NET运行时版本。为早期版本的.NET编译的任何程序集都必须使用“进程版本”。这通常适用于.NET几乎没有重大变化。

使用.NET 1.1 DLL的.NET 3.5应用程序将在CLR 2.0上运行该DLL（.NET 2.0,3.0和3.5都使用相同的CLR 2.0版本）。

.NET 4有一个新的CLR，.NET 4的一个新功能是in-process side by side CLR hosting，允许在同一个进程中使用多个版本的.NET，这可能会改变答案。

Answer 3

如果您的应用程序使用框架3.5（实际上是CLR 2）并且它加载为CLR 1.0或CLR 1.1编译的dll，那么这些dll将自动使用CLR 2。你不能走另一条路 - 即。你不能将CLR 2 dll加载到CLR 1进程中而不会受到一些伤害。

在CLR 4中，这些规则稍有改变，因为您现在可以在给定进程中拥有多个CLR实例，但这只有在通过COM实例化对象时才有意义，而不是通过正常反射加载。

哪个CLR将使用为不同版本的.net编译的DLL使用？

3 个答案: