2

在我所在的地方，我们有大量可以运行的程序，它们都使用位于网络共享上的一组程序集的功能：例如写入公共系统日志、数据库连接字符串、一些常见的业务对象和函数，等等

我们喜欢这种设置，因为它可以轻松部署错误修复和新功能：只需更新共享驱动器上的程序集，并且使用它们的每个应用程序都是最新的。需要打破二进制兼容性？这不是轻而易举的事，但也不是什么大不了的事：只需添加一个带有新版本号的新文件夹。Subversion 知道每个版本的位置，因此仍然可以将错误修复部署到每个版本中重复的代码。可能还会首先进行一些讨论，以确保它确实有必要，因此我们可以将多个更改批处理到一个新集合中，但到目前为止，这样做的需求非常少。

为了支持这一点，我们有一些自定义项目模板，它们自动包含对公共库的引用，再说一遍：我们真的很喜欢这种设置。

现在终于到了问题的实质——我们所做的大部分工作是支持大量的小型遗留经典 ASP 页面。随着新的发展，这些也正在慢慢转移到.Net。我们真的希望能够为这些 Web 应用程序使用与我们的其他应用程序相同的支持框架。传统观点认为 ASP.Net 应用程序不能引用 GAC 之外的程序集或它自己的小虚拟目录。因此，要在我们的 ASP.Net 页面中使用我们的通用代码，我们可以做的最好的事情是将其安装到 Web 服务器和每台开发人员机器上的 GAC，并确保此代码的每次更新也传播到这些位置。我们觉得这很令人反感。

鉴于我们可以为 ASPNet 帐户授予从公共代码所在的网络共享读取所需的权限，并且无论如何我们将为这些应用程序构建一些自定义项目模板（因此可以自动在 web.xml 中包含一些设置。例如，将普通的 asp.net 页面类配置或子类化作为我们的起点）有没有人知道任何非常规的智慧，说我们可能能够从它们当前的位置引用这些程序集？

4

2 回答 2

2

Joel，难道不能利用<codebase>应用程序配置文件的元素吗？AFAIK，它处理 UNC 共享，如果您已经将新的程序集版本放在命名文件夹中，那么在推出新版本时，似乎可以使用新<codebase>元素更新适当的配置文件，可能是通过使用颠覆钩子脚本。

如果您在不更改版本号的情况下进行了更新，则会遇到一个问题，因为机器已经下载了副本并且可能不知道更改。

于 2009-08-08T06:01:58.067 回答
0

据我所知，在 ASP.NET 中共享程序集的唯一方法（没有代码）是 GAC（或在每个站点本地维护一个副本并确保每个站点都是最新的），就像你说的那样。

这可能比它的价值更麻烦，但是有没有机会编写一个可以加载到您的 Web 服务器上的 GAC 中的单个程序集？

我的想法是，您可以在 GAC 中编写单个程序集，通过常规引用或反射，编组您对共享驱动器上其他共享程序集的对象的请求。

这样一来，您对共享文件夹中的程序集的维护麻烦就最小化了，并且真的只需要担心保持 GAC 中的单个程序集是最新的。

...为该程序集编写代码可能总是比它的价值更麻烦。

于 2009-08-07T14:16:47.563 回答