Home/ Questions/Q 220571
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T18:57:06+00:00

I’d be interested to hear how people handle conditional markup, specifically in their masterpages

  • 0

I’d be interested to hear how people handle conditional markup, specifically in their masterpages between release and debug builds.

The particular scenario this is applicable to is handling concatenated js and css files. I’m currently using the .Net port of YUI compress to produce a single site.css and site.js from a large collection of separate files.

One thought that occurred to me was to place the js and css include section in a user control or collection of panels and conditionally display the <link> and <script> markup based on the Debug or Release state of the assembly. Something along the lines of:

#if DEBUG
    pnlDebugIncludes.visible = true
#else
    pnlReleaseIncludes.visible = true       
#endif

The panel is really not very nice semantically – wrapping <script> tags in a <div> is a bit gross; there must be a better approach. I would also think that a block level element like a <div> within <head> would be invalid html.

Another idea was this could possibly be handled using web.config section replacements, but I’m not sure how I would go about doing that.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There’s a decent discussion on changes in web.config settings here:

    Using different Web.config in development and production environment

    Note: you are asking a different question but I suggest taking a look at that anyway because it’s an awesome collection of suggestions of how to switch between live and debug settings and all the answers (IMO) have some value – not just the highest voted/accepted answer.

    Personally, I use a method explained here and think it is the most flexible and is applicable to all types of configuration changes as it is file based but allows them to be auto-swapped based on solution configurations:

    http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx

    Essentially, you run a pre-build event to swap out the web config with another one on disc with the solution configuration name appended to the filename. For example, I have web.config.release, web.config.debug and even a web.config.neilathome.

    I then use the exact same methods for conditional bits of code by creating partial classes and putting the stuff that changes between my solution configurations in their own files. For example, I have sync_timersettings.cs which is a partial class containing a few constants that define how often my update code calls a web-service. Or you could just put all your settings in an app.settings file and do it that way.

    I find it a very flexible solution, it lets me swap out chunks of javascript and css and as long as you take the time to put things that change between configurations in their own files, you can probably go to a state where you can be debugging in the debug solution configuration and then switch to release and deploy in one click.

    One further note:

    #if DEBUG
    pnlDebugIncludes.visible = true
#else
    pnlReleaseIncludes.visible = true       
#endif

    Responses to comments:

    This is only useful if you have a debug solution configuration and one other one which is your live deployment. It won’t work when you (like me) have a staging, release and neilonhislaptop solution configuration as the DEBUG symbol is only set when you have debugging enabled. The work-around is to go to the properties page of your web application and in the build tab, put a conditional symbol in for each of your build configurations. IE, set you build configuration to release and put ‘release’ in the conditional symbol box in that tab. Then do the same for different build configurations, the conditional symbol box in there will automatically change depending on your build configuration. #if conditional compile directives will work as expected then.

    Bayard asked for more information on how to use this to change mark-up between configurations. Well you could use to to swap out the entire .aspx page – have home.aspx.release and home.aspx.debug but it would mean you had to repeat a lot of mark-up in each file. My solution is to add a partial class to my application. For example, my ‘ViewImage’ page has the following class definition in it:

    public partial class ViewImage : System.Web.UI.Page

    ..so I created some class files with the same signature and named them ‘ViewImage_titleset.cs.debug’ and ‘ViewImage_titleset.cs.staging’:

    namespace Website
{
    public partial class ViewImage : System.Web.UI.Page
    {
        public void SetTitle()
        {
            Page.Title = "Running in debug mode";
        }
    }
}

    and

    namespace Website
{
    public partial class ViewImage : System.Web.UI.Page
    {
        public void SetTitle()
        {
            Page.Title = "Running in staging mode";
        }
    }
}

    ..calling SetTitle in the page load event for ViewImage would change the title depending on which build configuration was in place. This will only work if you are altering the page programmatically.

    It’s better to use the conditional compilation method above for changing code like this and reserve the file-swap method for changing out non-code files such as images or web.configs. Just make sure you don’t set the alternative files to be deployed on publish.

    • 0