Web Application Structure and Deployment

Question

Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time. I am currently researching them so that we can hopefully improve our deployment process.

We have a base web site that is shared and common between different clients, and then we extend that with client-specific functionality in client Web Site Projects. The client projects extend base, and therefore rely on its contents. To build the full product, we first deploy the base web site, and then overlay it with the content from the client project.

In looking at converting to Web Application Projects in Visual Studio, we were hoping to be able to create the base project, then create client projects and set up references to base. This structure seems to work OK, but when we are attempting to deploy the application from the client project using MSDeploy, only the dll from the base web site is being published. This is fine for some things, referencing the compiled code is useful, but there are other items like images, js pages, htm, etc that is still source that is required for the client application to function. We need more than the compiled code from our base web site.

That all being said, I can think of a few options here:

1. Continue to deploy in 2 steps. First the base web site, then the client web site to build the full product.
2. Modify the deployment process to copy the required source files from the base project
3. Re-architect our model to support this base-client relationship in a different manner. Not quite sure how this would work, and would be the least-viable option.
4. ??

Is there a different option that I am missing? Am I doing something wrong with the way I am setting up my projects? Is there more to making a Web Application reference another Web Application beyond sharing compiled code? If that's the case, why wouldn't you just use a shared class library? Or maybe I am missing something with the MS Deploy process?

I am open to suggestions here as I feel like I am missing something. I don't think our model for our web applications is too unique.

Update: The dual-deploy process does work, but feels a little kludgey. Any other input?

Sarsaparilla

BTW, yes, your model is unusual. But run away from web site "projects" in any case. They are unique, and not in a good way. – Freckle

Ya we have known for awhile that Web Site projects are.. umm, "special" in a number of ways. Its just hard at times to fix something that isn't broken. What makes our structure so unique? Another conceivable option is to have every project contain the full source of the application and set up some kind of source branching. We've done that before though, and it becomes very difficult to maintain changes. – Sarsaparilla

I haven't thought of using branching in this scenario before, but FYI, the branching in TFS 2010 is a lot easier to use than in the past. It's worth a look. I also recommend that you carefully separate and isolate the client-specific parts of your application from the common parts. Create specific extensibility and customization points within the app. That will make it easier to see how best to deploy this. There are also fun tricks you can play with MSDEPLOY. See amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/… – Freckle

Well part of what makes our product unique is that clients can have pages that are unique and not included in our base web site at all. So beyond extending the existing application, it actually supplements it. Thats where I am getting confused with your suggestion of extensibility points where we have unique content. – Sarsaparilla

did you read about aspnet_merge.exe msdn.microsoft.com/en-us/library/aa479044.aspx – Prehistoric

Answer 1

By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.

If am right you can Add this WebResource in your base project then go through the below link.

http://support.microsoft.com/kb/910442

Like this way, most of the third party tools will access their CSS and JS files.

Try this. Hope it will help.

Elwoodelwyn

Answer 2

How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.

Boozer

Answer 3

If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).

So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).

I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.

Gladiatorial

Answer 4

I would carefully analyze what you are sharing between projects and how you share them.

If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.

If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.

On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.

Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders). I would suggest sticking to the 2 step deployment process with Web site projects.

I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.

Lastly, this is an old question. Please share if you have already implemented a successful strategy.

Alvie