#if DEBUG vs condicional ("Test")

Question

¿Qué es mejor usar, y por qué, en un gran proyecto:

#if DEBUG 
    public void SetPrivateValue(int value) 
    { ... } 
#endif 

o

[System.Diagnostics.Conditional("DEBUG")] 
public void SetPrivateValue(int value) 
{ ... } 

Answer 1

Realmente depende de lo que vamos a dar:

• #if DEBUG: El código aquí ni siquiera llegará a IL en el lanzamiento.
• [Conditional("DEBUG")]: Este código llegará a la IL; sin embargo, llamadas al método se omitirán a menos que DEBUG se establezca cuando la persona que llama se compila.

Personalmente utilizo ambos, dependiendo de la situación:

condicional ("Test") Ejemplo: Puedo utilizar esto para que yo no tengo que volver atrás y editar mi código más tarde durante la liberación, pero durante la depuración quiero asegurarme de no haber cometido errores tipográficos. Esta función comprueba que escribo un nombre de propiedad correctamente cuando trato de usarlo en mi material INotifyPropertyChanged.

[Conditional("DEBUG")] 
[DebuggerStepThrough] 
protected void VerifyPropertyName(String propertyName) 
{ 
    if (TypeDescriptor.GetProperties(this)[propertyName] == null) 
     Debug.Fail(String.Format("Invalid property name. Type: {0}, Name: {1}", 
      GetType(), propertyName)); 
} 

Realmente no desea crear una función utilizando #if DEBUG menos que esté dispuesto para envolver cada llamada a la función con el mismo #if DEBUG:

#if DEBUG 
    public void DoSomething() { } 
#endif 

    public void Foo() 
    { 
#if DEBUG 
     DoSomething(); //This works, but looks FUGLY 
#endif 
    } 

frente:

[Conditional("DEBUG")] 
public void DoSomething() { } 

public void Foo() 
{ 
    DoSomething(); //Code compiles and is cleaner, DoSomething always 
        //exists, however this is only called during DEBUG. 
} 

---

#if DEBUG ejemplo: Lo uso cuando trato de configurar diferentes enlaces para la comunicación WCF.

En el primer ejemplo, el código existe, pero se ignora a menos que DEBUG esté activado. En el segundo ejemplo, la const ENDPOINT se establece en "Localhost" o "BasicHttpBinding" dependiendo de si DEBUG está configurado o no.

---

Actualización: Debido a que esta respuesta es la más alta votaron respuesta a la pregunta, estoy actualizando esta respuesta para aclarar un punto importante y difícil. Si elige usar el ConditionalAttribute, tenga en cuenta que las llamadas se omiten durante la compilación y no en el tiempo de ejecución. Es decir:

MyLibrary.dll

[Conditional("DEBUG")] 
public void A() 
{ 
    Console.WriteLine("A"); 
    B(); 
} 

[Conditional("DEBUG")] 
public void B() 
{ 
    Console.WriteLine("B"); 
} 

Cuando la biblioteca se compila contra el modo de liberación (es decir, sin símbolos de depuración), será siempre tienen la llamada a B() desde dentro A() omitido, incluso si una llamada a A() está incluido porque DEBUG se define en el conjunto de llamadas.

Answer 2

Bueno, vale la pena señalar que no significan lo mismo en absoluto.

Si no se define el símbolo de depuración, a continuación, en el primer caso la SetPrivateValue en sí no se llamará ... mientras que en el segundo caso, existirá, pero cualquier personas que llaman que se compilan sin símbolos de depuración tendrá esas llamadas omitidas.

Si el código y todas sus llamadas están en la misma asamblea esta diferencia es menos importante - pero significa que en el primer caso que También necesita tener #if DEBUG alrededor del código llamando así.

Personalmente recomendaría el segundo enfoque, pero es necesario que mantenga la diferencia entre ellos clara en su cabeza.

Answer 3

Con el primer ejemplo, SetPrivateValue no existirá en la acumulación DEBUG si no se define, con el segundo ejemplo, llama a SetPrivateValue no existirá en la acumulación DEBUG si no está definido.

Con el primer ejemplo, deberá ajustar todas las llamadas a SetPrivateValue con #if DEBUG también.

Con el segundo ejemplo, se omitirán las llamadas a SetPrivateValue, pero tenga en cuenta que el propio SetPrivateValue se compilará. Esto es útil si está creando una biblioteca, por lo que una aplicación que haga referencia a su biblioteca aún puede usar su función (si se cumple la condición).

Si desea omitir las llamadas y ahorrar el espacio del destinatario de la llamada, se puede utilizar una combinación de las dos técnicas:

[System.Diagnostics.Conditional("DEBUG")] 
public void SetPrivateValue(int value){ 
    #if DEBUG 
    // method body here 
    #endif 
} 

Answer 4

Vamos a suponer que su código también tenía una declaración #else que definía una función de código nulo, abordando uno de los puntos de Jon Skeet. Hay una segunda distinción importante entre los dos.

Supongamos que existe la función #if DEBUG o Conditional en una DLL a la que hace referencia el ejecutable de su proyecto principal. Con el #if, la evaluación del condicional se realizará con respecto a la configuración de compilación de la biblioteca. Con el atributo Conditional, la evaluación del condicional se realizará con respecto a la configuración de compilación del invocador.

Answer 5

Estoy seguro de que muchos estarán en desacuerdo conmigo, pero después de haber pasado un tiempo como un chico de la construcción escuchando constantemente "¡Pero funciona en mi máquina!", Considero que casi nunca deberías usar ninguno. Si realmente necesita algo para probar y depurar, encuentre una manera de hacer que esa capacidad de prueba se separe del código de producción real.

Resuma los escenarios con burlas en las pruebas unitarias, realice una versión de las cosas para escenarios únicos que desee probar, pero no ponga pruebas para depurar en el código los binarios que prueba y escribe para el lanzamiento de producción. Estas pruebas de depuración simplemente ocultan posibles errores de los desarrolladores para que no se encuentren hasta más adelante en el proceso.

Answer 6

Tengo una extensión SOAP WebService para registrar el tráfico de red usando una [extensión de seguimiento] personalizada. Lo uso solo para compilaciones de depuración y omito de versiones de lanzamiento. Use #if DEBUG para ajustar el atributo [TraceExtension] y eliminarlo de las compilaciones de Release.

#if DEBUG 
[TraceExtension] 
#endif 
[System.Web.Service.Protocols.SoapDocumentMethodAttribute(...)] 
[ more attributes ...] 
public DatabaseResponse[] GetDatabaseResponse(...) 
{ 
    object[] results = this.Invoke("GetDatabaseResponse",new object[] { 
      ... parmeters}}; 
} 

#if DEBUG 
[TraceExtension] 
#endif 
public System.IAsyncResult BeginGetDatabaseResponse(...) 

#if DEBUG 
[TraceExtension] 
#endif 
public DatabaseResponse[] EndGetDatabaseResponse(...) 

Answer 7

Ésta puede ser útil también:

if (Debugger.IsAttached) 
{ 
... 
}