详细说明如何解决中不同版本无法编译的问题 net框架4.0环境

本文的研究内容：1 .问题推导2。问题解决方案3。原因分析最近部门的开发环境已经更新到WIN7。NET framework4 VS2010，在体验新技术、新环境带来的提高效率的方式方法的同时，也给我们带来了一些兼容性问题。这几天项目在业余时间一直在研究SQLite，做实验的时候遇到了一个问题。代码编译在执行时反复异常中断。发现SQLite.dll是在framework2.0环境下编译的，当前运行环境是framework4.0，所以出现了异常操作，如图3360 。

在未来的开发过程中，可能会引用到一些第三方组件，可能会在旧框架版本下编译，这种问题也会出现。因此，本文提供了一个解决方案，并解释了这个问题的原因。查阅了相关资料，在stackoverflow.com上，建议在配置文件中增加配置：复制代码的代码如下：启动useegacyv2 runtimeactivationpolicy=' true '支持的运行时版本=' v4.0'/该方法在startupMSDN上也有描述，参见http://mdn.microsoft.com/en-us/library/bbx34a2h(vs . 100)。aspx，但是用这个方法编译后问题仍然没有解决，但是问题绝对可以锁定到。net运行时环境。复制代码如下： startup useegacyv2 runtimeactivationpolicy=' true ' supportedruntimeversion=' v 4.0 '/requireduntimelversion=' v 4 . 0 . 30319 '/startup再次运行，问题解决。有必要知道是什么引起的。supportedRuntime标记用于指定的版本；应用程序支持框架运行时；requiredRuntime标记用于指定应用程序仅支持公共语言运行时1.0版本。如果用1.1或更高版本编译，应用程序必须使用supportedRuntime元素；注意：用1.1版或更高版本编译的应用程序必须使用supportedRuntime。仅支持1.0版运行时的应用程序必须使用requiredRuntime。再次参考CLR运行时版本的相关数据，参考以下CLR运行规则和版本间关系汇总表，如下：规则：1。使用CLR 4.0及以上版本编译的应用程序始终在编译应用程序的CLR版本上运行；2.用低于CLR4.0的版本编译的应用程序优先在编译后的CLR版本上运行。如果此版本不存在，将运行低于CLR 4.0的最新版本。总结如下：编译EXE的CLR版本号CLR 1.1安装在机器上。机器上安装了CLR 2.0？机器上安装了CLR 4.0？1.1加载CLR 1.12.0没关系加载CLR2.01.1没关系加载clr2.01.1没关系2.0失败没关系。失败没关系。到目前为止，我们可以清楚地了解各种clr版本之间的关系。总结：微软的每一次版本升级都会带来一些新的问题。在早期，CLRv1.0到CLRv2.0也引起了很多混乱。也可能是因为机构太大。希望在以后的版本升级中，能够真正做到无缝的版本连接。