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

Question

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

c#visual-studio-2008msbuildprojects-and-solutions

89

我们有一个涉及到100多个项目的解决方案，其中大部分是C#。自然而然地，打开和构建速度都很慢，因此我正在寻找这类庞大项目的最佳实践。希望得到回答的问题如下：

如何处理项目之间的引用最佳
- "拷贝本地"应该打开还是关闭？
每个项目是否应该构建到自己的文件夹中，还是它们都构建到同一个输出文件夹中（它们都是同一个应用程序的一部分）？
解决方案的文件夹是组织东西的好方法吗？

我知道将解决方案拆分为多个较小的解决方案是一种选择，但这会带来自己的重构和构建困难，因此也许我们可以将其保留到另一个主题中 :-)

- Eyvind

2

我可以问一下为什么一个单一的解决方案需要100多个项目吗？它们每个都在创建自己的程序集吗？ - Neil N

1

是的，它们是独立的，每个模块代表一个逻辑上单独的功能块。 - Eyvind

2

@Eyvind - 难道这不是类和命名空间的作用吗？分离的程序集给你带来了什么好处？我可以想到一些，比如可能更小的升级和内存使用（如果没有加载某些程序集），但是编译和管理100多个程序集肯定会有成本。 - si618

1

@Mark 我感同身受。我们这里已经有94个项目了。现在我们无法做太多事情，因为我们必须停止多个团队的开发来进行重组。我们有3个EXE项目引用了其他91个项目。我正在尝试使用一个共同的输出文件夹，到目前为止收益非常显著。 - Kevin

2

哥们，100+？这对于我们来说算不了什么...我们现在已经接近600了... - C.J.

显示剩余3条评论

12个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user306031 · Answer 1

这一切都与您对解决方案和项目的定义和观点有关。在我看来，解决方案就是一个逻辑分组，用于解决非常具体的需求的项目集合。我们开发了一个大型的内部网络应用程序。该内部网络中的每个应用程序都有自己的解决方案，其中可能还包含用于exes或windows服务的项目。然后，我们有一个集中式框架，其中包括基类、帮助程序和httphandler/httpmodule。基本框架相当庞大，并被所有应用程序使用。通过以这种方式拆分许多解决方案，您可以减少解决方案所需的项目数量，因为它们中的大多数与彼此无关。

在一个解决方案中有那么多项目只会导致糟糕的设计。没有理由在一个解决方案下拥有那么多项目。我看到的另一个问题是项目引用，它们最终可能会让你陷入困境，特别是如果您想将解决方案拆分成更小的部分。

我的建议是这样做并开发一个集中式框架（如果您愿意，可以实现自己的企业库）。您可以将其GAC共享，也可以直接引用文件位置，以便您拥有一个中央存储库。您还可以对集中式业务对象使用相同的策略。

如果您想直接引用 DLL，您需要在项目中以复制本地 false 的方式引用它（例如 c:\mycompany\bin\mycompany.dll）。在运行时，您需要向 app.config 或 web.config 添加一些设置，以使其引用不在 GAC 或运行时 bin 中的文件。实际上，无论是复制本地还是不复制本地，或者 DLL 最终是否在 bin 中或甚至在 GAC 中，都没有关系，因为配置将覆盖这两个选项。我认为复制本地并且系统混乱是一种不好的做法。但是，如果您需要调试其中一个程序集，则很可能需要暂时复制本地。

您可以阅读我的文章，了解如何在没有 GAC 的情况下全局使用 DLL。我真的不喜欢 GAC，主要是因为它阻止了 xcopy 部署，并且不会触发应用程序的自动重启。

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

- Michael Freidgeim · Answer 2

将CopyLocal设置为false可以减少构建时间，但在部署时可能会导致不同的问题。

有许多情况需要将“Copy Local”保留为True，例如顶层项目，二级依赖项，通过反射调用的DLL。

我将CopyLocal设置为false的经验并不成功。请参阅我的博客文章{{link1：“除非了解后续步骤，否则不要将“Copy Local”项目引用更改为false。”}}中的优缺点总结。