我们有一个包含大约100多个项目的解决方案,其中大多数是C#.当然,开放和构建需要很长时间,所以我正在寻找这种野兽的最佳实践.我希望得到答案的问题包括:
你如何最好地处理项目之间的引用
应该"打开或关闭本地"吗？
每个项目应该构建到自己的文件夹,还是应该构建到相同的输出文件夹(它们都是同一个应用程序的一部分)
解决方案的文件夹是组织内容的好方法吗？
我知道将解决方案分解为多个较小的解决方案是一种选择,但是它带有自己的重构和构建头痛,所以也许我们可以将其保存为单独的线程:-)
您可能对我编写的这两篇MSBuild文章感兴趣.
MSBuild:创建可靠构建的最佳实践,第1部分
MSBuild:创建可靠构建的最佳实践,第2部分
特别是在第2部分中,您可能需要查看构建大型源树的部分.
尽管如此,请简要回答您的问题:
CopyLocal？当然要关闭它
构建一个或多个输出文件夹？构建到一个输出文件夹
解答文件夹？这是一个品味问题.
Sayed Ibrahim Hashimi
我的书:Microsoft Build Engine内部:使用MSBuild和Team Foundation Build
+1用于节省使用解决方案文件夹来帮助整理内容.
项目构建+1到自己的文件夹.我们最初尝试了一个常见的输出文件夹,这可能导致查找过时引用的细微和痛苦.
FWIW,我们使用项目参考解决方案,虽然现在nuget可能是一个更好的选择,但已经发现svn:externals适用于第三方和(框架类型)内部组件.刚刚养成使用特定修订号而不是HEAD的习惯,当引用svn:externals时(有罪有罪:)
卸载不经常使用的项目,并购买SSD.SSD不会缩短编译时间,但Visual Studio的打开/关闭/构建速度提高了两倍.
我们有类似的问题,因为我们有109个单独的项目要处理.根据我们的经验回答原始问题:
1.如何最好地处理项目之间的引用
我们使用'添加引用'上下文菜单选项.如果选择"项目",则默认情况下会将依赖关系添加到我们的单个全局解决方案文件中.
2.应该"打开或关闭本地"吗？
关闭我们的经验.额外的复制只会增加构建时间.
3.每个项目是应该构建到自己的文件夹,还是应该构建到相同的输出文件夹(它们都是同一个应用程序的一部分)
我们的所有输出都放在一个名为'bin'的文件夹中.这个想法是该文件夹与部署软件时的相同.这有助于防止开发人员设置与部署设置不同时发生的问题.
4.解决方案文件夹是组织内容的好方法吗？
没有我们的经验.一个人的文件夹结构是另一个人的噩梦.深度嵌套的文件夹只会增加查找任何内容所需的时间.我们有一个完全扁平的结构,但命名我们的项目文件,程序集和命名空间相同.
我们构建项目的方式依赖于单个解决方案文件.即使项目本身没有改变,建立这个也需要很长时间.为了解决这个问题,我们通常会创建另一个"当前工作集"解决方案文件.我们正在处理的任何项目都会添加到此中.虽然我们看到的一个问题是Intellisense对于不在当前集合中的项目中定义的类型失败,但构建时间得到了极大的改进.
我们的解决方案布局的部分示例:
\bin OurStuff.SLN OurStuff.App.Administrator OurStuff.App.Common OurStuff.App.Installer.Database OurStuff.App.MediaPlayer OurStuff.App.Operator OurStuff.App.Service.Gateway OurStuff.App.Service.CollectionStation OurStuff.App.ServiceLocalLauncher OurStuff.App.StackTester OurStuff.Auditing OurStuff.Data OurStuff.Database OurStuff.Database.Constants OurStuff.Database.ObjectModel OurStuff.Device OurStuff.Device.Messaging OurStuff.Diagnostics ... [etc]
京公网安备 11010802040832号 | 京ICP备19059560号-6 