【发布时间】:2013-03-12 03:23:01
【问题描述】:
对于我们的企业应用程序,我们有一些作为 dll 引用的程序集和其他作为项目引用的程序集。
对于被引用为 dll 的那些,我们已将“特定版本”设置更改为 false。
作为项目引用的那些没有这样的设置。如果我们必须为引用的项目程序集之一部署修复程序,运行时将如何知道要搜索的版本? 我们是否也必须部署主项目?
【问题讨论】:
标签: .net assemblies versioning
对于我们的企业应用程序,我们有一些作为 dll 引用的程序集和其他作为项目引用的程序集。
对于被引用为 dll 的那些,我们已将“特定版本”设置更改为 false。
作为项目引用的那些没有这样的设置。如果我们必须为引用的项目程序集之一部署修复程序,运行时将如何知道要搜索的版本? 我们是否也必须部署主项目?
【问题讨论】:
标签: .net assemblies versioning
这里要理解的关键点——“特定版本”与应用程序在运行时的行为无关——它不会影响 .net 运行时解析程序集的方式。
所有“特定版本”的作用是告诉 Visual Studio(而不是编译器),当项目加载到 IDE 中时,如果 DLL 引用在可解析的位置不可用,是否接受不同版本的同一个DLL。 如果“特定版本”设置为 TRUE,并且您卸载/删除了项目的某些依赖项,则 Visual Studio 将在解决方案资源管理器中的该引用上放置一个小感叹号。如果“特定版本”设置为 FALSE,并且该 DLL 的另一个版本可用(假设 VS 可以找到它),那么 Visual Studio 将改为引用该 DLL。当然,这只会在您下次构建时体现出来……您的新输出将引用“后备 DLL”。
生成的输出是相同的,但是 - 因为您的项目在编译时引用的任何 DLL 版本,都是在运行时需要的 DLL 版本 - 它不能被另一个版本替换(我当然是,此处仅指强命名的 DLL,而忽略 explicitly declared version redirection)。
这对您的特定场景意味着什么 - 在您不使用特定版本控制的情况下 - 您将需要跟踪您的项目在编译它们时具有哪些依赖项(Excel 电子表格任何人?哎呀......) - 因为如果查看源代码管理,您将无法保证项目引用的版本是实际编译到项目中的版本。当然,您应该保留发布到野外的所有二进制文件的副本,这样您就可以检查这些文件以查看部署给客户的内容...
要回答您的问题 - 不,您不必部署主项目 - 您只需要在部署它们时知道这些依赖项项目的版本,这样您就可以构建兼容的热修复程序。 ..
...或者编写一个新的 DLL 并执行从旧版本到新版本的程序集绑定重定向。
【讨论】: