You’ve all had it happen. You just put the finishing touches on your project and you hit the Publish button. The files are automatically copied to the file server and users start get the updates right away. You double-check the publish and then you realize that you published the DEBUG version with all your program stops, disabled error checking, and wide open access to all program features!
Custom MSBuild targets to the rescue! Just add the following to your project file and it will prevent a publish when the DEBUG constant is defined. Place it at the bottom of your project file right before the [generic][/generic] tag. (For an example of editing your project file, see my post on Obfuscating a ClickOnce Publish.)
By the way, the DEBUG constant is the constant that you use in your code as a compiler constant, for example [raw]#If DEBUG Then[/raw]. It can be found in the ‘Compile’ tab under ‘My Project’ by clicking ‘Advanced Compile Options…’:
Edit: It looks like some people have had issues with the way I got things working. I was using a VB.Net forms application in VS2005 (and I think I tested in 2008 as well). The key is to find which constant works best for your situation. Drew Mcpherson says that [generic]DebugSymbols[/generic] worked for him rather than [generic]DefineDebug[/generic].
If you want even more control, another way of choosing a compiler constant is to define your own. You’ll notice that below the “Define DEBUG Constant” box there is a textbox for defining custom constants. If, for example, you have three configurations, such as [generic]Debug[/generic], [generic]Release[/generic], and [generic]Publish[/generic], you could define a constant on the [generic]Publish[/generic] configuration to prevent any other from allowing a publish.
Edit 2: Another strategy altogether is to disallow publish for all build configurations except for the one you intend to distribute. This is also helpful if you have multiple deployment strategies such as ClickOnce for internal users and a Windows-installer for external users. In this case, publishing the wrong version could have dire consequences.
Below is a sample of what I used in a multi-deployment scenario. Note that I’m calling out the actual names of the build configurations.