你应该把第三方程序集存储在哪里?

6
好的,我们有一个相当大的解决方案,其中包含大约8个不同的项目。这些项目都依赖于各种不同的第三方程序集。此解决方案位于源代码控制的主干分支中。我们还有大约5个与主干分支相关的不同分支。
如何管理这些第三方程序集才是最好的方法?当您添加对程序集的引用并单击它以查看属性窗口时,我注意到它对该程序集有硬编码的路径。
例如:我们所有的分支都映射到 "C:\Code\"。所以主干就是 "C:\Code\Trunk",而分支就是 "C:\Code\somebranch"。
如果我在 "C:\Code\Trunk" 中创建一个名为 "Assemblies" 的文件夹,然后将所有第三方程序集放入该文件夹中,然后再添加对其中某个程序集的引用,那么该程序集的引用是否是相对的?如果我单击已添加的程序集,我会看到灰色的路径属性显示为 "C:\Code\Trunk\Assemblies\someassembly.dll"。
如果我从主干分支分支出去,会发生什么情况?"somebranch" 是否仍将引用 "C:\Code\Trunk\Assemblies\someassembly.dll",还是它会引用 "C:\Code\somebranch\Assemblies\someassembly.dll"?
目前,我们实际上在源代码控制中有一个名为 "Assemblies" 的分支,它与任何其他分支一样被映射到 "C:\Code\"。因此,所有带有引用程序集的项目所在的分支都引用 "C:\Code\Assemblies\someassembly.dll",无论该项目在哪个分支中,路径都是相同的。
不幸的是,这意味着您必须获取您正在工作的分支的最新版本和程序集分支的最新版本,才能成功构建解决方案。
总而言之: - 如何添加相对于解决方案的引用?(例如,添加对 C:\Code\Trunk\Assemblies\someassembly.dll 的引用,并使其路径相对于添加它的项目,以便在创建分支时引用分支的程序集文件夹而不是主干的程序集文件夹。或者该引用已经是相对的了吗? - 其他推荐管理第三方程序集的策略有哪些?
4个回答

5
现在我们有NuGet,您可以使用它来获取所有支持的OSS包,甚至可以为其他第三方程序集创建自己的NuGet包。值得一提的是,OpenWrap也是NuGet的替代品。

NuGet将包存储在解决方案级别上,因此每个分支(和主干)都会保留这些版本。

我建议这是更可取的行为。例如,如果要升级第三方软件,则需要保持程序集版本的分离。

过去,我使用svn的外部命令从内部开发的依赖项构建特定版本。您可以将其放在存储库中,并使用外部命令(或您SCM的等效命令)获取正确的版本。

我也使用构建事件将dlls放置在正确的位置。


2

使用一个位于主干路径下的程序集文件夹。我更喜欢把它叫做“lib”,而不是“assemblies”。

是的,路径已经是相对路径了。当你分支时,你的项目将会得到正确的程序集文件夹。

根据你使用的第三方程序集的数量,你可能还想组织你的程序集文件夹,这样它就不会成为一堆混乱的dll文件。


好的,我们实际上将程序集文件夹分成了整洁的子目录。只要这些路径是相对的,我想这不是问题。感谢您的帮助。 - Chev

1
我们的解决方案中有一个SolutionItems文件夹,用于存放第三方引用。每个分支的解决方案都有自己的副本。
当我们添加引用时,我们使用“浏览”选项卡在添加引用对话框中选择与当前项目相关的程序集。
项目文件包含以下内容:
<Reference Include="SomeAssembly, Version=0.1.0.0, Culture=neutral, PublicKeyToken=8xxxxxxxxxxx, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\Solution Items\SomeAssembly.dll</HintPath>
</Reference>

0
我通常创建一个所有其他项目都引用的公共项目。在这个公共项目中,我创建了一个名为deps(表示依赖项)的文件夹。然后,每个其他项目都引用了公共项目deps文件夹中DLL的副本。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接