visual-studio 解决方案：每个应用程序或每个应用程序套件
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/200954/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Solution: Per application, or per application suite
提问by ProfK
Often multiple applications share a large codebase of libraries that change often in development. In these cases, I prefer to create a solution named after the suite, and include separate projects for each application and the shared libraries.
通常，多个应用程序共享大量在开发中经常更改的库代码库。在这些情况下，我更喜欢创建一个以套件命名的解决方案，并为每个应用程序和共享库包含单独的项目。
Is this a good approach? How do others structure their code bases for things like a suite of applications?
这是一个好方法吗？其他人如何为应用程序套件之类的东西构建他们的代码库？
回答by Greg D
It really depends on your organization's particular needs. MSDN has a good pagethat goes through the various recommended solution layouts, including:
这实际上取决于您组织的特定需求。MSDN 有一个很好的页面，其中介绍了各种推荐的解决方案布局，包括：
- The Single Solution model (preferred)
- The Partitioned Single Solution model
- The Multi-solution model (Only if strictly necessary)
- 单一解决方案模型（首选）
- 分区单一解决方案模型
- 多解决方案模型（仅在绝对必要时）
The MSDN pagealso discusses the pros and cons of each model in more detail so you can decide which one makes sense for you. :)
在MSDN网页还讨论了每个模型的优劣更详细，所以你可以决定哪一个有意义的你。:)
In general, for an application suite such as you describe, I would consider the partitioned, single solution model. There's a single master solution that builds everything, and a number of separate solutions for each individual application within the suite (assuming the applications are of appreciable size).
一般来说，对于您描述的应用程序套件，我会考虑分区的单一解决方案模型。有一个单一的主解决方案可以构建所有内容，并且套件中的每个单独应用程序都有许多单独的解决方案（假设应用程序具有可观的大小）。
If the applications in the suite are small and build quickly (e.g., a suite of command line tools), I might not even generate the separate solution files. That's really a judgement call we can't make for you. :)
如果套件中的应用程序很小并且构建速度很快（例如，一套命令行工具），我什至可能不会生成单独的解决方案文件。这真的是我们无法为您做出的判断。:)
回答by David Schmitt
The actual structure of your solution(s) really depends on the internal workflow. Having a very agile, everyone-refactors-everything approachwould point towards one solutionwith many projects. If your shop has a dedicated library teamand various application teams, which do regular internal releases, then separate solutionsmight help through stronger decoupling, and reduced build times.
解决方案的实际结构实际上取决于内部工作流程。拥有一种非常敏捷的、每个人都重构的方法将指向一个包含多个项目的解决方案。如果您的商店有专门的库团队和各种应用程序团队，他们定期进行内部发布，那么单独的解决方案可能有助于通过更强的解耦和减少构建时间。
