对于我们公司，我正在创建一个大型外联网网站，其中包含一组子应用程序。我对解决方案和项目的正确设置感到有些困惑。
我有一个我们称之为 Portal 的 Web 应用程序。它包含身份验证/授权类、母版页、导航/url 路由类和主题定义。它还将包含一些基本概述，供我们的客户快速了解他们的项目状态。
在接下来的一年中，我们将开发更多应用程序并将其与门户网站集成。将其视为称为功能 A、B 和 C 的详细概述和工具。多年来，我们将改进这些应用程序并发布新版本。这些 Web 应用程序应该无缝地适应门户网站的导航。我希望他们重用母版页和主题。
设置此解决方案的正确方法是什么？
如何将应用程序捆绑在一起，重新使用母版页并保持可维护性？
如何以适当的方式共享某些 Web 控件 (ASCX)？
我们正在使用 TFS，也许有任何分支/合并的想法？
编辑：
我想在 ASP.Net WebForms 中创建它，我们在该领域拥有最多的经验。但基本上我们可以使用任何东西，我们可以自己控制网络服务器（只要它是面向 Microsoft 的，而不是切换到 php 或类似的东西 :)）
正如 Brian 所说，在公开 API 时，您应该尽可能多地承诺，这意味着它应该在初始发布后尽可能少地更改。但是，要使某些东西变得稳定需要预先付出大量努力，因此如果您还没有准备好提交 API，您应该尽可能地将其内部化，因此您可能希望将事物组合起来而不是将它们分开。
但是，我不会根据 5 段描述来推荐适合您的应用程序的架构。您需要做的是权衡拥有几个大项目与拥有一堆松散耦合的小项目的利弊。我的意思是，如果你坚持计划，你提前做的计划越多，你就越容易做到。
因此，与 Brians 的回答相反，我不建议您让整个系统“尽可能松耦合”，只要让它尽可能松耦合即可。;) 如果您滥用它，松散耦合的代码可能会造成与紧密耦合的代码一样多的麻烦。
请参阅：
1.多个小组件或一个大组件哪个更好？
2.许多“小”组件的具体缺点？
最后，只有你知道你想把重点放在每一个“......能力”、可维护性、可扩展性、可靠性等上。所以要明确你的优先级和目标，并相应地进行计划。
关于分支策略，您可以阅读TFS 分支指南 2.0，它很好地介绍了从基本到高级的各种分支策略。即使您不使用 TFS，这也是一个很好的阅读指南（我目前使用 SVN）。由于我目前在有 1-4 名开发人员的小团队中工作，因此我倾向于使用介于基本和标准之间的策略。并不是我向您推荐这个，而是什么对我们的团队最有效。
至于在项目之间共享代码。在 SVN 中，我们可以使用“ externals ”，这意味着共享文件将出现在多个文件夹中，因此当您更改一个副本并将更改提交到 svn 时，所有其他副本将在下一次 svn 更新时更新。但是，我不记得 TFS 是否有类似的东西。
注意：当心 SVN 中的外部...它们可能会导致...问题。;)
我的建议是尽量避免共享 aspx、ascx 和母版页。它通常带来的伤害远大于帮助。而是尝试使用继承或其他替代方法来实现您的目标。
ASP.NET MVC 2.0 有一个称为“区域”的概念，您可以在其中构建与其余部分隔离的应用程序的子部分。据我所知，这些区域可以在与“主”应用程序不同的项目中维护。这听起来很像您的要求，所以也许您应该调查一下。
希望这是有道理的。;)
What is the proper way to setup this solution?
正确的方法……有这么多。我见过很多应用程序和很多不同的设置（其中很多我认为是“合适的”）。你真正要的是为你的情况寻找最好的方法。
因为您正在构建一个门户，所以您将拥有功能分离的优势，这将在您为应用程序开发附加功能时为您提供帮助。
我会为每个功能设置一个带有单独文件夹的网站。使其成为一个单独的网站将允许所有功能共享相同的母版页、用户控件和配置文件 - 而无需做任何特别的事情。（在那张纸条上，我会将您所有的母版页单独放在一个文件夹中，并为您的用户控件创建另一个文件夹）。
How can I tie the applications together, re-use the master pages and keep it maintainable?
再次......文件夹是这里的最佳选择。文件夹将有助于分离每个功能，使应用程序易于管理。
How can I share certain webcontrols (ASCX) in a proper way?
首先，ascx 文件不是 web 控件。它们是用户控件。WebControl 是一个用于创建驻留在单独程序集中的服务器控件的类。关于用户控件，正如我上面所说，如果您将它们放在单独的文件夹中，它们总是在一个地方并且在整个应用程序中都可用。
We are using TFS, perhaps any branching/merging ideas?
你真的不需要在这里做任何特别的事情。关于分支，您可以采取许多不同的路径：
当我决定如何分支我的代码时，我会考虑什么最能保护我。在您的情况下，您需要计划在功能版本之间进行错误修复，因此每个版本之后的一个分支可能最有意义（将其称为您的开发分支）。但是，鉴于功能的分离，一个功能可能不会影响应用程序的其余部分。为了安全起见，您可能不需要这种分支。
我会考虑使您的系统尽可能松散耦合。随着/当您添加更多应用程序时，您的网站将变得越来越不可靠（因为没有任何组件会在 100% 的时间内运行，将这些组合起来会降低您的整体可靠性）。所以你应该构建你的系统来满足非主要服务的需求（我相信亚马逊主页，例如，有 100 种服务对其做出贡献，因此它是为了容错而构建的）
服务之间的 API 应该尽可能保持稳定，这样实现可以在不破坏耦合的情况下进行更改。您还应该在 Web 级别（可能是Selenium或类似的？）研究对此的自动化测试，因为测试单个服务将几乎无法覆盖整体行为。
您可能会发现查看实现自定义VirtualPathProvider很有用。在我的上一个项目中，我们有多个 ASP.NET 站点需要共享主题文件（母版页、用户控件、图像、样式表），因此我创建了一个 VirtualPathProvider，它允许我们将虚拟文件夹（例如 /Themes）映射到任何物理文件夹硬盘驱动器上的文件夹（例如 C:\Shared\SiteThemes）。
这不是微不足道的，但没有花费太长时间，也没有造成任何问题。顺便说一句，事实证明这是克服 WiX 中最大组件限制的好方法……请注意，您不能预编译使用 VirtualPathProvider 的站点。
从现在开始使用 MVC 概念。它们为强大的应用程序提供了更多的可扩展性和灵活性。
您可能会考虑使用 SharePoint。对于 ASP.NET 应用程序交付来说，它是一个相当不错的平台，尤其是当它们共存于 Intranet 环境中时；它免费为您提供了很多东西。
当然，它的肘部非常粗糙，可以这么说，所以要谨慎行事。
我不认为应用程序是独立的，而是作为整个门户的模块。
我建议您查看 MEF，因为这似乎是一个完美的选择。
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx