在Team System上自动构建所需的二进制文件的存储位置? 您是将它们与代码一起存储在SCM中还是其他地方? SCM中有大量的二进制文件导致源控制器出现性能问题吗?
需要能够恢复到某些外部库的早期版本才能修复已发布版本中的错误,但版本不兼容。分支可以解决问题,但我认为将二进制文件与代码一起存储是反模式的。
欢迎提出任何建议。
答案 0 :(得分:3)
Nexus和Artifactory目前都支持.net开发中使用的二进制工件和依赖项的存储。对于使用NuGet包进行TFS构建和与Visual Studio的集成,您可以查看this blog.
答案 1 :(得分:1)
我在过去常常使用svn:externals,如cringe所述。但是在本地工作副本中更新速度很慢。我和几个朋友开始了一个开源项目试图解决这个问题,这个问题还处于初期阶段,但如果这是一个你感兴趣的问题,你可能需要关注它(甚至帮助它)。它叫做Refix,是hosted on CodePlex。
答案 2 :(得分:0)
我们总是存储外部二进制依赖项以及源代码,图像,构建脚本以及在版本控制系统(VCS)中一起构建解决方案所需的所有其他工件。这就是我真正擅长的VCS,它确保我们拥有适用于我们构建的任何版本的所有必需工件的正确版本,甚至是分支。
我很好奇:你为什么认为这是反模式?
答案 3 :(得分:0)
Subversion例如有svn:externals可用于导入你的库的另一个目录的内容。外部可以固定到特定版本。对我而言,这是一种更好的方法,您可以避免嵌套工作副本。
答案 4 :(得分:0)
(我知道这是一个老问题,但我的典型基于Java的团队正在做一些.NET工作并且现在就提出相同的问题,而这就是我们发现的。 )
如果你正在使用像Git这样的DVCS系统,那么如果你将这些库检查到源代码管理中,你可能会遇到性能问题。作为参考,我们将几个大型项目(2-5GB)与Perforce中的签入二进制文件转换为Git。导入Git repos的性能(在使用SSD的强大Windows盒子上使用Git 1.9)的开发速度非常慢。我们调整了我们的构建,以从私有Nexus实例中获取大部分依赖项,并且显着更薄的回购(50-200MB的源代码)似乎表现良好。
如果您已经拥有Nexus实例,那么就没有什么可以阻止您使用它来存储.NET工件 - 就Nexus而言,工件只是一个文件。如果您将DLL和配置文件以及诸如此类的文件压缩到单个文件中,Nexus很乐意将其作为版本化工件托管,您可以在需要时将其下载/解压缩到正确的位置。 (我还没有使用Artifactory,所以我不能评论它的作用。)
如果你想要与VisualStudio(或MonoDevelop)特别集成的东西,那么NuGet似乎是现在正在出现的答案。
默认情况下,中央NuGet Feed没有阅读权限。对于托管,看起来您可以提交要在其中托管的OSS /公共二进制文件,如果您想托管专有/私有二进制文件,则有instructions for setting up your own private NuGet feed。
如果你有Pro版本的Nexus,it claims to host .NET artifacts and allow access through NuGet,但我没有使用它的经验。