See*_*vil 5 deployment version-control asp.net-mvc asp.net-mvc-3-areas
我们目前有2个MVC Web应用程序完全独立运行.目的是将这两个站点绑定在某种内联网上,共享授权等,并将某些主页链接到每个站点.
到目前为止,我们已经创建了第三个MVC应用程序,并将两个现有站点作为MVC区域添加到此,这非常有效.我们还设法在单个解决方案下将每个区域分成他们自己的Visual Studio项目.
这两个领域中的每一个都由完全不同的业务部门进行规划,并且(通常)由不同的开发人员开发,并且需要遵循独立的发布周期.
当前的方法是将每个区域放在单独的存储库路径中,并使构建服务器签出每个区域的适当分支,构建主Web应用程序(Intranet主页事物),然后构建引用的区域项目.这个问题是我们必须每次都要部署所有3个项目,即使只有一个区域需要发布.
这不是一个大问题(假设我们不会意外地部署一个新的,未经测试的主内部网Web应用程序与该区域一起发布),但这也意味着构建服务器将使用相同的方式标记特定构建的所有程序集版本号.
第二种方法是主要内联网项目仅参考区域项目的组件而不是项目本身,因此它可以自己构建而无需再次构建每个区域或反之亦然.对此有两个问题,我无法看到MS WebDeploy(由buildserver用来发布我们的代码)只发布某些程序集的方法.其次,单独程序集中的MVC区域似乎需要添加为项目引用而不仅仅是程序集引用,因为视图不能正确动态编译(缺少〜/ Views/web.config?)
有没有更好的方法呢?
编辑:我已经设法让主要的Web应用程序运行与区域的常规程序集引用而不是项目引用(不完全确定如何,它只是工作).这意味着我现在可以根据需要独立于主应用程序构建区域.
下一个问题是使用MSDeploy部署整个批次.区域程序集与主应用程序一起部署在/ bin目录中,但不包括区域的views/scripts/content.我正在研究将各种视图编译到程序集本身的各种技术,但似乎无法使其工作.
令我震惊的是,这是一个非常复杂的方法。我预计不久之后,共享安全代码的好处似乎就不足以证明您将经历两个本质上不同的应用程序的代码库像这样交织在一起所带来的痛苦。
更好的方法可能是分离应用程序并为两者开发一个登录组件。如果您希望用户对两个应用程序只有一个帐户,则可以管理自己的数据库;如果每个应用程序都需要管理自己的用户帐户,则可以使用每个应用程序的数据库(假设它们有单独的数据库)。有大量的 Membership 组件可以为此类功能提供基础(ASP.NET MembershipProvider 和 Simple Membership,仅举两个例子)。
如果您希望这两个应用程序在生产环境中的同一域下运行,只需将它们部署到单独的虚拟目录即可。您最终将得到类似于使用区域的 url 方案。
| 归档时间: |
|
| 查看次数: |
2035 次 |
| 最近记录: |