2

我在这里阅读了一些关于 GAC 的帖子，以及为什么永远不应该通过将共享程序集安装到 GAC 中来部署应用程序。我认为这是有道理的，因为它应该使更新客户端计算机上的应用程序更容易。

但是，我可以看到 GAC 在两个方面很有用，即在开发期间和在构建服务器上。

例如，如果您使用 Microsoft 应用程序块，您可以将它们安装到 GAC 中并在那里引用它们。这是有道理的，因为这样做比拥有和绝对引用路径更容易，并且每个开发人员机器上的路径可能不同。这也比拥有一个包含所有共享组件的共享网络驱动器要好 - 已经做到了。

然后，您可能会对构建服务器执行相同的操作。但是，我看到的唯一问题是您有一个使用 2.0 版应用程序块的应用程序。稍后您将其升级为使用 3.1 版。在某些时候，您可能需要重新创建该应用程序的早期版本来测试客户发现的错误，但是当您重新创建构建时，它将选择应用程序块的 3.1 版本，而不是最初构建时所针对的 2.0 版本。这是真的，还是旧项目文件仍然会引用旧版本的 dll，只要它在 GAC 中？

你对这个特定点有什么想法/意见？

我希望能够将所有版本的共享组件（我们下载或构建）作为 MSI 分发给所有开发人员，这些 MSI 安装到 GAC 中，并作为应用程序安装程序的一部分部署到客户机器上。这是最好的方法吗？

4

2 回答 2

2

你对这个特定点有什么想法/意见？

我总是将主二进制文件保存在 .NET 软件项目的 Resource/Library 文件夹中。显然这个文件夹是版本化的。无论如何，这些天存储很便宜，所以它并没有太大的区别。

这有几个目的：

  • 项目是原子的，它们不依赖于 GAC 中某个库的特定版本。因此，只需检查一下，就很容易重现以前的一些修订。一切都会奏效。
  • 它只需要一台干净的开发机器（当然，安装了所有 .NET 服务包和主要 SDK），以便开始检查项目、运行完整的集成构建并开始工作。

当有超过 10 个不同的项目需要管理时，这就开始产生一些影响。

于 2009-06-18T10:11:04.133 回答
0

如果您不使用较新的程序集重建旧应用程序，旧应用程序将从 GAC 中选择旧版本的程序集。每个程序集都将此信息保存在它自己的清单中，即它所引用的程序集。如果您使用ILDasm 工具打开程序集，您可以详细检查程序集的清单，其中保留了所有引用程序集的信息。

于 2009-06-18T10:02:01.827 回答