I have an app that applies to two different groups and each has a different database.


_Layouts/dept1/SomePage.aspx (uses dept1db)
_Layouts/dept2/SomePage.aspx (uses dept2db)

I would like to have a single project is deployed to each location via powershell scripting, but I think the way _Layouts is mapped would not work.

The only other way I know to handle this is to maintain the dept2/SomePage.aspx as a copy of the same aspx file. I can probably automate this somewhat using a post-build event.

Is there a cleaner way to handle this? If I use web parts this becomes a non-issue but I prefer aspx.


To reduce code duplication/syncing, I decided to instead use a single folder like "depts" instead of dept1, dept2 etc and tried the following:

  1. Tried adding a query string like _Layouts/depts/SomePage.aspx?dept=dept1 in order to target the correct database. This unfortunately is incompatible with a web launching tool we use for end users because it also adds account info to the query string and I ended up with a broken URL like: _Layouts/depts/SomePage.aspx?dept=dept1?acct=1234. Basically I learned that this dept info needs to be in the path part of the URL.

  2. Tried adding routing to the end like _Layouts/depts/SomePage.aspx/dept1 but this broke webmethods.

  3. Tried this project structure:

    ControlTemplates/depts/SomePage.ascx - User control with code-behind relating to controls on the page. I pasted in all the HTML/js that was previously in SomePage.aspx

    Layouts/depts/SomePage.cs - The code-behind class that was previously in SomePage.aspx.cs. It inherits from LayoutsPageBase. Since it can't cleanly reference controls StepRate.ascx, only WebMethods are here.

    Layouts/depts/SomePageDept1.aspx - inherits from SomePage.cs and includes SomePage.ascx

    Layouts/depts/SomePageDept2.aspx - inherits from SomePage.cs and includes SomePage.ascx

    The code-behind SomePage.cs uses the current URL to determine the dept and choose the proper database.

I am currently evaluating option #3.

The pros:

  • Minimal duplication to deploy to multiple departments.
  • A single folder and solution/package.
  • An application page aspx so I get the ease of WebMethods

The cons:

  • Somewhat unintuitive project structure.
  • Possible deal breaker. Since the shared markup is in the ascx, I'm not sure how to use asp controls (fileupload, etc) via the aspx code-behind. My current project is very js heavy so this has not come up yet.. UPDATE: I now retain the ascx's code-behind to deal with asp controls on the page (fileupload, etc). The WebMethod stuff remains in the inherited code-behind class for the two dept aspx files.

It almost seems like too much fuss just for code reuse. If I switch to a Web Part project, reuse would be a non-issue but I would acquire these problems:


I decided to scrap all that complexity and just use a redirect.

The main page is SomePage.aspx and requires "dept" in query string

dept1.aspx and dep2.aspx contain something like this code to add the dept query string value and pass forward the Acct value if provided:

public void Page_Load(object sender, EventArgs e)
    string toPage = "SomePage.aspx"; // leave blank for Default.aspx
    string dept = "dep1";
    if (Request.QueryString["Acct"] != null)
        Response.Redirect(String.Format("{0}?dept={1}&Acct={2}", toPage, dept, Request.QueryString["Acct"]));
        Response.Redirect(String.Format("{0}?dept={1}", toPage, dept));

This allows me to use only the Acct query string (limitation of our dynamic link GUI) and maintain a single code base for multiple depts/databases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.