具有大量项目的Visual Studio解决方案

作者: My☀
发布时间: 2025-01-05 05:17:56 (29天前)
转自：

7 条回复

0#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我真正看到需要多种解决方案的唯一时间是功能隔离。 Windows服务所需的库可能与网站不同。应优化每个解决方案以生成单个可执行文件或网站IMO。它增强了关注点的分离，并且可以轻松地重建应用程序的功能部分，而无需构建其他所有内容。 </p> </DIV>

编辑
1#
回复此人
只怕再见是故人 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 与VS2008相比，VS2010的智能感应性能应该要好一些。另外，为什么需要一直重建整个解决方案？只有在依赖树的根部附近更改某些内容时才会发生这种情况，否则您只需构建您当前正在处理的项目。 </p> <P> 我总是找到它 <EM> 有帮助 </EM> 将所有内容都放在一个解决方案中，因为我可以轻松地浏览整个代码库。 </p> </DIV>

编辑
2#
回复此人
࿏自ོ༾由ོ༽人͙⃡⌇ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 将这样的解决方案分解为可编译和可测试的独立于“母”解决方案的小型解决方案是一个好主意吗？这种方法有任何潜在的缺陷吗？ </p> </BLOCKQUOTE> <P> 是的，这是一个好主意，因为： </p> <UL> <LI> 你不希望VS放慢使用几十个VS项目的解决方案。 </LI> <LI> 仅关注代码的一部分可能会很有趣，这会强制执行代码局部性的概念，这是一件好事。 </LI> </UL> <P> 但是，最重要的是要争取尽可能少的VS项目/组件。我公司发表了两篇 <a href="http://www.ndepend.com/WhiteBooks.aspx" rel="nofollow noreferrer"> 免费两本白书 </A> 这解释了使用程序集/ VS项目/命名空间来划分大型代码库的利弊。 </p> <UL> <LI> <a href="http://www.ndepend.com/Res/NDependWhiteBook_Assembly.pdf" rel="nofollow noreferrer"> 通过.NET程序集和Visual Studio项目对代码库进行分区 </A> （8页） </LI> <LI> <a href="http://www.ndepend.com/Res/NDependWhiteBook_Namespace.pdf" rel="nofollow noreferrer"> 使用命名空间定义.NET组件 </A> （7页） </LI> </UL> <P> 第一本白皮书还解释说，在使用包含数十个项目的解决方案时VS很慢，并且展示了如何解决这种缓慢问题的技巧。 </p> </DIV>

编辑
3#
回复此人
日耀九洲 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> Visual Studio 2010 Ultimate提供了多种工具来帮助您更好地理解和管理现有代码中的依赖项： </p> <UL> <LI> 依赖关系图和Architecture Explorer </LI> <LI> 序列图 </LI> <LI> 层图和验证 </LI> </UL> <P> 有关详细信息，请参阅 <a href="http://msdn.microsoft.com/en-us/library/dd409365.aspx" rel="nofollow noreferrer"> 探索现有规范 </A> 。该 <a href="http://msdn.microsoft.com/en-us/library/dd460723.aspx" rel="nofollow noreferrer"> 可视化和建模功能包 </A> 为C ++和C代码提供依赖图支持。 </p> </DIV>

编辑
4#
回复此人
撩心 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 让我重申一下你的问题： </p> <BLOCKQUOTE> <P> 将这样的解决方案分解为更小的解决方案是一个好主意 </p> </BLOCKQUOTE> <P> 该 <a href="http://msdn.microsoft.com/en-us/library/ee817674.aspx" rel="noreferrer"> 您链接的MSDN文章 </A> 做了一个非常明确的声明： </p> <BLOCKQUOTE> <P> 的<strong> 重要 </强> 除非您有充分的理由使用多解决方案模型，否则应避免这种情况并采用单一解决方案模型，或采用较大系统中的分区单一解决方案模型。与多解决方案模型相比，它们更易于使用并提供许多显着优势，这将在以下各节中讨论。 </p> </BLOCKQUOTE> <P> 而且，文章建议你的<strong> 总是 </强> 在构建过程中有一个“主”解决方案文件。 </p> <BLOCKQUOTE> <P> 这种方法有任何潜在的缺陷吗？ </p> </BLOCKQUOTE> <P> 您将不得不处理以下问题（实际上可能很难做到，与上面的引用相同）： </p> <BLOCKQUOTE> <P> 多解决方案模型受到影响以下缺点： </p> <UL> <LI> 当您需要引用时，您被迫使用文件引用由项目生成的程序集一个单独的解决方这些（不像项目参考）不自动设置构建依赖。这意味着你必须解决解决方案构建的问题系统构建脚本中的顺序。虽然这可以管理，但它补充道构建过程的额外复杂性。 </LI> <LI> 您还被迫引用了一个特定的配置版本 DLL（例如，Release或Debug 版）。项目参考自动管理这个和引用当前活动的 Visual Studio .NET中的配置。 </LI> <LI> 使用单个解决方案时，您可以获得最新的代码（可能在其他项目中）开发由其他团队成员执行本地集成测试。你可以确认在检查之前没有任何破坏你的代码回到VSS准备好了下一个系统构建。在多解决方案中系统这很难做到，因为你可以测试你的解决方案仅针对其他解决方案使用以前系统的结果建立。 </LI> </UL> </BLOCKQUOTE> </DIV>

编辑
5#
回复此人
圈圈红 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我们有~250个项目的解决方案。 </p> <P> 安装Visual Studio 2005补丁后，可以快速处理极大的解决方案[TODO add link]。 </p> <P> 我们还为团队选择他们喜欢的项目提供了更小的解决方案，但是每个添加的项目也都要添加到主解决方案中，而且很多人都喜欢使用它。 </p> <P> 我们重新编程F7快捷方式（构建）来构建启动项目而不是整个解决方案。那更好。 </p> <P> 解决方案文件夹似乎解决了找到问题的问题。 </p> <P> 依赖关系只添加到顶级项目（EXE和DLL），因为当你有静态库时，如果A是B的依赖关系，B是C的依赖关系，A可能通常不需要是C的依赖关系（为了使事情编译和正确运行）这样，循环依赖对于编译器是可以的（虽然对心理健康非常不利）。 </p> <P> 我支持拥有更少的库，甚至可以拥有一个名为“library”的库。我认为通过“仅仅需要它”来优化进程内存占用空间并没有明显的优势，链接器应该在目标文件级别上进行。 </p> </DIV>

编辑

登录后才能参与评论