我有一个使用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的一个内核。而且，在C＃编译期间不能使用Visual Studio本身。就我而言，按F7后，VS代码编辑器将变得非常无响应。当我尝试在编译器运行时在代码周围移动光标时，从一行移到另一行可能需要几秒钟。我什至没有输入任何内容，只是移动光标以查看代码。
我的问题是：如果我通过简单地将逻辑上相关的形式移动到单独的项目中，从而以某种方式将这个整体项目分解为几个较小的项目，会减少编译时间吗？
由于这250种形式中的大多数是独立的，因此当仅其中一种改变时，应该不编译所有形式都是可能的。
如果我的主要目标是减少日常编译时间，那么在Visual Studio中构建整个结构的最佳方法是什么？
更新：
为了清楚起见，我将术语“解决方案”用于SLN文件，将“项目”用于CSPROJ文件。
我应该在一开始就提到它。当我在网上搜索“如何加快C＃编译速度”时，我遇到了很多帖子，他们在其中解决了很多项目（70-100）。在这种情况下，经常建议减少项目数量。此外，对于特定的项目设置以及它们如何影响编译器性能，也有一些建议。看到其他人遇到的此类问题，使我认为拥有许多项目会给编译和常规VS IDE性能带来可观的开销。
在这里我有相反的情况。一个解决方案中只有一个项目。具有C ++背景对于我来说，C＃编译器每次都必须重新编译所有内容对我来说很奇怪。我希望有一种平衡的方法可以使C＃编译器仅编译那些已更改的文件，从而在我专注于整个项目的一小部分时，可以减少日常开发中的编译时间。
目前，该项目的编译没有任何警告。
如果您（根据您的经验）说VS2013中的C＃编译器支持开箱即用的增量编译，那么我将考虑从VS2005切换。如果您（再次根据您的经验）说，实际上在一个解决方案中有10个独立项目加一个主窗体的主要项目，而不是在一个解决方案中有1个大项目通常会导致仅重新编译两个小项目，我会给它一个尝试。如果我遵循将代码拆分为较小项目的方法，我想知道要寻找的“陷阱” /一些晦涩的设置，这样VS和编译器的性能就不会变差。
另外，如果您能重点介绍在VS中配置整个解决方案的最佳方法，我将不胜感激。例如，所有这些小项目都应该编译成一个大EXE，还是每个小项目都应该编译成一个单独的DLL，而不是一个大EXE，我最终会得到十二个DLL和一个小EXE？我什至都不知道这两个选项是否都可行。也许还有其他选择。
我会很感激你的想法。
谢谢。
最佳答案
首先，对于一个“大型”项目的编译时间不超过35秒。这些项目中的项目和文件不应该与最小化编译时间有关，而应与打包和管理依赖项有关。
编译时间取决于很多事情。
具有多个项目的解决方案可以在没有任何更改的情况下跳过项目的编译，但是，如果您在构建顺序的早期更改了项目中的代码，则会触发所有内容的重新编译。这意味着在某些情况下编译时间可能会更快，而在其他情况下则可能会更慢。
如果您有很多很少更改的代码，那么一种肯定有效的肯定方法是将代码移到单独的解决方案中，并在编译过程中将解决方案的输出DLL复制到暂存区。然后，您可以从文件系统上的登台区域创建对这些DLL的文件引用。这样做时，我从映射的网络驱动器或使用Subst命令创建的驱动器中引用文件。这样做的原因是，通过将驱动器重新映射到另一个位置，可以灵活地更改解决方案从何处拾取DLL的位置。
此外，我将研究从表单中分离出业务逻辑，并将该业务逻辑放入单独的项目中。设计良好的应用程序通常会结合一个N层设计，从逻辑上讲，它适合于应用程序每一层至少有一个（通常是几个）单独的项目。
关于c# - 如何通过将一个C#项目分解为多个项目来加快编译速度，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/27007788/