Question

在我目前的项目中，我们使用F＃-project有一个非常大的解决方案。我说的真的很大。它的70个F＃项目（480 .fs文件）和4个C＃项目。

正如您可能猜测的那样开始是一个问题。首先，在Visual Studio中管理需要永远。但是，它也需要很长时间才能构建 - 上次我检查它在我的机器上花了大约3分钟。

我知道有（不支持的）方法可以在Folders in your projects中组织F＃文件，但考虑到解决方案的大小，我会仔细检查并手动完成。我们也非常确定它会改善构建时间。

那么，现在我的问题 - 将合并到更少的项目中减少构建时间？假设我们将其归结为5-10个项目，而不是今天的70个项目。

如果没有 - 我们可以做些什么呢？你如何管理这种规模的项目？

Answer 1

我不能代表大型F＃解决方案，但我已经用大型C＃解决方案做到了这一点，并且看到构建时间大幅下降。例如一个解决方案有~100个项目，我们减少到~20，构建时间从＆gt; 10分钟到＆lt; 5分钟。

增益主要来自减少依赖项检查以及将文件从一个项目的构建输出文件夹复制到另一个项目的次数。

Answer 2

试过SSD＆amp; RAM驱动器没有太大作用。

项目之间的依赖关系可能会阻止您通过增加并发构建的数量来获得任何东西。

我有点惊讶你在70个项目中有480个.fs文件......这相当于每个项目大约6-7个文件，这并不多。无论如何，即使不是出于性能原因，也可能值得一看 - 人们可以（无论如何）设计问题。但是构建时间似乎与每个项目的文件（或LOC）数量一致，所以你可能不会像你想要的那样挤压。

由于这个原因，我个人失去了每次清洁和重建的习惯。

编辑：在专家F＃中找到了一个我认为值得一提的相关说明：

.NET assemblies often contain a large amount of code. For example, a single assembly may contain as 
many as 50 or 100 F# source code files. Having many small assemblies may seem tempting, such as to improve 
compilation times during development, but can lead to difficulties when you’re managing updates and can be 
confusing to end users. Large assemblies are easier to version: you have to update only one component, and you 
can package multiple updates into a single new version of the DLL

Answer 3

如果F＃编译速度很慢，可能是由于NGEN在最近的.net框架更新后没有运行。请参阅以下两个stackoverflow问题：f# compiling too slow和F# is running very slow since last round of Windows updates以获取更多信息

F＃大型解决方案 - 构建时间长

3 个答案: