我所在的位置我们有大量可以运行的程序，它们都使用位于网络共享上的一组程序集中的功能：例如写入公共系统日志，数据库连接字符串，一些常见业务对象和功能等。
我们喜欢这种设置，因为它可以轻松部署错误修复和新功能：只需更新共享驱动器上的程序集，并且每个使用它们的应用程序都是最新的。需要打破二进制兼容性？它不是轻易做到但仍然没什么大不了的：只需添加一个带有新版本号的新文件夹。 Subversion知道每个版本的位置，因此仍然可以将bug修复部署到每个版本中的重复代码。可能还会首先进行一些讨论，以确保它确实是必要的，因此我们可以将几个更改批量分配到一个新的集合中，但是到目前为止这一点的需要非常少见。
为了支持这一点，我们有一些自动包含公共库引用的自定义项目模板，并再次：我们非常喜欢这种设置。
现在终于问题了 - 我们所做的很多工作都是支持大量的小型传统经典ASP页面。这些以及新的发展也在慢慢转向.Net。我们真的希望能够为我们其他应用程序使用的这些Web应用程序使用相同的支持框架。传统观点认为ASP.Net应用程序不能引用GAC之外的程序集或它自己的小虚拟目录。因此，要在我们的ASP.Net页面中使用我们的公共代码，我们所能做的最好是将其安装到Web服务器和每个开发人员计算机上的GAC，并确保对此代码的每次更新也传播到这些位置。我们觉得这很令人反感。
鉴于我们可以为ASPNet帐户提供从公共代码所在的网络共享中读取所需的权限，并且我们将为这些应用程序构建一些自定义项目模板（因此可能会自动包含一些设置） web.config或子类普通的asp.net页面类作为我们的出发点，例如）有没有人知道任何非传统的智慧，说我们可能能够从他们当前的位置引用这些程序集？
答案 0 :(得分：2)
Joel，您的应用程序配置文件的leverage the <codebase> element是否不可能？ AFAIK，它处理UNC共享，如果你已经在命名文件夹中放置了新的程序集版本，似乎可以在新版本推出时使用新的<codebase>元素更新相应的配置文件，可能通过使用subversion钩子脚本。
如果您在不更改版本号的情况下进行更新，可能会出现问题，因为机器已经下载了副本，并且可能不知道更改。
答案 1 :(得分：0)
据我所知，在ASP.NET中共享程序集的唯一方法（没有代码）是GAC（或维护每个站点的本地副本，并确保每个站点都是最新的），就像你说的那样。 p>
它可能比它的价值更高，但有没有机会编写一个可以在Web服务器上加载到GAC的程序集？
我的想法是，你可以在GAC中编写一个程序集，通过传统的引用或反射，可以对来自共享驱动器上其他共享程序集的对象的请求进行编组。
这样，您可以最大限度地减少共享文件夹中程序集的维护难题，而且实际上只需要担心GAC中的单个程序集是最新的。
...编写该程序集的代码总是会比它的价值更麻烦。