How Do You Organize Your ASP.NET MVC 3 Applications? [duplicate]

Question

The one thing that I am having a hard time figuring out with developing an extensible application platform in ASP.NET MVC 3 is how to modularize everything into an easy to update and distributable form.

The ideal solution I think would be to be able to pack everything up is some compressed file like zip/rar/tar (but still having the source code and views compiled in a dll file) and build into the the core platform a way to allow a non-technical select the compressed file and install it automatically.

The only thing I have manage to compile in separate a .dll file are the controllers, classes, and razor views (with help from a blog post). Now this issue with this is that the .dll projects doesn't have access to the shared views from the main project (or I can't find a want to access them) and I have to copy the shared views from the main project into all the separate projects holding each module (not to mention the configuration files I also have to copy).

If I make a change to the shared views that other module are using (that other people are maintaining), they would have to update their module to copy in the new version of the shared views and this is just a solution that doesn't seem very manageable.

I am looking to see how other people setup large extensible C# ASP.NET MVC 3 applications.

EDIT - New Ideal Solution

I was wrong in my initial ideal solution. As pointed out by Tungano, my initial ideal solution would kill any type of caching the server/browser would be able to do on css, javascript, images, etc.

My new ideal solution is the whole compressed file installation idea. You can have the compiled dll with the source code and views in it along will all the separate css, javascript, images, etc. files in the compressed file. Then through the application itself you select the compressed file and the application will handle placing all the files in the correct location. Any links on how to create this type of functionality would be great.

Answer 1

Serving js, css and other static stuff from a DLL is asking for a performance disaster if your site gets a lot of traffic. A regular MVC project would let IIS handle them which would yield a lot more efficient use of caching on both the client and the server.

Your primary reason for wrapping it all into a dll seems to be purely for deployment comfort. A dll is just a poor form of packaging imho. The difference between unzipping a file and just copying a single dll is so small, I don't see enough value in complicating the development process over it.

I typically see my MVC apps as the extension itself and not as something that needs to be extensible. The MVC application is mostly configuration, glue and application layer. The bulk of my code is isolated in a domain model assembly.

Added for new solution:

You probably make it easier on yourself if you let the updating be done by a small separate service application. That way you might have less problems updating stuff, potentially hitting assemblies in which the update service itself resides etc.

Perhaps a small virtual application will do. This may also make it easier to deal with small web farm scenarios and/or placing temporary "site is being updated" notices etc. Roll back is probably easier too if you leave the previous version of your site intact while you switch over.

Visual Studio projects have some packaging and deployment options which may help you get started. They are basically zip-files with some added meta data. You can use them to deploy your apps using the Web Deploy engine that you can install on a web server (this might save you from writing this service yourself).

(don't have web deploy experience yet, so can't tell you more then that)

Answer 2

The easiest deployment would be to just zip the location of the website, and give them instructions on how to map a virtual directory to it in each version of IIS that you support. When you provide updates to the software, have them back up the current install location, by copying the folder, before copying the updates over the original. That way if there is any problems, they can rollback to the previous version. Its easy, it works, and you aren't forcing your more advanced customers into doing things a certain way.

Expecting users to know how to follow directions, such as starting and stopping the web server, when installing or updating a website, when they are running a website, is not an unreasonable request. It will save you lots of time in software maintenance. You won't receive many support calls if your instructions are good. Even if you do receive support calls, fixing their problem is quick and predictable, because you are only dealing with a basic virtual directory and a tree of files, not some custom installation.

Update:

Giving write permissions to a directory with execute permissions, which is what would we be required to have them upload the zip file from inside the application, is a security breach waiting to happen.

If you had some sort of packaged solution (especially if it was installed through the web application), you would have a whole lot of different scenarios to troubleshoot (e.g. permissions, firewall, bugs in the install process, etc.)