test - if development c#

¿Cuándo usar las directivas de preprocesador en.net?

Question

Creo que esta es una pregunta simple, así que asumo que me estoy perdiendo algo obvio. Realmente nunca uso directivas de preprocesador, pero estaba mirando el código de alguien que lo hizo y pensé que era algo con lo que debería estar familiarizado.

Así que miré el ejemplo de msdn here tiene el código:

#define DEBUG
// ...
#if DEBUG
Console.WriteLine("Debug version");
#endif

Mis dos preguntas son:

• en el ejemplo anterior, ¿por qué definen DEBUG? Tenía la impresión de que estaba configurado si compilaba en el modo debug v. Release.
• mirando el otro ejemplo que tiene #define MYTEST y luego escribe en la consola dependiendo de si está ''definido'', pero ¿en qué se diferencia esto de solo usar una variable? ¿Que me estoy perdiendo aqui?

Answer 1

en el ejemplo anterior, ¿por qué definen DEBUG? Tenía la impresión de que estaba configurado si compilaba en el modo debug v. Release.

Probablemente porque es código de ejemplo. Está destinado a demostrar cómo funcionan #ifdef y sus amigos. No esperaría que definieras símbolos así en los archivos de origen, a menos que sea para una prueba rápida.

mirando el otro ejemplo que tiene "#define MYTEST" y luego escribe en la consola dependiendo de si está ''definido'', pero ¿en qué se diferencia esto de solo usar una variable? ¿Que me estoy perdiendo aqui?

Si MYTEST no está definido en tiempo de compilación, el compilador no emitirá realmente el código entre los bloques #if y #endif . Por lo tanto, la IL resultante será más pequeña.

Además, tenga en cuenta que estas no son directivas de preprocesador en C #.

Answer 2

Generalmente, los símbolos de compilación condicionales / opcionales serán proporcionados por el script de compilación. Es bastante raro ver #define , excepto por un código muy depurado (si ves lo que quiero decir).

Re usando una variable; A menudo utilizo tales condiciones para manejar el código que debe ejecutarse en diferentes tiempos de ejecución (mono, cf, silverlight, etc.). Una variable no puede ser suficiente porque el código no puede compilarse contra la plataforma incorrecta (tipos / métodos faltantes, etc.).

En el ejemplo presentado, probablemente hubiera utilizado Debug.WriteLine ; ya que está decorado con [Conditional("DEBUG")] , todas las llamadas se eliminan automáticamente si DEBUG no está definido en la compilación.

Answer 3

Lo he usado para muchas cosas. Depurar los mensajes que solo quiero en las versiones de depuración; limpiar archivos temporales; Incluye funciones o acciones de diagnóstico.

Answer 4

Me gustaría dar un ejemplo donde he usado una directiva de preprocesador en mi proyecto.

Mi programa crea muchos archivos intermedios en el disco. Utilicé la directiva #DEBUG para eliminar esos archivos solo si mi proyecto está en modo de lanzamiento; de lo contrario, conservo esos archivos para que podamos ver esos archivos intermedios y determinar qué sucede dentro.

Cuando mi aplicación está trabajando en el servidor de producción, compilo el proyecto en modo de lanzamiento para que esos archivos se eliminen una vez que se complete el procesamiento.

#if (DEBUG==false)
deleteTempFiles()
#endif

Answer 5

Realmente recomendaría usar el atributo condicional en lugar de las declaraciones #if en línea.

[Conditional("DEBUG")]
private void DeleteTempProcessFiles()
{
}

No solo es más limpio y fácil de leer, ya que no termina teniendo #if, #else dentro de su código. Este estilo es menos propenso a errores, ya sea durante las ediciones normales del código y también a los errores de flujo lógico.

Answer 6

Si usa la variable, se compila todo el código, cuando usa directivas de preprocesador solo parte del código incluido en ejecutable / dll.

Answer 7

Tengo un código que necesita un manejo diferente al usar el entorno Mono en lugar del CLR, por lo que tengo una directiva Mono en algunos de mis módulos. Creo que este es un mejor ejemplo que la depuración.