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

Best practices for large solutions in Visual Studio (2008)

提问by Eyvind

We have a solution with around 100+ projects, most of them C#. Naturally, it takes a long time to both open and build, so I am looking for best practices for such beasts. Along the lines of questions I am hoping to get answers to, are:

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

• how do you best handle references between projects
  • should "copy local" be on or off?

• should every project build to its own folder, or should they all build to the same output folder(they are all part of the same application)

• Are solutions' folders a good way of organizing stuff?

• 你如何最好地处理项目之间的引用
  • “复制本地”应该打开还是关闭？

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

• 解决方案的文件夹是组织东西的好方法吗？

I know that splitting the solution up into multiple smaller solutions is an option, but that comes with its own set of refactoring and building headaches, so perhaps we can save that for a separate thread :-)

我知道将解决方案拆分为多个较小的解决方案是一种选择，但这有其自身的一组重构和构建问题，因此也许我们可以将其保存为单独的线程:-)

回答by David M

We work on a similar large project here. Solution folders has proved to be a good way of organising things, and we tend to just leave copy local set to true. Each project builds to its own folder, and then we know for each deployable project in there we have the correct subset of the binaries in place.

我们在这里开展了一个类似的大型项目。解决方案文件夹已被证明是一种组织事物的好方法，我们倾向于将 copy local 设置为 true。每个项目都构建到它自己的文件夹中，然后我们知道对于每个可部署的项目，我们都有正确的二进制文件子集。

As for the time opening and time building, that's going to be hard to fix without breaking into smaller solutions. You could investigate parallelising the build (google "Parallel MS Build" for a way of doing this and integrating into the UI) to improve speed here. Also, look at the design and see if refactoring some of your projects to result in fewer overall might help.

至于时间开放和时间建设，如果不分解成更小的解决方案，这将很难解决。您可以研究并行构建（谷歌“Parallel MS Build”以获取执行此操作并集成到用户界面的方法）以提高速度。另外，看看设计，看看重构你的一些项目以减少整体是否有帮助。

回答by Michael Meadows

In terms of easing the building pain, you can use the "Configuration Manager..." option for builds to enable or disable building of specific projects. You can have a "Project [n] Build" that could exclude certain projects and use that when you're targeting specific projects.

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

As far as the 100+ projects goes, I know you don't want to get hammered in this question about the benefits of cutting down your solution size, but I think you have no other option when it comes to speeding up load time (and memory usage) of devenv.

就 100 多个项目而言，我知道您不想在这个关于减少解决方案大小的好处的问题上受到重创，但我认为在加快加载时间（和内存使用情况）devenv。

回答by si618

+1 for sparinguse of solution folders to help organise stuff.

+1 用于节省使用解决方案文件夹来帮助组织内容。

+1 for project building to its own folder. We initially tried a common output folder and this can lead to subtle and painful to find out-of-date references.

+1 用于将项目构建到其自己的文件夹。我们最初尝试了一个通用的输出文件夹，这可能会导致难以找到过时的引用。

FWIW, we use project references for solutions, and although nuget is probably a better choice these days, have found svn:externals to work well for both 3rd party and (framework type) in-house assemblies. Just get into the habit of using a specific revision number instead of HEAD when referencing svn:externals (guilty as charged:)

FWIW，我们使用项目引用作为解决方案，虽然现在 nuget 可能是更好的选择，但我们发现 svn:externals 对于 3rd 方和（框架类型）内部程序集都可以很好地工作。只是在引用 svn:externals 时养成使用特定修订号而不是 HEAD 的习惯（被指控有罪：）

回答by Mitchel Sellers

What I typically do with this depends a bit on how the "debug" process actually happens. Typically though I do NOT set copy local to be true. I setup the build directory for each project to output everything to the desired end point.

我通常对此做什么取决于“调试”过程实际上是如何发生的。通常，尽管我不会将复制本地设置为 true。我为每个项目设置了构建目录以将所有内容输出到所需的端点。

Therefore after each build I have a populated folder with all dll's and any windows/web application and all items are in the proper location. Copy local wasn't needed since the dll's end up in the right place in the end.

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

Note

笔记

The above works for my solutions, which typically are web applications and I have not experienced any issues with references, but it might be possible!

以上适用于我的解决方案，这些解决方案通常是 Web 应用程序，我没有遇到任何参考问题，但它可能是可能的！

回答by JP Alioto

We have a similar issue. We solve it using smaller solutions. We have a master solution that opens everything. But perf. on that is bad. So, we segment up smaller solutions by developer type. So, DB developers have a solution that loads the projects they care about, service developers and UI developers the same thing. It's rare when somebody has to open up the whole solution to get what they need done on a day to day basis. It's not a panacea -- it has it's upsides and downsides. See "multi-solution model" in this article(ignore the part about using VSS :)

我们有一个类似的问题。我们使用较小的解决方案来解决它。我们有一个可以打开一切的主解决方案。但性能。那是坏的。因此，我们按开发人员类型细分较小的解决方案。因此，DB 开发人员有一个加载他们关心的项目的解决方案，服务开发人员和 UI 开发人员同样如此。当有人不得不打开整个解决方案来完成他们每天需要完成的事情时，这种情况很少见。它不是万能药——它有它的优点和缺点。请参阅“多解模式”在这篇文章中（忽略有关使用VSS部分:)

回答by Thomas Bratt

We have a similar problem as we have 109 separate projects to deal with. To answer the original questions based on our experiences:

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

1. How do you best handle references between projects

1.你如何最好地处理项目之间的引用

We use the 'add reference' context menu option. If 'project' is selected, then the dependency is added to our single, global solution file by default.

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

2. Should "copy local" be on or off?

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

Off in our experience. The extra copying just adds to the build times.

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

3. Should every project build to its own folder, or should they all build to the same output folder(they are all part of the same application)

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

All of our output is put in a single folder called 'bin'. The idea being that this folder is the same as when the software is deployed. This helps prevents issues that occur when the developer setup is different from the deployment setup.

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

4. Are solutions folders a good way of organizing stuff?

4. 解决方案文件夹是组织东西的好方法吗？

No in our experience. One person's folder structure is another's nightmare. Deeply nested folders just increase the time it takes to find anything. We have a completely flat structure but name our project files, assemblies and namespaces the same.

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

---

---

Our way of structuring projects relies on a single solution file. Building this takes a long time, even if the projects themselves have not changed. To help with this, we usually create another 'current working set' solution file. Any projects that we are working on get added in to this. Build times are vastly improved, although one problem we have seen is that Intellisense fails for types defined in projects that are not in the current set.

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

A partial example of our solution layout:

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

\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]

回答by Blake Taylor

I think with solutions this large the best practice should be to break them up. You can think of the "solution" as a place to bring together the necessary projects and perhaps other pieces to work on a solution to a problem. By breaking the 100+ projects into multiple solutions specialized to developing solutions for only a part of the overall problem you can deal with less at a given time there by speeding your interactions with the required projects and simplifying the problem domain.

我认为对于这么大的解决方案，最佳实践应该是将它们分解。您可以将“解决方案”视为将必要的项目和其他部分汇集在一起​​以解决问题的地方。通过将 100 多个项目分解为多个解决方案，专门针对整个问题的一部分开发解决方案，通过加快与所需项目的交互并简化问题域，您可以在特定时间内处理更少的问题。

Each solution would produce the output which it is responsible for. This output should have version information which can be set in an automated process. When the output is stable you can updated the references in dependent projects and solutions with the latest internal distribution. If you still want to step into the code and access the source you can actually do this with the Microsoft symbol server which Visual Studio can use to allow you to step into referenced assemblies and even fetch the source code.

每个解决方案都会产生它负责的输出。此输出应具有可在自动化过程中设置的版本信息。当输出稳定时，您可以使用最新的内部分发更新相关项目和解决方案中的参考。如果您仍想单步执行代码并访问源代码，您实际上可以使用 Microsoft 符号服务器来执行此操作，Visual Studio 可以使用它来允许您单步执行引用的程序集甚至获取源代码。

Simultaneous development can be done by specifying interfaces upfront and mocking out the assemblies under development while you are waiting for dependencies that are not complete but you wish to develop against.

可以通过预先指定接口并模拟正在开发的程序集来完成同步开发，同时您正在等待不完整但您希望针对其进行开发的依赖项。

I find this to be a best practice because there is no limit to how complex the overall effort can get when you break down it down physically in this manner. Putting all the projects into a single solution will eventually hit an upper limit.

我发现这是一种最佳实践，因为当您以这种方式将其物理分解时，整体工作的复杂程度是没有限制的。将所有项目放在一个解决方案中最终会达到上限。

Hope this information helps.

希望这些信息有帮助。

回答by Vasu Balakrishnan

We have about 60+ projects and we don't use solution files. We have a mix of C# and VB.Net projects. The performance was always an issue. We don't work on all the projects at the same time. Each developer creates their own solution files based on the projects they're working on. The solution files doesn't get checked into our source control.

我们有大约 60 多个项目，我们不使用解决方案文件。我们混合了 C# 和 VB.Net 项目。表演一直是个问题。我们不会同时处理所有项目。每个开发人员根据他们正在处理的项目创建自己的解决方案文件。解决方案文件不会被签入我们的源代码管理。

All Class library projects would build to a CommonBin folder at the root of the source directory. Executable / Web Projects build to their individual folder.

所有类库项目都将构建到源目录根目录下的 CommonBin 文件夹中。可执行文件/Web 项目构建到它们各自的文件夹中。

We don't use project references, instead file based reference from the CommonBin folder. I wrote a custom MSBuild Task that would inspect the projects and determine the build order.

我们不使用项目引用，而是使用来自 CommonBin 文件夹的基于文件的引用。我编写了一个自定义 MSBuild 任务来检查项目并确定构建顺序。

We have been using this for few years now and have no complaints.

我们已经使用它几年了，没有任何抱怨。

回答by Sayed Ibrahim Hashimi

You might be interested in these two MSBuild articles that I have written.

您可能对我写的这两篇 MSBuild 文章感兴趣。

MSBuild: Best Practices For Creating Reliable Builds, Part 1

MSBuild：创建可靠构建的最佳实践，第 1 部分

MSBuild: Best Practices For Creating Reliable Builds, Part 2

MSBuild：创建可靠构建的最佳实践，第 2 部分

Specificially in Part 2 there is a section Building large source treesthat you might want to take a look at.

特别是在第 2 部分中有一节构建大型源代码树，您可能想看一看。

To briefly answer your questions here though:

在这里简要回答您的问题：

• CopyLocal?For sure turn this off
• Build to one or many output folders?Build to one output folder
• Solution folders?This is a matter of taste.

• 复制本地？一定要关掉这个
• 生成一个或多个输出文件夹？构建到一个输出文件夹
• 解决方案文件夹？这是一个品味问题。

Sayed Ibrahim Hashimi

赛义德·易卜拉欣·哈希米

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

我的书：Microsoft Build Engine 内部：使用 MSBuild 和 Team Foundation Build

回答by Nicolas Dorier

Unload projects you don't use often, and buy a SSD. A SSD doesn't improve compile time, but Visual Studio becomes twice faster to open/close/build.

卸载不常用的项目，买个SSD。SSD 不会缩短编译时间，但 Visual Studio 的打开/关闭/构建速度提高了两倍。