独立开发/部署MVC区域

时间:2012-03-28 08:22:43

标签: asp.net-mvc version-control deployment asp.net-mvc-3-areas

我们目前有两个完全独立运行的MVC Web应用程序。目的是将这两个站点绑定在某种内联网上,共享授权等,并将某些主页链接到每个站点。

到目前为止,我们已经创建了第三个MVC应用程序,并将两个现有站点作为MVC区域添加到此,这非常有效。我们还设法在单个解决方案下将每个区域分成他们自己的Visual Studio项目。

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

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

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

第二种方法是主要内部网项目仅引用区域项目的程序集而不是项目本身,因此它可以自行构建而无需再次构建每个区域或反之亦然。对此有两个问题,我无法看到MS WebDeploy(由buildserver用来发布我们的代码)只发布某些程序集的方法。其次,单独程序集中的MVC区域似乎需要添加为项目引用而不仅仅是程序集引用,因为视图不能正确动态编译(缺少〜/ Views / web.config?)

有没有更好的方法呢?

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

下一个问题是使用MSDeploy部署整个批次。区域程序集与主应用程序一起部署在/ bin目录中,但不包括区域的views / scripts / content。我正在研究将各种视图编译到程序集本身的各种技术,但似乎无法使其工作。

1 个答案:

答案 0 :(得分:0)

让我觉得这是一个非常复杂的方法。我希望不久之后,拥有共享安全代码的好处似乎没有理由让你将两个本质上不同的应用程序的代码库交织在一起这样的痛苦。

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

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

相关问题