【问题标题】:Where to store external DLL files?在哪里存储外部 DLL 文件?
【发布时间】:2011-05-15 17:15:34
【问题描述】:

在我的项目中,我使用了一些第三方库。我使用 Visual Studio 中的引用文件夹包含它们。

但是我应该将 DLL 文件保存在哪里?它们是从文件系统中的路径引用的,但如果我可以将它包含到项目中会很好。但是怎么做呢?

【问题讨论】:

    标签: c# .net wpf visual-studio dll


    【解决方案1】:

    这就是我的工作:

    • 在解决方案级别创建 lib 文件夹
    • 将我所有的第三方 DLL 文件下载并复制到那里
    • lib 文件夹中的引用
    • 将所有这些 DLL 文件放在源代码管理中。我正在使用Subversion,我手动添加它们,但这是一次性的。

    您还可以添加解决方案文件夹并将它们添加到那里。


    2012 年 12 月 19 日更新

    上面的答案是NuGet 还处于婴儿期。 FWIW,我有 NuGet 项的方法:

    1. 对纯 DLL 文件依赖项执行上述操作(它们没有 NuGet pkg)
    2. 为解决方案启用“包还原”
    3. 根据需要更改 packages.config 文件以将版本锁定到特定包
    4. 不要将包本身存储在版本控制系统中(为GitMercurial等设置忽略)

    我实际上使用 NuGet 来管理内部依赖项,并且有一个私人提要。

    【讨论】:

    • +1 用于提醒将它们添加到源代码管理...这应该很明显,但它经常被忽视。
    • 与我工作时使用的程序相同。添加到源代码管理以确保它也适用于所有其他开发人员,这一点很重要。
    • 干杯,我已经考虑这个问题几天了,但这似乎是个中肯的建议。
    • @Tyler 没有。您将在 NuGet 控制台中调用 PM> Update-Package。
    • 您能否澄清一下,当您说“解决方案级别”时,您是指存储.sln 文件的级别?
    【解决方案2】:

    通常,我的项目结构如下所示(至少):

    projectname
       - trunk
           - src
           - lib
       - support
           - docs
       - releases
    

    trunk 文件夹包含我现在正在处理的源代码的副本。此外,还有一个目录“lib”,其中包含我的项目引用的所有第三方程序集。
    (我引用了那个位置的程序集)。

    “发布”文件夹包含主干的分支。例如,当 v1 发布时,会从主干中提取一个分支,以便我拥有构建应用程序版本 1 所需的源代码及其所有依赖项的副本。 (这对于错误修复很方便。修复该分支中的错误,将修复合并到主干,重建该分支,您的应用程序就有一个固定的 v1)。

    所有这些都进入源代码管理。 (是的,引用的程序集也是如此)。这样一来,如果另一个同事也必须从事该项目,就很容易了。他只是从源代码控制中获得了最新版本,并且他(或她)已经准备好一切以便能够编译和构建)。

    (请注意,如果您将CruiseControl 用于continuous integration,这也是如此)。

    【讨论】:

    • 为什么是“JAVA-esque”?我的意思是,我认为这在所有环境中都是一种很好的做法。 :)
    【解决方案3】:

    在 Visual Studio 的属性窗口中用于引用 dll,有一个名为“复制本地”的属性 - 将其设置为 true,它们将被复制到本地项目的 bin 目录中

    【讨论】:

      【解决方案4】:

      看看NuGet(Visual Studio 的包管理器)...

      NuGet 是一个 Visual Studio 扩展,可以轻松安装和 更新 Visual Studio 中的开源库和工具。

      然后阅读此 NuGet 文档以获取 crème de la crème

      Using NuGet without committing packages to source control

      【讨论】:

      • 我刚开始使用 NuGet,我喜欢它。
      • 这是任何近期发展(2011 年以后)的最佳答案
      【解决方案5】:

      您应该查看NuGet。它是 Visual Studio 2010 的包管理扩展,专为您的需要而设计。

      【讨论】:

        【解决方案6】:

        看看Tree Surgeon - 为 .NET 项目创建一个开发树,这是一个很好的起点,您可以从那里即兴创作。

        【讨论】:

          【解决方案7】:

          就我个人而言,我的源代码控制中有一个用于 3rd 方 DLL 的文件夹(每个公司、组织都有一个文件夹)并从那里引用它们。

          这些文件随后可供所有下载源代码的开发人员使用,并且可以轻松更新。

          【讨论】:

            【解决方案8】:

            要正确回答这个问题,您需要区分环境工作集

            环境:

            • 这是构建您的解决方案所需的所有工具和库。
            • 环境中的事物预计会保持相当稳定。
            • 环境中的事物通常是版本化的,您应该能够同时拥有多个版本。
            • 环境中的东西通常是经过许可的。
            • 环境不受源代码控制。
            • Visual Studio 就是一个很好的例子。

            工作集:

            • 这基本上是你的源代码。
            • 这是获得最终可执行文件所需的所有要求。
            • 您应该期望工作集在开发过程中会发生很大变化。
            • 工作集应受源代码控制。

            您需要决定您的组件适合的类别。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2013-02-01
              • 2013-06-04
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2011-01-12
              • 1970-01-01
              相关资源
              最近更新 更多