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.
I tried this and Visual Studio 2010 happily published it anyway!
I thought it was too good to be true 😉
This solution seems simple, doomed to work. So I tried it with Visual Studio 2008 on a C# project. Unfortunately, it did not work and — sorry, I could not figure out why it didn’t.
The example in this article is ALMOST correct. The correct code to add to your project file is as follows (note the name of the variable is "DebugSymbols", not "DefineDebug" as stated in the article):
<!– The following makes sure we don’t try to publish a configuration that defines the DEBUG constant –>
<Error Condition="’$(DebugSymbols)’ == ‘true’" Text="You attempted to publish a configuration that defines the DEBUG constant!" />
Pingback: clickOnce publishing | whitecapetech
Thanks! DefineDebug worked for me.
i have the same issue, and both constants did not work for me (DefineDebug , DebugSymbols). please help
@farouk I updated the post with an example of using the names of the build configurations that you don’t want ClickOnce published. You should be able to easily adapt it to your situation.