We Keep Coding

Removing the code with preprocessor in .net

I have .net C# application. In the application have two set of code for different client.
We were thinking of removing the part of code through preprocessor. Diabling the part with config file parameter is not an option for us.
We want simple setup like:
#define DEBUG
//....
#if DEBUG
Console.WriteLine("Debug version");
#endif
The only issue is, our part of code is distributed into multiple files and multiple projects in the solution.
So we want to define globally the preprocessor “DEBUG” at one place. Preferably in project property or something.
What is the best option for us?

Look for "Conditional Compilation Symbols" on the "Build" page of the project property dialog. You can set it per-build configuration.

Remove Log before release System.Diagnostics

To Log output I am using the following code.
System.Diagnostics.Debug.WriteLine("Hello");
Now, its always advisory to remove such logs before the app is submitted.
So, is that we have to remove such lines, before we submit it for release or its done implicitly.
Is there any another better way to log output in C#, which removes the logging to the console when its released. I see Log4Net is one of them.

All methods on the System.Diagnostics.Debug class have the ConditionalAttribute, so under most compilers they will not be compiled into a Release build (unless you define the DEBUG attribute in the release build). 1
This is certainly true for the compilers within Visual Studio.
Your second question about log4Net is actually the reverse, and something to be careful about if you do decide to start using log4Net - log4Net debug calls are included within debug builds and are emitted if you have the logger set to the debug trace level (usually done with runtime configuration).
1. The MSDN pages are actually (IMO) a little bit unclear, but these SO posts agree with my interpretation:
System.Diagnostics.Debug.WriteLine in production code
C# Do Debug statements get compiled out when running in Release mode?

You can use preprocessor directive:
#if DEBUG
System.Diagnostics.Debug.WriteLine("Hello");
#endif
That line will be skipped when you'll build your application in Release build configuration.

How can I mark some lines of my code as it won't run in release?

I want to throw exceptions while debugging but in release mode I don't want to throw them. I am logging them into EventLog. This is the source of my problem but if I'm not wrong in C and Delphi there are some directives to make this.
In C# is there any way(directives or something else) which can ignore the lines in debug mode or release mode?

You can do it like this:
#if DEBUG
Console.WriteLine("Debug version");
#endif
http://msdn.microsoft.com/en-us/library/4y6tbswk.aspx

For your purposes (logging), you might also be interested in the ConditionalAttribute. It lets you mark an entire method as "remove all calls to this method in release builds".
If you do your logging in a lot of different places in your code, this would be much simpler than adding #if DEBUG around every single call site.

Use the #if DEBUG directive (and end with #endif). The DEBUG constant is defined when you run your application in debug mode (the Define DEBUG constant should be checked under the Build tab of your project properties).

Can I set a C# preprocessor directive from a central file?

I need to add some logging to my app, and it needs to be in release mode, and I need to make sure that the logging code isn't running in production. Therefore I'd like to use a #define and #if to make sure the log statements are removed when I move to production.
Trouble is, I need the logging in multiple files, and it's a pain to put a #define at the top of every file. Is there a way to have a centralized #define? That way I can remove the single #define rather than a #define from all files(which means I'll almost assuredly forget one).

On the command line, use the /define switch. In Visual Studio, choose the "Build" tab from the properties page for the project and fill in the "Conditional Compilation Symbols" section.
Consider also instead of using conditional compilation, to instead make your logging methods conditional methods. That's a more pleasant-looking alternative. That's how Debug.Assert works; it is a conditional method, so if the debug preprocessor symbol is not defined, the compiler simply removes all calls to the method before code generation.
See also my article on the subject:
http://ericlippert.com/2009/09/10/whats-the-difference-between-conditional-compilation-and-the-conditional-attribute/

Are you using Visual Studio? In the project Properties page, on the "Build" tab, there's a "Conditional compilation symbols" text box.

Yes, this is typically done in your build file, or the script you use which creates your build. You specify it as command-line arguments to MSBuild.

To add to Dave's answer, global conditional compilation symbols can also be specified in Visual.
Right-click on your project and go to Properties
Go to the Build tab
You can specify the symbols that you like (DEBUG is already turned on by default for Debug configurations, so this might actually give you what you want already) for the given configuration, or select "All Configurations" at the top to specify certain symbols for all configurations.

Call the logging everywhere you want.
Define the logging api entry methods with
[Conditional ("DEBUG")]
public void WriteDebugMessage(...)
Build your program in debug mode (which, by default, defines 'DEBUG' in VS). These calls will be part of your assembly.
Build your program in release mode (or - remove the DEBUG symbol from the build definition). These calls are now meaningless no-ops and won't run.
Seems like what you want?

VS2008: Multiple build configs with defines don't work as expected

I have a base library to maintain in multiple versions. I do a SVN switch whenever I need to work on another version.
I don't have multiple versions of my test application solution, so I thought that for different versions I could do multiple solution / project configurations that define symbols for the version to be able to have version-specific code in my test.
Currently I have the following build configurations in the test application solution: Debug, Release, DebugV10, ReleaseV10, DebugV15, ReleaseV15. In the *V10 and *V15 configs, I created and selected corresponding *V10 and *V15 PROJECT configurations for the two projects that have version-specific test code (not for all projects, most run normal Debug / Release configuration in the solution -Vx configuration).
In those project configurations I entered the corresponding conditional compilation symbols (VERSION10 and VERSION15).
Now in my code in the project I go like
#if VERSION10
// do v1.0 stuff
#elif VERSION15
// do v1.5 stuff
#else
// do trunk stuff
#endif
But apparently VS doesn't recognize the symbols. Even a simple #if DEBUG does not work anymore, allthoug define DERBUG constant is checked in all Debug* project configurations.
Is this a known thing? What can I do about it?

The concept that you describe sounds fine.
That is, the code uses:
#if VERSION10 ... #endif
and the Project configuration defines VERSION10
and a Solution configuration is set up that is set to use the above Project configuration.
As long as these are all set up correctly, I'd expect it to work.
The fact that you say even #if DEBUG isn't working as expected suggests that something is very broken.
I'd suggest you try the simplest possible case, to ensure you undersatand how to set it up: Create a new minimal "hello world" application that just has simple code that allows you to tell apart the versions:
#if VERSION1
Console.WriteLine("Hello from version 1");
#else
Console.WriteLine("Hello from version 2");
#endif
Then create project configurations ("Debug Version 1", "Debug version 2") and see if you can set them up (one with VERSION1 defined, one without) to get the two outputs when built.
Then add Solution configurations that use the above Project configurations, and build them to check that they print the right things when executed.
Once you've done this you should have a working system (an understanding of how these elements relate to each other) that you can apply back to your more complex project. To apply them back, I suggest deleting most of the project/solution configurations and then rebuilding them from scratch now that you are sure you know what to do - often rebuilding these things from first principles works out better than trying to tweak an existing 'broken' setup back into life.

Conditional compilation in C# is different from C and C++. See here for info on the ConditionalAttribute class.
For example:
doDebugOutput(); // unconditionally call the optional code
Conditional["DEBUG"]
void DoDebugOutput()
{
// do expensive debug-only output here
}