Eyv*_*ind 85 c# msbuild projects-and-solutions visual-studio-2008
我们有一个包含大约100多个项目的解决方案,其中大多数是C#.当然,开放和构建需要很长时间,所以我正在寻找这种野兽的最佳实践.我希望得到答案的问题包括:
每个项目应该构建到自己的文件夹,还是应该构建到相同的输出文件夹(它们都是同一个应用程序的一部分)
解决方案的文件夹是组织内容的好方法吗？
我知道将解决方案分解为多个较小的解决方案是一种选择,但是它带有自己的重构和构建头痛,所以也许我们可以将其保存为单独的线程:-)
Say*_*imi 41
您可能对我编写的这两篇MSBuild文章感兴趣.
特别是在第2部分中,您可能需要查看构建大型源树的部分.
尽管如此,请简要回答您的问题:
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]
我们在这里从事一个类似的大型项目。解决方案文件夹已被证明是组织事物的好方法，我们倾向于将复制本地设置保留为 true。每个项目都会构建到自己的文件夹中，然后我们知道对于其中的每个可部署项目，我们都有正确的二进制文件子集。
至于时间开放和时间建设，如果不分解更小的解决方案，这将很难解决。您可以研究并行化构建（谷歌“Parallel MS Build”以获取执行此操作并将其集成到 UI 中的方法）以提高此处的速度。另外，查看设计并看看重构一些项目以减少总体数量是否会有所帮助。