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:
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.
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:
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:
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.
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.
关于JS文件，我所做的是使用 Web 部署项目，用于预编译 Web 应用程序。 构建完成后，如果配置为 Release，那么我会缩小 JS 文件并替换输出目录中的文件。 这一切都是通过 MSBuild 完成的，因为 Web 部署项目是 MSBuild 文件。
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.
发布评论
评论（3）
我刚刚在 ASP.NET MVC 项目的母版页中尝试了这一点，它成功了。 如果在 DEBUG 模式下我使用 jQuery 的开发版本，如果不在 DEBUG 模式下，我使用 jQuery 的缩小版本：
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:
这里有一个关于 web.config 设置更改的不错的讨论：
使用开发和生产环境中的 Web.config 不同
注意：您问的是一个不同的问题，但我建议无论如何都看一下这个问题，因为它是关于如何在实时和调试设置之间切换以及所有答案的很棒的建议集合（IMO）有一定的价值 - 不仅仅是最高投票/接受的答案。
就我个人而言，我使用此处解释的方法，并认为它是最灵活的，适用于所有类型的配置更改，因为它是基于文件的，但允许它们根据解决方案配置自动交换：
< 本质上，
您运行一个预构建事件，用于将 Web 配置替换为光盘上的另一个配置，并将解决方案配置名称附加到文件名。 例如，我有 web.config.release、web.config.debug 甚至 web.config.neilathome。
然后，我通过创建部分类并将解决方案配置之间发生变化的内容放入它们自己的文件中，对条件代码位使用完全相同的方法。 例如，我有sync_timersettings.cs，它是一个部分类，其中包含一些常量，这些常量定义我的更新代码调用 Web 服务的频率。 或者，您可以将所有设置放入 app.settings 文件中，然后这样做。
我发现它是一个非常灵活的解决方案，它可以让我交换大量的 javascript 和 css，只要您花时间将配置之间发生变化的内容放入自己的文件中，您就可以进入可以调试的状态在调试解决方案配置中，然后一键切换到发布和部署。
进一步说明：
对评论的回复：
仅当您有调试解决方案配置和另一项是实时部署时，这才有用。 当您（像我一样）拥有暂存、发布和 neilonhislaptop 解决方案配置时，它将无法工作，因为只有在启用调试时才会设置 DEBUG 符号。 解决方法是转到 Web 应用程序的属性页面，然后在“构建”选项卡中为每个构建配置添加一个条件符号。 IE，将构建配置设置为发布并将“发布”放入该选项卡的条件符号框中。 然后对不同的构建配置执行相同的操作，其中的条件符号框将根据您的构建配置自动更改。 #if 条件编译指令将按预期工作。
Bayard 要求提供有关如何使用它来更改配置之间的标记的更多信息。 那么您可以使用来交换整个.aspx页面 - 有home.aspx.release和home.aspx.debug，但这意味着您必须在每个文件中重复大量标记。 我的解决方案是向我的应用程序添加一个部分类。 例如，我的“ViewImage”页面中有以下类定义：
..所以我创建了一些具有相同签名的类文件，并将它们命名为“ViewImage_titleset.cs.debug”和“ViewImage_titleset.cs.staging”：
和
..在 ViewImage 的页面加载事件中调用 SetTitle 将更改标题，具体取决于当前的构建配置。 仅当您以编程方式更改页面时，这才有效。
最好使用上面的条件编译方法来更改这样的代码，并保留文件交换方法来更改非代码文件，例如图像或 web.configs。 只需确保您没有设置要在发布时部署的替代文件即可。
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:
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:
..so I created some class files with the same signature and named them 'ViewImage_titleset.cs.debug' and 'ViewImage_titleset.cs.staging':
and
..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.
关于JS文件，我所做的是使用 Web 部署项目，用于预编译 Web 应用程序。 构建完成后，如果配置为 Release，那么我会缩小 JS 文件并替换输出目录中的文件。 这一切都是通过 MSBuild 完成的，因为 Web 部署项目是 MSBuild 文件。
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.