2011-08-19 19 views
5

consideran este códigoEl análisis de código se queja de que no estoy eliminando objetos. ¿Que esta mal aquí?

private MailMessage GetMailMessageFromMailItem(Data.SystemX.MailItem mailItem) 
     { 

      var msg = new MailMessage(); 

      foreach (var recipient in mailItem.MailRecipients) 
      { 
       var recipientX = Membership.GetUser(recipient.UserKey); 
       if (recipientX == null) 
       { 
        continue; 
       } 

       msg.To.Add(new MailAddress(recipientX.Email, recipientX.UserName)); 
      } 

      msg.From = new MailAddress(ConfigurationManager.AppSettings["EmailSender"], 
            ConfigurationManager.AppSettings["EmailSenderName"]); 

      msg.Subject = sender.UserName; 
      if (!string.IsNullOrEmpty(alias)) msg.Subject += "(" + alias + ")"; 
      msg.Subject += " " + mailItem.Subject; 
      msg.Body = mailItem.Body; 
      msg.Body += Environment.NewLine + Environment.NewLine + "To reply via Web click link below:" + Environment.NewLine; 
      msg.Body += ConfigurationManager.AppSettings["MailPagePath"] + "?AID=" + ContextManager.AccountId + "&RUN=" + sender.UserName; 

      if (mailItem.MailAttachments != null) 
      { 
       foreach (var attachment in mailItem.MailAttachments) 
       { 
        msg.Attachments.Add(new Attachment(new MemoryStream(attachment.Data), attachment.Name)); 
       } 
      } 

      return msg; 
     } 

sólo estoy tomando mi tipo de base de datos y la conversión a MailMessage. Se envía en otra función.

El análisis de código me dice que no me estoy deshaciendo de "msg", que es correcto. Pero si lo hago aquí, obtengo una excepción cuando intento enviarlo.

Además, se queja de no disponer MemoryStream aquí:

msg.Attachments.Add (nuevo Adjunto (nueva MemoryStream (attachment.Data), attachment.Name));

No tengo idea de cómo desecharlo correctamente. Probé cosas diferentes pero recibía excepciones cuando enviaba un mensaje que decía "Stream se cierra"

Respuesta

2

Básicamente no debe deshacerse del mensaje de correo más tarde dispondrá de cada archivo adjunto, que eliminará cada flujo. Además, no disponer de un MemoryStream que no se esté utilizando en remoto no hará ningún daño.

Le sugiero que suprima la advertencia de este método.

EDIT: sospecho que puede usar [SuppressMessage] para suprimir el mensaje.


Tenga en cuenta que hay un riesgo de que algún código va a tirar código a mitad de camino a través del método, así que al final no poder disponer del mensaje, incluso si tiene una declaración using en el código de llamada. Si realmente te molesta, puedes escribir:

private MailMessage GetMailMessageFromMailItem(Data.SystemX.MailItem mailItem) 
{ 
    bool success = false; 
    var msg = new MailMessage(); 
    try 
    { 
     // Code to build up bits of the message 
     success = true; 
     return msg; 
    } 
    finally 
    { 
     if (!success) 
     { 
      msg.Dispose(); 
     } 
    } 
} 

Personalmente, yo diría que esto es exagerado.

+0

¿Cómo elimino las advertencias? – katit

+0

@katit: Pase: no uso el análisis de código. Sin embargo, estoy seguro de que hay muchas instrucciones en línea. –

+0

@Downvoter: ¿me gustaría comentar? –

0

Con respecto a "no desechar" msg "", la única forma en que puedo pensar es en lugar de devolver MailMessage en lugar de pasar una referencia a un MailMessage. Algo como esto. No estoy seguro de si es una buena idea.

private void GetMailMessageFromMailItem(ref MailMessage msg, Data.SystemX.MailItem mailItem) 
+0

Sospecho que la transmisión se almacenará en el archivo adjunto y solo se leerá más tarde. –

+0

@Jon Skeet, ahora que lo pienso, la transmisión debería estar abierta. – Jethro

-1

El creador del objeto desechable también debe desecharlo. Si no puede eliminar el mensaje aquí, debe pasarlo desde un creador a otro lugar. El análisis de código es correcto en este caso y puede terminar con pérdidas muy desafortunadas y difíciles de depurar si ignora estos mensajes.

+0

La transferencia de propiedad es un concepto muy útil, que desafortunadamente ni C# ni Code Analysis proporcionan ayuda. –

+0

Por lo tanto, debe evitarse. Por lo tanto, es conveniente asignarle al creador la responsabilidad de disponer de sus recursos desechables. –

+0

El creador no siempre es el propietario lógico. Por ejemplo, en el patrón de fábrica, el creador nunca es el propietario, ni la fábrica puede disponer del recurso que crea. En cambio, se debe devolver un recurso no presentado. –

Cuestiones relacionadas