我使用Visual Studio 2005在C#.NET 2.0中编写了一个相对较大的winforms应用程序。它还使用了Crystal Reports。编译的EXE大约是12 MB。源代码约为60 MB。
应用程序的整体结构非常简单。 后面有一个SQL Server数据库。该应用程序的主要形式没有做任何事情,除了它主持一个包含许多项目的菜单。大多数菜单项都会打开一些非模态形式。大多数这些形式是独立的。某些表单包含"报告" - 具有一些参数的一些数据的只读视图,用户可以更改这些参数并刷新报告。某些表单提供可编辑的数据视图。本质上,它是一个DataGridView,带有参数来过滤/限制显示的内容以及用于添加/编辑/删除行的按钮。通常网格本身是只读的。添加/编辑命令通常会打开一个单独的模态窗体,其中包含要编辑的所选行的字段列表。
申请表中共有约250种表格。
所有源代码都在单一解决方案中,解决方案中有单个项目。 几个文件夹逻辑上将某些表单的源代码组合在一起。说,销售,财务,BizDev等。
我面临的问题是,如果我在任何文件中做出任何改变,C#编译器都会重新编译所有内容。例如,如果我在一个文件中更改一行并执行"构建解决方案"编译需要35秒。如果我做"清洁解决方案"然后"重建解决方案"它仍然需要35秒才能编译。该计算机具有16Gb内存,SSD磁盘和Intel Core i7,因此改善硬件的空间不大。我试图创建一个RAM驱动器并将源代码放在那里。它根本没有影响编译时间。最有可能的是,这些60MB的源代码都在Windows缓存中,无论如何都有16 GB的内存。在C ++世界中,C ++编译器只重新编译已更改的文件,但C#会重新编译所有内容。此外,它仅使用8个CPU中的一个核心。此外,Visual Studio本身无法在C#编译期间使用。在我按F7之后的情况下,VS代码编辑器变得非常反应迟钝。当我尝试在编译器运行时将光标移动到代码周围时,可能需要几秒钟才能从一行移动到另一行。我甚至都没有输入任何内容,只需移动光标即可查看代码。
我的问题是:如果我通过简单地将逻辑相关的表单移动到单独的项目中以某种方式将这个整体项目分解为几个较小的项目,是否会减少编译时间? 由于这250个表单中的大多数都是独立的,因此当其中只有一个表单发生更改时,应该可以不编译所有表单。
如果我的主要目标是减少日常编译时间,那么在Visual Studio中构建整个事物的最佳方法是什么?
更新: 为了澄清,我使用术语"解决方案"对于SLN文件和"项目"对于CSPROJ文件。
我应该在开始时提到它。当我在网上搜索"如何加速C#编译"我遇到了许多帖子,其中人们有许多项目的解决方案(70-100)。在这种情况下,建议减少项目数量。此外,还有一些关于特定项目设置以及它们如何影响编译器性能的建议。与其他人一起看到这些问题让我觉得有很多项目会给编译和一般的VS IDE性能带来很大的开销。
我有相反的情况。我在一个解决方案中只有一个项目。拥有C ++背景对我来说很奇怪,C#编译器每次都必须重新编译所有内容。我希望存在一些平衡的方法,允许C#编译器只编译那些已经改变的文件,从而减少日常开发中的编译时间,当我专注于整个项目的一小部分时。
目前项目编制时没有任何警告。
如果你说(根据你的经验)VS2013中的C#编译器支持开箱即用的增量编译,我会考虑从VS2005切换。如果你说(再次,根据你的经验)确实在一个解决方案中确实有10个独立项目加上主要表单的1个主项目而不是一个解决方案中的1个大项目通常会导致只重新编译两个小项目,我会给它一个尝试。如果我按照这个将代码拆分成较小项目的路径,我想知道什么是"陷阱" /要查找的一些模糊设置,以便VS和编译器性能不会变差。 另外,如果您能突出在VS中配置整个解决方案的最佳方法,我将不胜感激。例如,如果所有这些小项目都编译成一个大的EXE,或者每个小项目应该编译成一个单独的DLL而不是一个大的EXE,我最终会得到十几个DLL和一个小的EXE?我甚至都不知道这两种选择是否都可行。也许还有其他选择。
我很感激你的想法。
谢谢。
答案 0 :(得分:2)
首先,35secs对于“大型”项目的编译来说并不长。这些项目中的项目和文件不应该是关于最小化编译时间,它应该是关于打包和管理依赖项。
编译时间取决于很多事情。
具有多个项目的解决方案可以在没有任何更改时跳过项目的编译,但是如果您在构建顺序的早期更改项目中的代码,它可以触发重新编译所有内容。在某些情况下,编译时间的意义可能更快,而在其他情况下,它们可能会更慢。
如果您有很多很少更改的代码,那么肯定有效的方法是将该代码移动到单独的解决方案中,并且作为编译过程的一部分,将解决方案的输出DLL复制到暂存区域。然后,您可以从文件系统上的暂存区域创建对这些DLL的文件引用。执行此操作时,我从映射的网络驱动器或使用Subst命令创建的驱动器中引用文件。这样做的原因是为了让您灵活地通过将驱动器重新映射到另一个位置来轻松地更改解决方案从中获取DLL的位置。
此外,我会考虑将业务逻辑与表单分离,并将该业务逻辑放入单独的项目中。设计良好的应用程序通常采用N层设计,逻辑上可以为应用程序的每个层级提供至少一个(通常是几个)单独的项目。
答案 1 :(得分:-1)
是的,将项目逻辑分组始终是安全的。无论如何,还有其他因素会影响编译时间。
有些要点可以缩短编译时间。当你尚未准备好部署时
1。如果您有安装项目,请不要启用安装项目,除非您已准备好部署/发布。
2。在输出窗口中查找警告,警告次数越少越好。
3. 在处理一段代码时,排除不影响当前代码的不相关表单/项目/文件