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