I was writing an C# Console application which I use System.Web.Mail.SmtpMail to send
email out. System.Web.Mail.SmtpMail internally use CDO for Windows 200 (CDOSys) to
send the mail out.
While my application was running, I got an exception when calling the SmtpMail.Send()
method. The exception message was :
Could not access CDO.Message object.At first thought, the exception could be due to one of the following reasons:
- The CDOSys.dll component is not registered properly on the machine.
- The application does not have enough permission to read the registry and instantiate the component.
So, I went on to search the MSDN for the possible cause and mitigation of error. I found a few KB articles and try the settings suggested in the articles and still not luck. I try a couple more things to try to get it work. After half an hour, still nothing was working.
So I decide to reference the CDOSys.dll using COM interop in my C# project and replace the original code with calls to CDO.Message directly. When I ran the application, the exception message I got was :
Unable to connect to SMTP serverNow, things become helpful.I check my SMTP server setting and found out that I gave the wrong IP. I type in the correct SMTP Server IP, ran the app again and everything work now. I move on to put back my original System.Web.Mail.SmtpMail code with the correct SMTP Server IP and get everything working. This whole process took me only 5 minutes.
If the System.Web.Mail.SmtpMail.Send() throw an exception with more precise message, it would have save me 30 minutes time for looking at the wrong thing.
The lesson here is :
If you does not return a meaningful exception/error message which precisely describe the error, you will drive your user nuts and mislead them into looking at the wrong remedy. This will essentially make your API/application less usable.
Labels: design, programming