System.Web.Mail question

  • Thread starter Thread starter Adrian
  • Start date Start date
Adrian said:
What does this error mean?

Could not access CDO Message Object.
Click to expand...

If you search for the error message on Google, you'll find *lots* of
references to it. I believe the InnerException property usually gives
you a lot more information about what's gone wrong.
 
Adrian,
From Windows 2000 server to 2003 server, the default component for
Click to expand...
sending local smtp mail changed from the CDONTS COM+ package to the CDO
package. If you have a late version of outlook installed, you'll
probably have the CDO package installed. You can either make a com
interop assembly to use CDONTS or install the CDO package on the
server. System.Web.Mail uses CDO.

Best regards,
Jeffrey Palermo
 
Jeffrey Palermo said:
Adrian,
sending local smtp mail changed from the CDONTS COM+ package to the CDO
package. If you have a late version of outlook installed, you'll
probably have the CDO package installed. You can either make a com
interop assembly to use CDONTS or install the CDO package on the
server. System.Web.Mail uses CDO.

Best regards,
Jeffrey Palermo
Click to expand...

"You can either make a com interop assembly to
use CDONTS" ... wouldn't know how the L to do that.
The only thing I can find on my pc is pkmcdo.dll
Is a cdo package downloadable? Couldn't find a
download option on MSDN.

Apologies for the ignorance.
 
Jeffrey Palermo said:
Adrian,
sending local smtp mail changed from the CDONTS COM+ package to the CDO
package. If you have a late version of outlook installed, you'll
probably have the CDO package installed. You can either make a com
interop assembly to use CDONTS or install the CDO package on the
server. System.Web.Mail uses CDO.

Best regards,
Jeffrey Palermo
Click to expand...

Hi Jeffrey

After a connection with the server has been established, an email can be
sent ok.
However if a connection has not yet been established, I get the "Could not
access
CDO.Message object" error. Is there a way to overcome this, i.e., that a
message
can be sent without first having to manually establish a connection with the
server?

Many thanks,
Adrian
 
Adrian said:
Yes I know about Indy. The trouble is the license. It cannot be
redistributed.
Click to expand...

You dont understand the license very well if you think it cannot be
redistributed. Where did you get this impression? In fact Indy has two
licenses you can choose from, both of which allow free redistribution.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/
 
Chad Z. Hower aka Kudzu said:
You dont understand the license very well if you think it cannot be
redistributed. Where did you get this impression? In fact Indy has two
licenses you can choose from, both of which allow free redistribution.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/
Click to expand...

Hi Chad,

If I have FreeSMTP.Net.dll and
Indy.Sockets.dll in an application
I am not allowed to sell that application
commercially. That is what I understand.
If that is not so, could you please direct me
to where I can read anything to the
contrary?

Many thanks.
 
Adrian said:
If I have FreeSMTP.Net.dll and
Indy.Sockets.dll in an application
I am not allowed to sell that application
commercially. That is what I understand.
If that is not so, could you please direct me
to where I can read anything to the
contrary?
Click to expand...

http://www.indyproject.org/License/BSD.iwp talks about one form of the
Indy licence which doesn't seem to stop you from selling it
commercially.

The FreeSMTP.Net library appears to only be freely distributable for
non-profit applications, but I don't see what that has to do with your
claim that Indy can't be redistributed.
 
Jon Skeet said:
http://www.indyproject.org/License/BSD.iwp talks about one form of the
Indy licence which doesn't seem to stop you from selling it
commercially.

The FreeSMTP.Net library appears to only be freely distributable for
non-profit applications, but I don't see what that has to do with your
claim that Indy can't be redistributed.
Click to expand...


Hi John,

Thank very much you for this information.
I will now have to find out whether Indy can work
together with System.Web.Mail. As you will
understand I am not familiar with this area
of expertise. Any further tips would be greatly
appreciated.

Adrian.
 
Adrian said:
Thank very much you for this information.
I will now have to find out whether Indy can work
together with System.Web.Mail. As you will
understand I am not familiar with this area
of expertise. Any further tips would be greatly
appreciated.
Click to expand...

Using Indy means you don't have to use System.Web.Mail at all - why
would you particularly want to?
 
Jon Skeet said:
Using Indy means you don't have to use System.Web.Mail at all - why
would you particularly want to?
Click to expand...

Actually I don't particularly want to. As I posted back to you
http://www.codeproject.com/csharp/IndySMTP.asp
seems to have the information I have been looking for.
(Hopefully it does.)

Many thanks Jon, your response about
the license seems to have got me going in
the right direction. I was starting to think
this subject was a "mer à boire".
 
Pointless Interop is not something I'd encourage. Do you really need to call
the Indy components? There is native dotnet SMTP support and if that's not
enough the superb socket classes make it trivial to implement a simple
protocol like SMTP. Consider this article of mine
http://www.codeproject.com/useritems/EmailMessage.asp

Does it do attachments? Yes and no. It certainly does multipart mime
encoding but it doesn't support attachments in the sense in which most users
would conceive them. Once again this would be trivial to implement - I just
didn't see the point. EmailMessage class is designed to send a web page as
the content of the message. If you want attachments just put in hyperlinks
to the files on a webserver. It means people don't have to collect the
attachments unless they really want them.
 
Peter Wone said:
Pointless Interop is not something I'd encourage. Do you really need
to call the Indy components? There is native dotnet SMTP support and
if that's not enough the superb socket classes make it trivial to
implement a simple protocol like SMTP.
Click to expand...

But why implement it yourself when someone else has already done it?
(As for it being trivial - in your article you make mention of an
earlier version of your class having no error checking etc. Such things
take time in my experience, but are vital for production systems.)
Consider this article of mine
http://www.codeproject.com/useritems/EmailMessage.asp

Does it do attachments? Yes and no. It certainly does multipart mime
encoding but it doesn't support attachments in the sense in which most users
would conceive them. Once again this would be trivial to implement - I just
didn't see the point. EmailMessage class is designed to send a web page as
the content of the message. If you want attachments just put in hyperlinks
to the files on a webserver. It means people don't have to collect the
attachments unless they really want them.
Click to expand...

And I'm sure that's good for many uses, but not all of them. I don't
see why you think it's actually a bad idea to use Indy.
 
But why implement it yourself when someone else has already done it?

Whether someone else has done "it" depends on your precise definition of
"it" hence I regard the DNF classes mail support adequate for plaintext and
inadequate for fancy work with ASPX etc.

Also sometimes "someone else" hasn't done a proper job. MimeOLE fails to
include watermark graphics referenced by a linked stylesheet. MimeOLE also
leaves stylesheets linked instead of munging them into the HTML which means
they get lost with Outlook Web Access.
(As for it being trivial - in your article you make mention of an
earlier version of your class having no error checking etc. Such things
take time in my experience, but are vital for production systems.)
Click to expand...

Yes indeed. My sysadmin asked me to use the pickup folder, apparently it's
faster due to something to do with queueing and how our systems are
configured. The SMTP protocol implementations are there for illustrative
purposes. In my environment this code worked first time which is a big part
of the reason the code never got much in the way of instrumentation. I stand
by my assertion that it is trivial. If you want to criticise me then say
that I am lazy.

Then add "pragmatic" - in a production system the pickup folder is more
likely.
And I'm sure that's good for many uses, but not all of them. I don't
see why you think it's actually a bad idea to use Indy.
Click to expand...

I don't think it's a bad idea to use Indy - from Delphi. I just think that
if I can write a fancy mailer in 300 lines of pure managed code - and I
did - then it's wrong to write 600 lines of interop.

Regarding attachments, my position on them is that machine generated email
is dangerously close to spam before you even start, and that there's enough
crap in my mailserver queue without me encouraging the irresponsible. The
best reason I can conceive for wanting to attach a file to a machine
generated email would be sending an invoice or similar business document.
However in this situation the document can directly be the body of the
email, leaving me with no ethically acceptable reason for supporting
attachments in machine generated email.
 
I don't think it's a bad idea to use Indy - from Delphi. I just think that
if I can write a fancy mailer in 300 lines of pure managed code - and I
did - then it's wrong to write 600 lines of interop.
Click to expand...

I think you're confused about Indy. These days, Indy is available as a
..NET assembly. No interop involved. Delphi is another .NET language
now.
 
Back
Top