我们目前在内部就实际的.NET 程序集名称是否应该包含代码的版本号（例如CodeName02.exe 或CompanyName.CodeName02.dll）进行了激烈的内部辩论。有没有人知道像微软这样的权威来源可以提供关于这个问题的指导？
Steve
问问题
2240 次
9 回答
12
这就是 Properties/AssemblyInfo.cs 文件的用途。
该文件中有两个版本，文件版本和程序集版本：
[assembly: AssemblyVersion("1.1.0.256"]
[assembly: AssemblyFileVersion("1.1.0.256")]
一旦设置好这些，您就可以使用它们来跟踪您的二进制文件的版本。可以在资源管理器中通过右键单击-> 属性轻松查看。
Microsoft 的应用程序（和操作系统）中包含的任何 dll 或 exe 名称都没有使用该约定。
其他系统将使用这些数字来解决依赖关系并验证版本。例如，MSI 系统将根据版本属性更新二进制文件。
于 2008-11-21T21:25:24.780 回答
8
微软的Krzysztof Cwalina和Brad Abrams的框架设计指南建议将程序集命名为
<Company>.<Component>.dll
我进一步支持这一点（不使用版本号），因为 GAC 和 dll 文件属性将显示版本。
于 2008-11-21T21:25:52.393 回答
4
我知道 DevExpress网站使用版本指示符作为其程序集名称的一部分，例如 XtraEditors8.2.dll。我猜原因是您希望能够在同一目录中拥有多个版本的程序集。例如，我们有大约 15 个智能客户端，它们作为同一外壳/客户端的一部分分布。每个 smartclient 可以有不同版本的 DevExpress 控件，因此我们需要能够让 XtraEditors7.1.dll 和 XtraEditors8.2 存在于同一目录中。
我会说，如果您有公共库是可重用模块的依赖项并且可以存在于多个版本 1.0、1.1、1.2 等中，那么版本号可以包含在名称中以避免冲突将是一个有效的论点。鉴于通用库不在 GAC 中。
于 2009-02-11T13:53:11.047 回答
3
我不知道有任何权威性，但在我看来，使用一致的名称可以简化从安装脚本到文档的所有过程。鉴于可以将版本作为元数据存储在文件中，我不知道为什么在文件名中需要它。为什么要为不得不考虑不同名称的文件而烦恼呢？
于 2008-11-21T21:23:26.487 回答
3
只需查看 .NET 框架或任何其他 Microsoft 产品即可。将版本号作为程序集名称的一部分听起来是个坏主意。
在程序集的元数据部分中有此（和其他信息）的位置。(AssemblyInfo.cs)
此信息可以在 Windows 资源管理器中查看（属性对话框、状态栏、工具提示 - 它们都显示此信息）。
于 2008-11-21T21:24:12.647 回答
1
我认为将版本号放在 DLL 的文件名中的主要思想是从DLL Hell带来的，其中有多个版本的 DLL，所有版本都具有相同的名称会导致问题（即你有哪个 DLL 的实际版本和它是否具有所需的功能等）。
与更传统的 C/C++ DLL 文件相比，.NET 框架处理的依赖关系完全不同，GAC 中可能有多个版本的库，主要是因为 GAC 是链接到其他文件的“假”文件夹在文件系统上，除了能够将程序集包含在可执行安装中（相同的文件夹部署等）。
于 2008-11-24T15:38:00.473 回答
0
版本信息可以包含在 assemblyInfo 文件中，然后可以通过反射等方式进行查询。
一些供应商在名称中包含版本号，以便一目了然。Microsoft dll 名称在框架目录中不包含版本号。
于 2008-11-21T21:23:33.863 回答
0
由于版本可以设置为属性，这不是半多余的吗？
我也会冒险并建议 MS 没有标准，因为快速查看它们的 DLL 名称：user32.dll、tcpmon.dll、winsock.dll 等。
于 2008-11-21T21:24:54.750 回答
0
Microsoft used a suffix of 32 to denote 32 bit DLL versions so that those DLL's could coexist with the existing 16 bit DLL files.
于 2011-04-26T02:03:11.550 回答