9

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.

Bayard Randel
  • 9,930
  • 3
  • 42
  • 46

3 Answers3

9

I just tried this in my Master page in my ASP.NET MVC project and it worked. If in DEBUG mode I use the development version of jQuery and if not in DEBUG mode, I use the minified version of jQuery:

<head runat="server">
<% #if DEBUG %>
    <script type="text/javascript" src="<%= Url.Content("~/Scripts/jquery.js") %>"></script>
<% #else %>
    <script type="text/javascript" src="<%= Url.Content("~/Scripts/jquery.min.js") %>"></script>
<% #endif %>
</head>
Praveen Angyan
  • 7,227
  • 29
  • 34
5

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.

Community
  • 1
  • 1
Neil Trodden
  • 4,724
  • 6
  • 35
  • 55
  • 1
    I use Development, Test and Production solution configurations as well. As long as you define a conditional compilation symbol for each configuration, you should be able to do something like this: #if Development pnlDevelopmentIncludes.visible = true #endif #if Test pnlTestIncludes.visible = true #endif – Praveen Angyan May 22 '09 at 00:02
  • Neil this certainly seems like the right approach to take. Could you please expand on how you're using the partial classes to change your markup between different builds? – Bayard Randel May 22 '09 at 00:07
  • You may want to change your naming convention to be more like web.debub.config or web.release.config. By default IIS will not serve files ending in .config, so it may be better. – Sayed Ibrahim Hashimi May 22 '09 at 04:51
  • Praveen, that seemed obvious to me initially but the solution configurations cannot be detected using conditional statements as they do not set a symbol. You could edit the properties of your web application and add a release/staging/testing conditional compilation symbol in the build tab - you can set these per build configuration too. I'll add something in the answer. Bayard, I will edit and add a little to my answer to demonstrate. Sayed, good point but I set the build action for those files to 'None' and set them to 'Do Not Copy'. What you say ensures VS handles the file properly. – Neil Trodden May 22 '09 at 20:08
1

With regard to the JS files what I do is use Web Deployment Projects to pre-compile the web app. After the build completes if the configuration is Release then I minify the JS files and replace the files in the output directory. This is all done with MSBuild, beacuse Web Deployment Projects are MSBuild files.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178