C# Visual Studio中大型解决方案的最佳实践（2008）

我们有大约100多个项目的解决方案，其中大部分是C#。当然，打开和构建都需要很长的时间，所以我正在寻找这些野兽的最佳实践。我希望得到答案的问题包括：

• 如何最好地处理项目之间的引用
  • “本地复制”应该打开还是关闭
• 每个项目是生成到自己的文件夹，还是都生成到同一个输出文件夹（它们都是同一应用程序的一部分）

• 解决方案文件夹是组织内容的好方法吗

---

我知道将解决方案拆分为多个较小的解决方案是一种选择，但这会带来重构和构建方面的麻烦，因此我们可以将其保存为单独的线程：-）我们在这里处理一个类似的大型项目。事实证明，解决方案文件夹是一种很好的组织方式，我们倾向于将copy local设置为true。每个项目都构建到自己的文件夹中，然后我们知道对于每个可部署的项目，我们都有正确的二进制文件子集

---

至于时间开放和时间构建，如果不打破较小的解决方案，这将很难解决。您可以研究并行化构建（google“Parallel MS build”是一种这样做并集成到UI中的方法）以提高速度。另外，看看设计，看看重构一些项目以减少总体工作量是否有帮助。

为了减轻构建的痛苦，您可以对构建使用“配置管理器…”选项来启用或禁用特定项目的构建。您可以有一个“Project[n]Build”，它可以排除某些项目，并在针对特定项目时使用它

就100多个项目而言，我知道你不想被这个问题所困扰，关于减少解决方案规模的好处，但我认为在加快devenv的加载时间（和内存使用）方面，你别无选择。

+1避免使用解决方案文件夹来帮助组织内容

+1用于项目生成，并将其保存到自己的文件夹中。我们最初尝试使用一个公共输出文件夹，这可能会导致查找过期引用的微妙和痛苦

---

FWIW，我们使用项目引用来解决方案，尽管nuget现在可能是一个更好的选择，但我们发现svn:externals对第三方和（框架类型）内部程序集都很有效。只要养成在引用svn:externals时使用特定修订号而不是HEAD的习惯就行了（罪名成立：）

我通常如何处理这个问题取决于“调试”过程实际上是如何发生的。通常情况下，尽管我没有将copy local设置为true。我为每个项目设置构建目录，以将所有内容输出到所需的端点

因此，在每次构建之后，我都会有一个包含所有dll和任何windows/web应用程序的填充文件夹，并且所有项目都位于正确的位置。由于dll最终位于正确的位置，因此不需要复制本地

注

---

以上内容适用于我的解决方案，这些解决方案通常是web应用程序，我在引用方面没有遇到任何问题，但这是可能的

我们也有类似的问题。我们使用更小的解决方案来解决它。我们有一个开放一切的主解决方案。但是性能。这是不好的。因此，我们按开发人员类型划分较小的解决方案。因此，DB开发人员有一个解决方案，它可以加载他们关心的项目，服务开发人员和UI开发人员也一样。很少有人需要打开整个解决方案来完成日常工作。这不是万能药——它有好的一面和坏的一面。请参阅“多解决方案模型”（忽略关于使用VSS:的部分）

我们有一个类似的问题，因为我们有109个单独的项目要处理。根据我们的经验回答最初的问题：

1。您如何最好地处理项目之间的参考资料

我们使用“添加引用”上下文菜单选项。如果选择了“项目”，则默认情况下，依赖项将添加到单个全局解决方案文件中

2。“本地复制”应该打开还是关闭？

根据我们的经验。额外的复制只会增加构建时间

3。每个项目是构建到自己的文件夹，还是构建到同一个输出文件夹（它们都是同一应用程序的一部分）

我们所有的输出都放在一个名为“bin”的文件夹中。其想法是，此文件夹与部署软件时的文件夹相同。这有助于防止开发人员设置与部署设置不同时出现问题

4。解决方案文件夹是组织资料的好方法吗？

根据我们的经验，没有。一个人的文件夹结构是另一个人的噩梦。深度嵌套的文件夹只会增加查找任何内容所需的时间。我们有一个完全扁平的结构，但将项目文件、程序集和名称空间命名为相同的名称

---

我们构建项目的方式依赖于单个解决方案文件。即使项目本身没有改变，构建这一过程也需要很长时间。为此，我们通常创建另一个“当前工作集”解决方案文件。我们正在进行的任何项目都将添加到此中。构建时间得到了极大的改进，尽管我们看到的一个问题是Intellisense在项目中定义的类型不在当前集合中时失败

我们的解决方案布局的部分示例：

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

---

我认为，对于这么大的解决方案，最好的做法应该是将其分解。您可以将“解决方案”视为一个集合必要项目和其他部分以解决问题的地方。通过将100多个项目分解为多个解决方案，专门为项目的一部分开发解决方案