5

We currently have 2 MVC web applications running completely independently of each other. The aim is to tie these 2 sites together in some sort of Intranet with shared authorisation etc. and some sort of home page linking to each.

So far we have created a 3rd MVC application and added both of the existing sites as MVC areas to this, which works nicely. We've also managed to separate each area into their own Visual Studio projects under a single solution.

Each of the 2 areas are specced by completely different departments of the business and (usually) developed by different developers and will need to follow independent release cycles.

The current approach is to have each area in separate repository paths and have the build server checkout the appropriate branch for each area, build the main web application (Intranet home page thing) which will in turn build the referenced area projects. The problem with this is we have to always deploy all 3 projects each time, even if just one area wants a release.

This isn't a massive deal (assuming we don't accidentally deploy a new, untested release of the main intranet web app along with the area) but it also means that the build server will stamp all assemblies of a particular build with the same version number.

A second approach was for the main intranet project to reference only the assemblies of the area projects and not the projects themselves, so it could be built on its own without having to build each area again or vise versa. 2 problems with this, I can't see a way with MS WebDeploy (used by the buildserver to publish our code) to publish just certain assemblies. Secondly, MVC areas in separate assemblies seemingly need to be added as project references and not just assembly references as views don't dynamically compile properly (missing ~/Views/web.config?)

Are there any better approaches to this?

EDIT: I've managed to get the main web application to run with regular assembly references to the areas and not project references (not entirely sure how, it just works). This means I can now build the areas independently of the main app as required.

The next problem is a deploying the whole lot with MSDeploy. The area assembly is deployed with the main app in the /bin directory but the area's views/scripts/content are not included. I'm looking at various techniques for compiling views into the assemblies themselves but can't seem to get this working yet.

SeeNoWeevil
  • 2,549
  • 4
  • 26
  • 39
  • Are there any other reasons you're trying to merge them other than authentication? It sounds like a shared auth method (OAuth, Active Directory or Windows identity framework) are more suited to the problem than trying to merge your applications. – Betty Mar 28 '12 at 09:26
  • 2
    The main reason they were converted to areas under a main web application (instead of 3 separate web apps) was to reduce duplicated content i.e login/account controllers, shared layouts, scripts, css etc. It all had to seem as one site. – SeeNoWeevil Mar 29 '12 at 08:00
  • Have you tried Portable Areas? http://elegantcode.com/2012/04/06/mvc-portable-areas – Betty Apr 07 '12 at 02:36

1 Answers1

0

Strikes me that this is a very complicated approach. I would expect that before long, the benefit of having shared security code will seem little justification for the pain that you will go through having the code-bases of two essentially different applications intertwined like this.

A better approach might be to separate the applications and develop a single sign-in component for both. This could either manage its own database, if you want users to have just one account for both applications, or it could use each application's database (assuming they have separate ones) if each is required to manage it's own user accounts. There are plenty of Membership components available to provide the foundation for this type of feature (ASP.NET MembershipProvider and Simple Membership, to name but two).

If you want both applications to run under the same domain in a production environment, simply deploy them to separate virtual directories. You will end up with a url scheme similar to using Areas.

Paul Taylor
  • 5,651
  • 5
  • 44
  • 68