Smtp Client give COMException No such interface supported

Aspose.Email Product Family
1

Hi

I am getting COMException when trying to send an email within a Windows Service. The Windows Service is the SMTP service and therefore runs under IIS which runs as Local System. The operating system is Windows Server 2008 R2 (64bit).

If I put the same code inside a console application it works fine. The delivery method is

client.DeliveryMethod = Aspose.Network.Mail.SmtpDeliveryMethod.PickupDirectoryFromIis

Here is the stack trace from Event Log.

Message: Could not send email, exception System.Runtime.InteropServices.COMException (0x80004002): No such interface supported

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at Aspose.Network.Mail.SmtpClient.xb29a7e60cc957867()
at Aspose.Network.Mail.SmtpClient.Send(MailMessage message, MailAddress sender)

Regards

Richard....

2

Hi,

What account does the Windows Service log on? Is there permission issue?

Thanks,

3

Hi

Found the main problem was that I was using version 3.9.3 and not 4.8.x. Upgraded to 4.8.x and the COM exception went away. But then I found that attachments (Word 2007 mainly) were getting corrupted when loading from either the disk or resource file. So I have reverted back to System.Net.* classes and it is now working fine.

I just needed to be able to generate SMTP emails with PDF, Word and Email attachments. My main problem before using Aspose was that the attached eml file was not viewable in Outlook, but once I told it to use 7bit encoding it is all working fine now.

We do use Aspose for various other parts of our products and don't have that much problems with them. In this instances we are going to keep with the System.Net classes until we need to switch to something more powerful.

Regards

Richard...