【问题标题】:Should I set copy local false for commonly referenced assemblies in asp.net mvc applications?我应该为 asp.net mvc 应用程序中常用引用的程序集设置复制本地 false 吗?
【发布时间】:2013-03-12 19:49:32
【问题描述】:

我的组织为业务逻辑内容定义了一些程序集。我们正在尝试为这些公共库设置持续集成,并维护引用它们的项目模板。这将使我们能够相对快速地完成小型维护应用程序。

我们的目标是按版本将这些 dll 放在一个文件夹中,并在运行时在 Global.asax 中解析它们。如果没有在本地复制它们,我会发现各种东西都会中断,例如强类型剃刀视图。

将它们放在一个共享目录中是否有任何真正的好处,或者是构建主要应用程序同时引用共享项目源并复制本地的最佳实践?

我的同事认为,如果业务逻辑发生变化,共享位置将使以后修复错误变得容易。我觉得我们永远不需要全局更改某些对象或服务,如果我们这样做了,我们无论如何都必须触摸每个应用程序来处理更改。

【问题讨论】:

  • 请记住,将它们拉出 bin 目录(复制本地)将要求它们位于 Global Assembly Cache 中。除非您要在构建时将正确的版本放入 bin 目录中。
  • @Frazell 这就是问题所在。没有人打算GAC,也没有人想复制本地。他们希望它可以在磁盘上的共享目录中工作。

标签: c# asp.net .net asp.net-mvc .net-4.0


【解决方案1】:

NuGet package 中的共享DLL 发布到Local NuGet server!这样,每个依赖应用程序都可以显式依赖于您的包的特定版本。

【讨论】:

  • +1 这个。效果很好,自动添加引用等,甚至还可以添加配置和代码更改。
  • 要清楚一点,这个方法仍然意味着共享的DLL将是Copy Local = True?
  • NuGet 会为您处理这个问题,但是它确实指定 Copy Local = True 因为这些外部 DLL 将被您的运行代码引用(NuGet 还会修改您的 .csproj 文件以具有适当的引用)。如果它没有将它们复制到您的输出目录,您将不得不依赖像 GAC 这样更具侵入性的东西
  • 看起来很简单,我会试一试。谢谢!
【解决方案2】:

将您的 DLL 放在一个共享的公用文件夹中。这是为了防止您在应用程序中可能遇到的任何未来问题无法解决或“混淆”它应该使用的 DLL。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-08
    • 2013-03-02
    • 2020-08-22
    • 1970-01-01
    • 2010-09-08
    相关资源
    最近更新 更多