代码之家  ›  专栏  ›  技术社区  ›  User

如何构建SVN:Externals,用于构建引用第三方DLL的类库

  •  2
  • User  · 技术社区  · 16 年前

    我正在使用Subversion和Nant(以及Visual Studio IDE)

    我一直在遵循建议的项目结构 http://blog.jpboodhoo.com/NAntStarterSeries.aspx 它提倡自包含的Subversion目录,在该目录中开发人员可以执行签出并立即在一个步骤中构建项目。

    我的回购结构如下:

    /Repo
      /MainProject
        /trunk
          /doc   <-- documentation
          /lib   <-- binary-only DLLs
          /src   <-- source code for MainProject
          /tools <-- holds tools like nant, nunit, etc
    ...
      /ClassLibrary1
        /trunk
          /doc
          /lib
          /src
          /tools
    ...
      /ClassLibrary2
        /trunk
          /doc
          /lib
          /src
          /tools
    

    尚不清楚的是,如何构建一个具有类库的项目,而类库又引用第三方库DLL本身。

    目前,我有一个主项目,有一个工作目录

    例子:

    /MainProject
      /build
      /lib
      /src
        /MainProject
        /ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
        /ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
      /tools
      ...
    

    在构建主项目时,我编译类库并将dll输出到build文件夹。然而,类库本身只有它们引用的第三方二进制dll。

    我的问题是,为了构建主项目,我必须以某种方式将类库中的第三方DLL获取到构建输出中。我该怎么做?

    思想: 1。我应该将这些第三方DLL的副本存储在主项目的lib文件夹中吗? 2。或者我的svn:external引用应该是类库项目的主干,而不是SRC,这样我就可以访问类库的lib文件夹了? 三。我应该使用svn:externals到单个文件的subversion 1.6特性吗?

    3 回复  |  直到 16 年前
        1
  •  1
  •   Jim T    16 年前

    我亲自把参考图书馆的后备箱带来。 (实际上,我引入了一个标签的根,但这不是重点)。

    如果保留所需dll的单独副本,则不会真正允许引用的库确定自身需要什么,因为所有这些逻辑都在项目中重复。如果使用多个外部引用或文件外部引用引入代码和DLL,也会发生同样的事情。

    我这里的原则是——图书馆知道它需要什么,一个对图书馆的外部参考就可以得到图书馆和它需要的一切。

    这样,如果您更改了库的引用,您就可以确信任何和所有项目都会得到它。(如果IDE不支持这一点,那就是IDE的问题,而不是Subverion的问题)。作为一个项目,您也可以自信地认为,如果您更改所指向的库的版本,您也将自动获得正确的引用,并且不需要调试构建失败来解决问题。

        2
  •  1
  •   Andrew Siemer    16 年前
    1. 我应该将这些第三方DLL的副本存储在主项目的lib文件夹中吗? 我更喜欢将任何外部库存储在主干下的二进制目录中,但要存储在源代码旁边……或者调用它的引用、依赖项等。这样,任何开发人员都可以获得最新的,并且所需的一切都将得到解决。它本身不需要成为项目的一部分。它只需要在执行构建时可访问。

    2. 或者我的svn:external引用应该是类库项目的主干,而不是SRC,这样我就可以访问类库的lib文件夹了? 我不喜欢这种方法,因为它使新开发人员的启动和运行过程更加复杂。我认为当程序集自身具有一定的重要性时,它可以进入自己的存储库。但我绝不会引用它的输出。它应该有一个围绕它的构建过程,它促进一种机制将输出“部署”到上面的引用或依赖目录。然而,像这样自动化部署可能会充满问题。如果装配有自己的过程,那就更好了。当新版本的程序集发布时,需要它的项目开发人员将手动接受它。然后他们可以测试它,接受它,并将其放入构建过程中。显然,如果这种装配每天都在变化,那么可能需要一些自动化。

    3. 我应该使用svn:externals到单个文件的subversion 1.6特性吗? 不,我更喜欢将项目/解决方案作为一个独立的实体来保存。把帐篷铺开会让依赖更加痛苦。保持筒仓尽可能坚硬……尽可能手动地引入新事物……或尽可能手动地改变事物所允许的频率。

        3
  •  0
  •   Julien Bérubé    14 年前

    我也有类似的需求,在Tortoissesvn的文档中找到了一个简短而贴切的答案:

    http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html