我想减少我的VS.NET项目的编译时间 – 你对如何做到这一点的想法是什么?

我的项目是在Visual Studio 08中用C#开发的。 它是一个独立的桌面应用程序,大约有6万行代码。 曾几何时我喜欢在这个软件上工作 – 现在,赞美时间已经增长到大约2分钟,它变得不那么令人愉快了…

我认为我缺乏C#经验可能是一个因素; 例如,我已经在一个名称空间下开发了所有内容 – 具有结构良好的代码库使编译器能够在进行更改时仅重新编译代码的必要部分吗? 或者我是否需要将部分分成单独的项目/ DLL以强制实现这一点?

升级到最新的四核处理器有多大区别?

另一个想法是,对于程序员来说,这可能是一个典型的事情 – 像这样的漫长的编译时间只是必须要管理的东西?

提前致谢。

令我惊讶的是,60k行代码需要2分钟才能编译。 我有一个500,000行代码的应用程序,它只需要大约一分半钟。 确保每次都没有进行完全重建,并确保不在构建之间清除解决方案。 正常构建应执行增量构建,仅重新编译自上次构建以来已更改的代码(以及受该更改影响的任何内容)。

也许其他一些因素可能包括大量资源(图像?)的大量使用,最低级别库(即其他所有用途)的广泛变化等。一般来说,在相对现代的机器上,编译60,000行C#代码平均需要不到一分钟,除非您正在重建整个解决方案。

增加编译时间的事情:

  • 解决方案中的项目数量与特定项目中的文件数量差异更大。
  • 自定义构建任务可以产生巨大的差异,特别是如果它们生成代码或运行构建后分析(FxCop,StyleCop,代码契约)。
  • 本机代码项目需要更长时间才能构建

一个包含60K行C#代码而没有启用特殊构建function的单个项目应在几秒钟内在过去5年以上的任何机器上编译。

有关于硬件的这个线程可以改善编译时间。 这也是斯科特格思里关于硬盘速度表现的优秀博客文章 。

将项目拆分为多个项目将有所帮助。 只有那些有变更的项目(以及依赖它的项目)才需要重新编译。

但是,单个命名空间不应影响编译时间。 但是,如果您将项目拆分为多个项目/程序集,那么单个命名空间肯定不是一个好主意。

升级到更快的CPU可能会有所帮助,但您可能会发现更快的I / O(更好的磁盘,RAID等更有用)。

是的,避免长编译时间是开发人员需要处理的事情之一。 在生产力方面,尽你所能(更好的工具,更大的屏幕,更快的机器等……)