在我目前的项目中，我们有一个非常大的解决方案f# -project。我说的是非常大的。它有70个f#项目(480个.fs文件)和4个c#项目。
你可能猜到这是开始是一个问题。首先，在Visual Studio中管理要花很长时间。但是，它也需要太长时间来构建 -上次我检查它在我的机器上花了大约3分钟。
我知道在你的项目中有(不支持的?)方法来组织文件夹中的f#文件，但是考虑到解决方案的大小，我害怕亲自去做。此外，我们希望非常确定它将改善构建时间。
那么，现在我的问题-合并到更少的项目会减少构建时间吗?假设我们把项目减少到5-10个，而不是今天的70个。
如果不是，我们能做什么呢?你是如何管理这种规模的项目的?
我不能说大型f#解决方案，但我已经在大型c#解决方案中这样做了，并且看到构建时间大幅下降。例如，一个解决方案有大约100个项目，我们将其减少到大约20个，并且构建时间从> 10分钟减少到<5分钟。
收益主要来自于减少依赖检查和文件从一个项目的构建输出文件夹复制到另一个项目的次数。
如果f#编译非常慢，可能是由于NGEN没有在最近的。net框架更新后运行。查看这两个stackoverflow问题:f#编译太慢和自上一轮Windows更新以来f#运行非常慢的更多信息
尝试SSD &RAM驱动器不做太多。
项目之间的依赖关系可能会阻止您从增加并发构建的数量中获得任何东西。
我有点惊讶你在70个项目中有480个。fs文件…这相当于每个项目大约6-7个文件，这并不多。无论如何，这可能值得研究一下，即使不是出于性能原因——无论如何都可能有(将会?)设计问题。但是构建时间似乎与每个项目的文件(或loc)数量一致，因此您可能不会像您希望的那样挤出那么多。
因为这个原因，我个人失去了每次清理和重建的习惯。
编辑:在Expert 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