WCSF deploying aspx pages in modules ?

Topics: Web Client Software Factory
Aug 1, 2007 at 3:29 PM
I'm evaluating WCSF for a new product as I'm looking for a way to separate out core product modules and customer specific modules.

Each customer module could contain presentation, business and data access layers, for example a set of ASPX pages which can access the core product services and/or its own services.

The main reasons I want separation between the modules are:
- source control, separate projects for the core product and each customer
- deployment, I only want to deploy the core product modules and customer modules for that customer, i.e a customer shouldn't get modules for other customers.

WCSF appears to solve most of these problems except that the ASPX pages for each module must be in the main (product) web application. This means that over time, it would build up pages for all customers.

Is there any workaround to this problem in the current (Jun) release of WCSF ?

Are there any plans to implement this in the near future (next few months ) ?

Thanks,
CJB
Aug 1, 2007 at 4:47 PM
You can always exclude the module from your main web app and rebuild. The nice thing is, you can still access the logic in your libraries (providing you leave them) and you won't have the actual aspx pages.
Aug 1, 2007 at 6:53 PM
Hi! To do what Stormbringer mentioned, you have to comment/remove the lines in your Website’s Web.config inside <compositeWeb><modules>.
If you want further isolation between your modules, you can also create your business module’s websites as sub-Web Application Projects.

Here’s a quote from Creating sub-projects in IIS with Web Application Projects blog post that may help:


Why use sub-projects?
With very large web applications, such as those that contain thousands of files, using a sub-project structure in Visual Studio provides several benefits.
At development time, it provides a clean isolation between different parts of the application. This enables different developers to own their own projects within a single web application, and allows them to make changes without affecting code that is in a different project.

As well, using sub-projects provides a clean way to compartmentalize functionality so different parts of the application can be developed in isolation from others. The compartmentalization also enables the ability to deploy the various sub-projects to production independently from each other thus providing more flexibility around incremental updates to one part of the application without affecting other parts.


Hope it helps!

Luciano G. Panaro
http://staff.southworks.net/lpanaro
Aug 2, 2007 at 3:53 PM
Thanks to both stormbringer and Luciano for the help, after a good degree of trouble I managed to get your suggestion working.

The link above http://blogs.msdn.com/webdevtools/archive/2006/07/01/652986.aspx did allow me to create the sub-project, but then I ran into problems getting the Web Setup Project to install the sub-project under the main projects virtual directory (I wanted to have separate installers, one for the main 'product' app and the other for customer specific projects).

For anyone who is interested here are the changes I had to make to the sub-project Web Setup Project:
  1. Open the File System View and select the 'Web Application Folder' and make the following changes to its properties:
    1. Set 'IsApplication' to false, as it should already be a virtual directory from the main application install.
    2. Set 'VirtualDirectory' to the name of name of the virtual directory of the main application.
  2. Right click on the 'Web Application Folder' and select Add>Web Folder
  3. Name the new web-folder with the same name as the sub-project
  4. Move any installation files (Content Files etc) from the 'Web Application Folder' to the sub-project folder
  5. Create a new web-folder under the sub-projected called 'bin'
  6. Move all installation files (Primary Output etc) from the 'Web Application Folder\bin' folder to the new bin folder.


I haven't verified this from scratch on a clean machine, so there may be some extra steps (like setting 'IsApplication' to false) that aren't really necessary.

Cheers,
CJB.
Aug 5, 2007 at 8:39 AM
I see you have solved your issue, but maybe my solution just might help you or others out in the future. My goal with WCSF was to be able to share common web modules across many of my clients' websites without having to copy/paste/reconfigure those common modules for each client. The idea of subprojects was almost perfect, as they are aimed at compartmentalizing websites for both development and deployment. I figured with a little help, they could also solve my reusability goals as well. Originally I thought virtual directories was the answer, as it allowed me to store my common modules in a single repository, and link them to each site via IIS. This may be the solution for most, but I wanted to use the Personal Web Server for development instead of IIS (At the time i was on XP, and liked developing a site on the root level, rather than in a virtual directory). Since personal web server doesn't support the concept of virtual directories, I had to come up with a workaround. That is when I thought about using Junctions. Junctions are folders that really just pointers to other folders. They are perfect for my scenario, because the personal web server sees a regular folder with files in it, not knowing those files are really in a totally different directory. So in each of my clients' sites, I just create an empty folder on the root, and then "wire" this folder, via junctions, to the root of the common web module i wish to include. Everything works like the files were actually located in the clients directory structure.

Up until vista, there was very little documentation and support for using Junctions. In XP, the easiest way to create a junction is to use the junction tool by sysinternals. Microsoft makes one too that is included in the windows server 2003 admin kit (correct name?), but it was a pain for me to find. In vista, which i am running now, there is a command line tool called mklink that is included. Bring up a command window, and type "mklink ?" to see its usage.

Hope this helps,
Sam