Part 1 of 3: Creating sub-projects in IIS with Web Application Projects

Part 1 of 3: Creating sub-projects in IIS with Web Application Projects

Rate This
  • Comments 60

First a quick intro, since this my first post on the team blog.  My name is Omar Khan.  I'm the group program manager for the web development tools team.  I manage the program management team that helps design the web tools inside of Visual Studio.

This post is one of a three part series that describes how to factor development of a single large ASP.NET application into multiple projects inside of Visual Studio 2005 using the Web Application Projects add-in.

Part 1 of 3: In this post, I’ll describe the basics on how to setup a sub-project structure using IIS. 

Part 2 of 3: The next post will describe intricacies with master pages, user controls, and project references when using a sub-project structure.

Part 3 of 3: The final part to the series will describe how to use the same technique but with the built-in development server in Visual Studio 2005.

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. 

Setting up the root project using IIS

The first thing I want to show is a step-by-step on how to setup a sub-project project structure based on developing on IIS. 

Setting up a sub-project structure in Visual Studio 2005 is fairly straightforward.  If one has done it in Visual Studio 2003, the process described below should be very familiar. 

Here is a step-by-step walkthrough of how to setup sub-projects using Visual Studio 2005 and the Web Application Projects add-in.

1)    Download and install “Web Application Projects” add-in.  The add-in can be installed from the following location:

2)    Create the root project.  The first thing we want to do is create a new Web Application project that will represent the root of the application in IIS.  To do this select File > New Project.  Choose the ASP.NET Web Application item, and type in a name and location for the root project.  In this example we’ll call the root project MyLargeWebApp.  Make sure the “Create directory for solution” checkbox is unchecked.  One can create the “Root” project in a folder in the “inetpub/wwwroot” directory for IIS, or in any other location where you wish to create the virtual root for your app.  In this example, we’ll use a location underneath “inetpub/wwwroot”. 



3)    The next step is to map the MyLargeWebApp project in IIS using the “Web” tab in project properties.  To do this, right-click on the root node of the project and select “Properties”.  Click the “Web” tab on the page that is launched, and select the “Use IIS Web Server” option.


4)    Next you need to create a virtual directory mapping in IIS to point to the location where your root project exists.  To do this click the “Create Virtual Directory” button on the same Properties page.


5)    You can now test your root project, by adding some content to default.aspx and selecting F5.  This should run launch IE and the default.aspx page will get served from IIS.


Creating sub-projects under a root project

Once the root project is up and running fine, the next step is to create a sub-project and set it up so it builds and runs as part of the same ASP.NET application represented by the root project.  The following steps describe how to do this:

1)    The first thing you need to do is add a new Web Application project to the same solution.  Make sure the MyLargeWebApp solution/project is already open in the solution explorer.  To add a new project to the solution, select “File > Add > New Project”.  Select “ASP.NET Web Application” as the template.  Then type in a name for the sub-project (“SubProject1” in this example), and set it to the location of the folder where the root project is (c:\inetpub\wwwroot\MyLargeWebApp in this example).




2)    You should now have two projects in your solution which represent a single ASP.NET application.  To verify this, go to the IIS management console by selecting Start > Run > inetmgr in Windows.  In the management console, you should see a “SubProject1” folder under single IIS web application called “MyLargeWebApp”.



3)    To get the sub project building and running a few more steps are required in Visual Studio.  The first thing you should do is delete the web.config file in the sub-project.


4)    Next you need to adjust a few of the properties for the sub-project.  Right click on the sub-project’s node in solution explorer and select “Properties”.  Under the “Compile” page change the “Build output path” to “..\bin\”.




5)    Finally in the sub-project’s properties, under the “Web” page, select the “Use IIS Web Server” option and change the “Project URL” setting to “http://localhost/MyLargeWebApp/SubProject1”.  Also check the "Overwrite application root URL" and provide the URL to the root project, which in this case is "http://localhost/MyLargeWebApp/".  Do not click the “Create Virtual Directory” button in the sub-project’s setting as you don’t want to create another application root in IIS at the sub-projects folder.


6)    Once you’ve updated these properties for the sub-project, the sub-project should be ready to go.  Add some content to the default.aspx page in the sub-project and press F5.  This should build the sub-project, deploy its DLL to the \bin of the root project, and then run the page from the sub-project.  If you select the root-project and “Show All Files” in the solution explorer, you will see in its \bin folder that there are two deployed assemblies, one for the root project (MyLargeWebApp.dll) and one for the sub-project (SubProject1.dll).




This wraps up my first post on sub-projects.  Hopefully it provides a quick introduction on how to setup a sub-project structure using the Web Application Project add-in for Visual Studio 2005. 

As mentioned in the beginning of the post, sub-projects are a good way to partition a single large ASP.NET application into several Visual Studio projects so you get the benefits of isolated development and deployment.

Looking forward to hear from you about this post, and I'll update with Part 2 hopefully next week.


Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post
  • Hello Omar,

    On the root project, is there a way for the root project to self discover the sub-project.

    I guess the goal is to have a root project but not to have a reference to the sub projects.  

    The root project would look in a sub directory under the root project for dll's and automatically load them.


  • I was doing a similar approach with 2003.  An additional benefit for changing the output path is to avoid referencing new WAP projects after initial deployment.  If you were to reference the sub project from the root and release it, then later add another sub project, you would have to alter the root project again.  That definitely isn't a desired scenario in a large application where the purpose of a sub project is to segregate workload or minimize code affected in a single project release.
  • thanks it really helped
  • Hi all,
    I have splitted the project. Very Nice.
    I also splitted the user web controls as a project.  Now i cant use the controls in other sub projects.
  • Thanks for this information, really useful. Keep up the good work

    Steve C.
  • Hello New bee,

    Please see part 2 of this post for information about user controls across projects.

  • In our model, we can't reference the sub-project in the main project because it isn't known at design time. I've found that if you are dynamically loading controls, you HAVE to have the assembly in the MAIN /bin/ path and not in a private path. Is there any workaround to this?
  • Why we have 2 diffrent attributes in @Page for WAP and WSP. WSP used CodeFile where WAP use CodeBehind. Is there any functional requirement behind this? Can't both be same?
  • I got the answer my self. WAP and WSP can't share same attribute. If they share, it will result in runtime error becuase WSP will create assembly for code, which is already included in another assembly ( Generated as WAP ).

    Try to get single Attribute will require to have a big change in ASP.NET compiler it self.

    Thanks for the thread, it helped me to get some answers.
  • Omar Khan, GPM for the VS 2005 web tools has posted a lengthy example of how to create a partitioned
  • OK - how do I get around " The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. "?
  • The value "..\bin\" can not be saved and restored to "bin\" after pressing "Apply". Any idea why this happened?

  • As per Amit:

    ...We have close to 140+ web application projects ....

    If I take this approach of sub-projects and if I make a change in a code-behind of aspx pages in one of my sub-projects will it re-compile the entire project or can I re-compile just  the sub-project?



    I have the same question. If I make changes to one project will I have to re-compile the whole solution including all the sub-projects?


  • This is the Part 3 of a 3 part series on using sub-projects with the Web Application Projects add-in

  • Hello Rob,

    Yes, if you make a change to a sub-project, the other projects will not get compiled.  Breaking a very large app into smaller compilation units is one benefit of this approach.

Page 3 of 4 (60 items) 1234