3

I have been working on ASP.NET MVC for a while and loving it so far. But I am hitting a wall now.

I am working on a new intranet site, where I will have to host many projects, ranging from couple of pages to full blown applications. I have been using Areas to differentiate between the projects. It's all good so far.

Now, the solution is too big and every simple change I need to compile the whole projects which consists of all the areas (multiple projects). I am always afraid of making changes to live once I compile and upload the dll.

Is there anyway that I can hold multiple projects sharing same layout but to compile each projects into separate dll?

Thanks in advance

EDIT

Thanks guys, I followed Portable Areas as an ASP.NET MVC Project and he seems to have explained things much easier in a step by step to get started.

Siva Kandaraj
  • 824
  • 7
  • 15

1 Answers1

2

Have you considered using Portable Areas feature in the MVCContrib? - read a post about it here

Also read the response from Eilon in another question Multiproject areas in ASP.Net MVC 3

If the portable area solution won't work for you then it's probably time for a refactor/restructure of your single web project into separate web projects. As it is an intranet site you'll probably want to setup some sub-domains to allow you run separate websites under the one domain.

Eg.

www.yourdomain.com

admin.yourdomain.com

calendar.yourdomain.com

etc.

This way you can segregate your functionality and update different areas of the intranet without affecting others. You may of course need to look into single sign-on across your sub-domains depending on your site.

I would normally extract all common functionality into a core project (class library) which may be used by all of the web projects, and keep each your web projects as lightweight as possible. Then you can create separate solutions for different web projects or groups of web projects.

Also consider looking into continuous integration/build server so that you can easily check if a change you make in one project is affecting other projects that may not be in your current solution.

Community
  • 1
  • 1
brodie
  • 5,354
  • 4
  • 33
  • 28
  • 1
    As an alternative, on one project we actually modularized it in such a way that each business function was completely self-contained in its own module. Controllers, views, data access, etc. This made deployment of any particular feature as simple as dropping an assembly in the bin folder. So yeah, something in the "portable areas" concept is definitely something to consider. – GalacticCowboy Jul 28 '11 at 23:49
  • (It was written in MVC 1.0, so long before Areas or Portable Areas ever came along...) – GalacticCowboy Jul 28 '11 at 23:50
  • @GalaticCowboy did you use something like MEF or another IoC framework with scanning to pickup on the modules ... or did you roll your own? – brodie Jul 28 '11 at 23:53
  • Rolled our own. MVC will use controllers from any assembly, so most of the "goo" was in wiring up views, etc. We used a `VirtualPathProvider` to handle that - loading the views as resources and passing them to the MVC render pipeline. Our navigation was a separate module that the other modules basically told where they wanted to plug in, and it built the site map. – GalacticCowboy Jul 29 '11 at 00:18
  • We also built a custom route loader so we could define our routes in an XML file and the app would update its route table at launch or whenever the file changed. However, we ended up really only using that for 2 "core" modules, so we could have just as easily left it in Global.asax. – GalacticCowboy Jul 29 '11 at 00:20