Large web application architecture?

Hi, I am working with a company developing a web application using VS2005 and
the web application project (WAP). We started out with a single WAP and a class
library. Now this has grown out of hand and we have several class libraries that
we work with, but only one WAP. We have tough requirements on uptime and we need
to be quick with new feature releases. I am asking anyone who have some
experience of this. How do you manage this? Do you all deploy the entire
application every time or do you divide it in many smaller web applications, one
for each subsite?

I have pondered this for a while and come up with a possible scenario: What do
you think about dividing this kind of application in one layout project,
containing masterpages and custom web controls and one for each subsite which
uses things from the common design project. Has anyone tried this? We need to be
able to quickly update a small portion of the site and since all code goes in
one assembly this is impossible as far as I can see. 

Thanks for any responses, 
Richard

I'm not sure I get what you are talking about. I have several sites I work on
where I've continally added new class library projects to the solution with
custom controls and all kinds of functionality. With a WAP project, all I need
to do is FTP the new pages and the new assemblies into the /bin folder and I'm
good to go. 

Keep it simple.

Yea, the class library projects are no problem, I can update those at any time
without any problems. The problem is when we are in a middle of development and
someone need a new feature deployed quickly. We might not want to, or be able to
post the feature in our site since the WAP assembly might have changes which
would mean we had to update the entire site and all database changes. I would
like to be able to post just a part of the WAP assembly, thats why I was talking
about dividing it up in multiple projects.

hello,

it is possible to configure "sub web application projects" for your
solution. unfortunately, this is quite buggy if you use features like custom
server controls, custom expression builders, master pages, ...

 install tutorial:
http://blogs.msdn.com/webdevtools/archive/2006/07/01/part-1-of-3-creating-sub-pr
ojects-in-iis-with-web-application-projects.aspx

we are using this solution in a big web project, but it is really annoying. 

some problems, I have experienced until now:

you can't choose a master page from the parent project via designer. you have to
write this in your aspx code by hand. you also don't have designer support for
master pages from parent projects.
We wrote some custom file templates, where the master page is already included
to get around this.

if you use custom server controls, sub projects don't recognize your control
prefix because it is just specified in the web.config of the parent project. it
doesn't even help if you register the controls on every aspx page.
if you use custom server controls, automatic generation of .designer.cs files
fails because the control prefix is unknown (see previous point)
you have to declare all (even the normal asp controls) your used controls by
hand in the designer.cs file as soon as you include one custom user control.

if you use custom expression builders (example: <asp:Button
id="btn" runat="server" Text="<%$ Expr : My Text
%>" />, you get compile warnings, because again it is just registered
in the web.config of your parent project.
you don't have any kind of support for "~/" url writing in your
designer. It works, if you run the project but in aspx files, every use of this
generates warnings, because the compiler doesn't find the files.
... 


it works and we are using this despite all this %&§"" errors,
because you get separete DLLs...


I hope, all this errors get fixed in near future. I've read a post by Scott
Guthrie where he says that the VS team hadn't found the time to fix this for
VS2008 but they want to fix it someday...

best regards,
christian

Thanks alot, that's right on the money what I was looking for. For now we are
looking into our publishing process instead to see if we can do more there to
ease the deployment. But I will look in to that solution, it seems promising
despite the bugs you are talking about. We rarely use the designer mode while
developing anyway. 

I found another possible solution too. That's to put the masterpage in an
virtual filesystem under an assembly or in a database and provision it from
there. Piyush Shah provides a post about that here:
http://blogs.msdn.com/shahpiyush/archive/2007/03/09/Sharing-Master-Pages-amongst
-Applications-by-Embedding-it-in-a-Dll_2E00_.aspx

Your solution seems easier though. Unfortunatly we use VS2008, do you have a
link to SG's post about that?

 Thanks for your response,
Richard