begin process at 2010 02 09 22:49:19
  Trouver un code source :
 
dans
 
Accueil > 

Code

 > 

Réseaux & Internet

 > ENVOI D'EMAILS AVEC LES CLASSES .NET - MAIL MESSAGE

ENVOI D'EMAILS AVEC LES CLASSES .NET - MAIL MESSAGE


 Information sur la source

Note :
7 / 10 - par 3 personnes
7,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Réseaux & Internet Source .NET ( DotNet ) Classé sous :mailer, envoi mail, mail message, mail adresse, send mail Niveau :Initié Date de création :22/01/2008 Vu / téléchargé :7 596 / 488

Auteur : Belouafi

Ecrire un message privé
Commentaire sur cette source (15)
Ajouter un commentaire et/ou une note

 Description

Cliquez pour voir la capture en taille normale
Cette source montre comment utiliser les classes du .net framework 2.0 pour envoyer des emails bien structurés.

Source

  • using System;
  • using System.Collections.Generic;
  • using System.Text;
  • using System.Net.Mail;
  • using System.Net.Sockets;
  • using System.IO;
  • using System.Collections;
  • /* Cette classe va être la classe de notre application */
  • namespace MailNetClass
  • {
  • class Mailer
  • {
  • private MailAddress adrMail; // Adresse mail de expéditeur
  • private MailMessage mail; // le mail lui même
  • private SmtpClient smtp; // une variable pour gérer le serveur SMTP
  • private Attachment att; // une variable attachement pour ajouter des fichiers joints
  • public Mailer()
  • {
  • // initialisation des variables
  • mail = new MailMessage();
  • smtp = new SmtpClient();
  • }
  • /* Fonction qui permet d'envoyer les mails */
  • public void sendMail(String Destinataires,String CC, String CCC, String Subject, ArrayList joints, String Body)
  • {
  • // On lit le fichier de configuration qui contient l'adresse mail de l'expéditeur ainsi que @ du serverur smtp
  • // stockés comme sui nom_user@domaine.com%ip_serveur_smtp
  • String str = File.ReadAllText("C:\\mail.ini"); ;
  • String[] f = str.Split('%');
  • adrMail = new MailAddress(f[0], f[2]);
  • smtp = new SmtpClient(f[1]);
  • int i = 0;
  • // La fonction admet comme paramètre un arraylist qui contient les noms des fichiers joints, on les rajoute au attachements du mail message
  • for (i = 0; i <= joints.Count - 1; i++)
  • {
  • att = new Attachment((String)joints[i]);
  • mail.Attachments.Add(att);
  • }
  • // Test sur les adresses des destinataires si elle est vide
  • if (Destinataires ==string.Empty )
  • {
  • throw new Exception("La liste des destinataires ne peut pas être vide !");
  • }
  • mail.To.Add(Destinataires);
  • mail.Subject = Subject;
  • if (CC != String.Empty)
  • {
  • mail.CC.Add(CC);
  • }
  • if (CCC != String.Empty)
  • {
  • mail.Bcc.Add(CCC);
  • }
  • mail.Body = Body;
  • mail.From = adrMail;
  • // Envoi du mail
  • smtp.Send(mail);
  • }
  • }
  • }
using System;
using System.Collections.Generic;
using System.Text;
using System.Net.Mail;
using System.Net.Sockets;
using System.IO;
using System.Collections;

/* Cette classe va être la classe de notre application */

namespace MailNetClass
{
    class Mailer
    {
        private MailAddress adrMail; // Adresse mail de expéditeur 
        private MailMessage mail; // le mail lui même 
        private SmtpClient smtp; // une variable pour gérer le serveur SMTP
        private Attachment att; // une variable attachement pour ajouter des fichiers joints
        

        public Mailer()
        {
            // initialisation des variables
            mail = new MailMessage(); 
            smtp = new SmtpClient();
        }
        
        /* Fonction qui permet d'envoyer les mails */

        public void sendMail(String Destinataires,String CC, String CCC, String Subject, ArrayList joints, String Body)
        {
           // On lit le fichier de configuration qui contient l'adresse mail de l'expéditeur ainsi que @ du serverur smtp
           // stockés comme sui  nom_user@domaine.com%ip_serveur_smtp

            String str = File.ReadAllText("C:\\mail.ini"); ;
            String[] f = str.Split('%');
            
            adrMail = new MailAddress(f[0], f[2]);
            smtp = new SmtpClient(f[1]);
            
            int i = 0;
            
            // La fonction admet comme paramètre un arraylist qui contient les noms des fichiers joints, on les rajoute au attachements du mail message

            for (i = 0; i <= joints.Count - 1; i++)
            {
                att = new Attachment((String)joints[i]);
                mail.Attachments.Add(att);
            }

            // Test sur les adresses des destinataires si elle est vide

            if (Destinataires ==string.Empty )
            {
                throw new Exception("La liste des destinataires ne peut pas être vide !");
            }
            mail.To.Add(Destinataires);
            mail.Subject = Subject;
            if (CC != String.Empty)
            { 
                mail.CC.Add(CC); 
            }
            if (CCC != String.Empty)
            {
                mail.Bcc.Add(CCC);
            }
            mail.Body = Body;
            mail.From = adrMail;

            // Envoi du mail

            smtp.Send(mail);
        }
    }
}


 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources de la même categorie

Source avec Zip Source avec une capture Source .NET (Dotnet) HTTP FLOOD STRESS TEST par NightMareLmW
Source avec Zip Source avec une capture Source .NET (Dotnet) SERVEUR/ESCLAVE MODBUS TCP/IP par SteveFuchsIT
Source avec Zip Source avec une capture Source .NET (Dotnet) IPHELPER - PORTS TCP/UDP, TABLES DE ROUTAGE/ARP + FONCTIONS ... par Willi
Source avec Zip Source avec une capture Source .NET (Dotnet) [.NET3.5] SYSTEM.IO.PIPES - UTILISATION D'UN CANAL NOMMÉ par Willi
Source avec Zip Source .NET (Dotnet) MESSAGES PERSOS MSN par XelectroX

 Sources en rapport avec celle ci

Source avec Zip Source avec une capture Source .NET (Dotnet) SEND MAIL WITH GMAIL par ayache78500

Commentaires et avis

Commentaire de oximoron le 22/01/2008 13:19:10

C'est bien fait  mais le throw new Exception quand il n'y pas de destinataire c'est un peu hard, et vu que c'est une classe qui sera utilisé autre part il vaut mieux a mon avis que tu renvoies une valeur genre un enum qui correspond à un type d'erreur.

Commentaire de Warny le 22/01/2008 14:16:02

oximoron -> je ne suis pas d'accord avec toi. L'exception permet de gérer le fait qu'il y ait une erreur et son contenu correctement. Il suffit de faire un try/catch pour gérer l'erreur, c'est à mon sens la meilleure méthode

Commentaire de Belouafi le 22/01/2008 15:36:00

Ce que vous dites n'est pas tout à fait juste, vu que j'utilise le throw pour qu'elle soit catché dans l'interface graphique et comme ça elle va être gérée comme étant une érreur. Il faut voir le try/catch il est présent dans le code source du bonton envoyer.

Commentaire de oximoron le 22/01/2008 16:18:51

Warny -> On s'entend sur un point, on n'est pas d'accord ensembble :). Pourquoi je dis ca : Imaginons dans le cas où on utilise une dll externe dont on a pas accès aux sources. Comment voir ce qui est catché ou pas ? Si il y a plusieurs erreurs il faudra faire un test dans le catch pour faire un traitement spé. Et un autre cas, j'utilise une fonction d'une classe un peu plus complexe qui va lancer une throw sur quelque chose qui ne sera pas bloquant alors que je ne veux pas qu'il le fasse.
Pour moi tant qu'on peut faire des tests classiques avec des if on fait ca, les try/catch c'est pour rattraper les erreurs non prévus.
Donc je reste sur ma position (pour l'instant)

Commentaire de Belouafi le 22/01/2008 17:21:27

Bon, c'est de la programmation classique enfin de compte, moi j'ai un point de vue c'est minimiser les if dans mes programmes. D'ailleur, un bon programmeur a toujours intêret d'utiliser des try/catch, surtout dans les application qu'il juge instable ( cas des bases de données par exemple ).
Pour cela, je prèfère utiliser des try/catch, pour minimiser les if d'un coté, et pour montrer des fois l'utilité.

Commentaire de billou_13 le 22/01/2008 17:27:13

Bonsoir,

Histoire d'ajouter un protagoniste à votre débat, je voudrais donner mon accord pour l'utilisation de l'exception car il s'agit bien d'un traitement problèmatique qui ne devrait pas être fait, donc une exception. Comme son nom l'indique, c'est une exception qui peut arriver et doit être corriger: on ne doit pas appeler une méthode send mail avec un destinataire vide.
Cependant, (il y a toujours un mais), je voudrais ajouter un petit conseil: tu devrais tester la valeur nulle aussi et envoyé une exception typée. Cela permet aux utilisateurs de ta classe de pouvoir trier les exceptions. Et, de plus, pourquoi ne pas le faire quand le framework nous donne les outils pour ^^

Cela donne donc le code:

if(string.IsNullOrEmpty(Destinataires))
   throw new ArgumentException("La liste des destinataires ne peut pas être vide !");


Enfin, ca s'appelle du chipotage à ce niveau ^^ (mais j'aime chipoter)

Bonne soirée à vous,

Commentaire de Belouafi le 22/01/2008 17:31:28

Bonne idée. Je suis de ton avis.

Commentaire de Shad78 le 22/01/2008 17:51:14 7/10

Oui je suis également en faveur de l'exception, c'est à mon avis la meilleure façon de gerer les erreurs en C# et dans tous les langages qui les mettent à disposition.
Comment améliorer un tout petit peu? On pourrait faire une classe qui dérive de System.Exception et utiliser celle ci pour que le développeur qui utilise la classe puisse filtrer les exception sur le type d'exception. (ChipotageLevel = 90).
On pourrait également mettre dans les commentaires XML une balise exception : /// <exception cref="System.Exception">Declenche une exception si aucun destinataire</exception> pour informer ceux qui utiliseront la classe qu'une exception peut être déclenché. (ChipotageLevel = 97)
Sinon c'est une source simple mais claire donc c'est bien :)
A pu qu'à mettre des commentaires XML partout! ;)

Commentaire de oximoron le 22/01/2008 18:21:59

bon moi je vais faire mon têtu, mais je vous avoue ne pas trop bien vous suivre:
Vous préférez
try
{
EnvoiMail()
}
catch
{
}

à ca :

bool lbEnvoiOk = EnvoiMail()
if(!lbEnvoiOk)
{
}
else
{
}

Moi je préfère le 2ème. J'ai déjà eu des cas où une exception était lancé alors que voulais traiter l'erreur moi même, mais j'ai du surchagée la fonction pour faire un test avant le throw ... C'est sur une appli pas forcément géniale au niveau du code avec des try catch dans tous les sens, impriquées, avec des throw new exeption à tous va, donc que je pense que c'est pas forcément mauvais, mais ca peut vite devenir un bordel monstre

Commentaire de billou_13 le 22/01/2008 19:11:00

Je vais répondre à ta question oximoron.

Tu as tout à fait raison sur le fait que ce n'est pas bon de lancer des exceptions à tout bout de champs. C'est pourquoi il est très important de se poser la question : envoyer une exception ou renvoyer un code erreur.



Je vais donc parler personnellement car ce choix est à la décision de chacun.
Je pense qu'un code erreur ne peut être renvoyé que si le déroulement a été normal et surtout, si l'erreur était à prévoir pour le besoin utilisateur.
Exemple: on te demande de faire un logiciel qui va scanner un fichier formaté de telle facon tout en vérifiant les erreurs possibles (erreur de formatage d'un entier,...). Dans ce cas, il vaut mieux préférer le recours à un code erreur (int.TryParse(...)) plutot que de faire des int.Parse et catcher les erreurs.


Seulement, dans le cas de cette méthode Send(...), c'est bien plus qu'une simple erreur, c'est une erreur qui ne doit jamais arriver. C'est au développeur qui appelle la méthode de vérifier au préalable.
foreach(string curAdr in listeAdresses)
{
  if(!string.IsNullOrEmpty(curAdr))
     Send(...);
}

Mais aussi, une raison de plus, imagines que quelqu'un utilise cette classe mais qu'il s'en fout du code de retour de la fonction. Il va croire que tout va bien alors que non. En lui envoyant une exception, tu lui indiques une erreur dans son programme: le destinataire ne doit pas être vide.

Voila ce que je pense mais c'est au désir de chacun ^^


Et pour finir, je voudrais faire une proposition qui pourrait combler tout le monde. Pourquoi ne pas enlever complétement ce test et laisser le framework faire ce qu'il veut de cet argument (à voir: http://msdn2.microsoft.com/fr-fr/library/swas0fwc(VS.80).aspx). Car après tout, ce n'est peut être pas à la fonction test de faire ce test mais plutôt à la fonction smtp.Send(mail);
Comme ça, plus de problème ^^


Bonne soirée à tous,

Commentaire de billou_13 le 22/01/2008 19:29:34 7/10

J'avais oublié la note avec tout ça ^^

Commentaire de oximoron le 22/01/2008 20:05:05 7/10

Merci pour ces précisions, je pense que l'appli pour laquelle je traville n'est pas étrangère à cet aprioris. Ca lance des exeptions pour des broutilles et ca plante quand l'objet est null...
En fait ca dépent du contexte, du développeur et de l'utilisateur.

Pour en revenir au code:
les using System.Collections.Generic et System.Text ne sont pas utilisées.
Le '%' et le "C:\\mail.ini" il faut au moins mettre ca en constantes

Encore une chose :
String str = File.ReadAllText("C:\\mail.ini"); ;
String[] f = str.Split('%');
adrMail = new MailAddress(f[0], f[2]);
smtp = new SmtpClient(f[1]);
Pourquoi ne pas les mettres dans une fonction genre LoadParam() qui ne serait appelé que dans le constructeur, comme ca si je fais un evoi de 300 mails ca évite d'aller lire le fichier ini 300 fois...

Commentaire de Belouafi le 22/01/2008 20:15:36

Ceci ce n'est qu'un simple exemple de l'utilisation des classes .NET, si on s'amuse à optimiser il y en tant de chose à faire , exemple :

string[] f=(string)(File.ReadAllText("C:\\mail.ini")).split('%');

Pour le contructeur, si tu envoi 300 mais tu va écrire les adresses l'une après l'autre séparées par des virgules.

Commentaire de badrbadr le 22/01/2008 20:31:17

L'utilisation des exceptions diminue les performances de l'application.
C'est un point à considérer.

Commentaire de MrCapo le 13/07/2009 00:03:56

Mon commentaire vient un peu en retard.
Si j'ai bien suivi le débat.
J'apporte ma connaissance à ce sujet.
Les règles disent qu'il faut vérifier l'état des variables saisies par l'utilisateur, ce qui est fait.
Et aussi et surtout
lors de l'utilisation d'un Stream, il faut toujours mettre l'opération entre un bloque try catch et capter l'exception. Dans ce cas, l'opération d'envoi et une opération d'écriture dans un flux de donnée, de type particulier, mais ça reste une écriture dans un Stream, pareil que dans un fichier. Donc, il faut mettre le send entre try{}catch(){}
Je vous donne le pour quoi:
Imaginer que toutes les variables contiennent les bonnes valeurs, jusqu'à la tout est bon.
Mais, tu n'es pas sure que le serveur ne va pas te répondre, alors il y aura une erreur qui va cracher l'application.
Une écriture dans un fichier est simple, ouvrir, écrire et fermer. Mais si le fichier est réservé par un autre processus, c'est le même cas ici.

Conclusion:
Vérification de variable : IF et TRYPARSE
manipulation d'un stream ==> BLOCK TRY CATCH

 Ajouter un commentaire




Nos sponsors


Sondage...

CalendriCode

Février 2010
LMMJVSD
1234567
891011121314
15161718192021
22232425262728

Consulter la suite du CalendriCode

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,530 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales