Goody wrote about a web service he created that was changing strings as they come across against his will.  This was converting the \r\n to \n essentially stripping off the \r.  While I hadn't run into a similar situation, it got me curious on what was going on.  After some digging, it appears that this might be documented by Microsoft here in it's White Space [XML Standards].  Down at the very bottom it has a section labeled End of Line Handling which states:

XML processors treat the character sequence Carriage Return-Line Feed (CRLF) like single CR or LF characters. All are reported as a single LF character. Applications can save documents using the appropriate line-ending convention.

Also in the W3C it states:

XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

Seems like that is just the way it's gotta work if the standards are to be followed, so Dave's workaround sounds like a good solution if you need to preserve both the carriage return and line feed.

I developed a smart client for a customer a while back.  It's linked off of their website and has worked fine for quite some time.  I haven't worked with it for awhile, but this morning I had someone ask me a question about it so I went to fire it off to take a look and now IE is bringing up the standard download dialog.  It is happening on both of my development machines.  Program still runs fine in development. I will test on a few other machines, although it appears that it may be working fine for other people.

My initial thoughts is perhaps since I installed VS2005 on these machines that since the smart client was developed under 1.1 that perhaps the 2.0 framework is causing my some grief.

Any thoughts?

Received a lot of activity recently on an older post surrounding an exception received when trying to send email.  Thought I would summarize the information in a new post to hopefully help others out there.

The problem surrounds receiving an exception

[COMException (0x80040211): The message could not be sent to the SMTP server. The transport error code was 0x800ccc15. The server response was not available]

when trying to send an email using System.Web.Mail in the framework.  The problem is caused by having McAfee VirusScan on the server and having OnAccessScan enabled (at least it was in the discussion we were having, there may be other causes that we haven't discussed.)  Thanks to David for further confirmation and too Marcel (see last comment) for the following steps to work around the issue in McAfee VirusScan Enterprise 8.0.

- go to VirusScan Console
- Right-click Access Protection
- Click "Properties"
- Go to Port-Blocking tab
- Select Rule: "Prevent mass mailing worms from sending mail"
- Click Edit (in order to edit this rule)
- Add "aspnet_wp.exe" to the exclusion list

Other products such as Norton and other antiviral or firewall software may cause the same issue, but I'll bet the underlying issue is the same.

Hope this helps others out there.

I hope to make this my new blogging home, to talk about a ton of things regarding my business and developing.  Making a home all my own giving me the freedom to tinker and modify to my hearts content.  Shoul be fun.