asp.net-mvc - 独立开发/部署MVC区域

Question

我们目前有 2 个完全独立运行的 MVC Web 应用程序。目的是将这两个站点在某种具有共享授权等的 Intranet 中以及某种链接到每个站点的主页中联系在一起。

到目前为止，我们已经创建了第三个 MVC 应用程序，并将两个现有站点作为 MVC 区域添加到其中，效果很好。我们还设法在单个解决方案下将每个区域分成各自的 Visual Studio 项目。

这两个领域中的每一个都由完全不同的业务部门指定，并且(通常)由不同的开发人员开发，并且需要遵循独立的发布周期。

当前的方法是将每个区域放在单独的存储库路径中，并让构建服务器 check out 每个区域的相应分支，构建主 Web 应用程序(Intranet 主页)，然后构建引用的区域项目。问题是我们每次必须始终部署所有 3 个项目，即使只有一个区域需要发布。

这不是什么大问题(假设我们没有意外地部署一个新的、未经测试的主内网 Web 应用程序版本以及该区域)，但这也意味着构建服务器将使用相同的标记标记特定构建的所有程序集版本号。

第二种方法是主内网项目仅引用区域项目的程序集而不是项目本身，因此它可以自行构建而无需再次构建每个区域，反之亦然。 2 与此相关的问题，我看不到 MS WebDeploy(由构建服务器用于发布我们的代码)仅发布某些程序集的方法。其次，单独程序集中的 MVC 区域似乎需要添加为项目引用，而不仅仅是程序集引用，因为 View 不能正确动态编译(缺少 ~/Views/web.config？)

有没有更好的方法来解决这个问题？

编辑:我已经设法让主 Web 应用程序使用对区域的常规程序集引用而不是项目引用来运行(不完全确定如何，它只是有效)。这意味着我现在可以根据需要独立于主应用程序构建区域。

下一个问题是使用 MSDeploy 部署整个批次。区域程序集与/bin 目录中的主应用程序一起部署，但不包括区域的 View /脚本/内容。我正在研究将 View 编译为程序集本身的各种技术，但似乎还无法使其正常工作。

Answer 1

让我震惊的是，这是一种非常复杂的方法。我预计不久之后，共享安全代码的好处似乎不足以证明您将两个本质上不同的应用程序的代码库像这样交织在一起所带来的痛苦。

更好的方法可能是将应用程序分开并为两者开发单一登录组件。这可以管理自己的数据库，如果您希望用户对两个应用程序只有一个帐户，或者如果每个应用程序都需要管理自己的用户帐户，则可以使用每个应用程序的数据库(假设他们有单独的数据库)。有许多 Membership 组件可用于为此类功能提供基础(ASP.NET MembershipProvider 和 Simple Membership，仅举两个例子)。

如果您希望两个应用程序在生产环境中的同一域下运行，只需将它们部署到单独的虚拟目录即可。您最终会得到一个类似于使用区域的 url 方案。