Solution Explorer Recently I had to send an email blast out to about two thousand email subscribers from a client's ASP.NET Web Forms application. The client had an admin form where they would compose and send out the email. Unfortunately, with that many emails the Web form would inevitably hang. Plus, with Exchange Server there is no easy way to know how many emails actually got sent; you could use Powershell to determine this or you could log it but it still isn't a robust way of doing things.

The conventional wisdom is to use a third party service for mass mailings and most times this is probably your best option. In this situation, an email blast is only sent every 5 years so it really didn't make sense to enrol in a monthly plan. With a little due diligence, this can be accomplished with a very simple console application which can be called from the Web form to dispatch the emails.

The basic design is that the subject line and email body text are entered in the form and passed to the console application as string parameters. In the console app, we can obtain the email addresses from a database and send the emails out in batches with a pause between each batch.

Some basics first: the entry point to any console application is the Main method:

// Mailer class in console application

static void Main(string[] args)
{
    if (args.Length >= 2)
    {
        SmtpClient smtpClient = new SmtpClient(EMAIL_HOST);
        smtpClient.Host = "localhost";

        MailMessage message = new MailMessage();
        message.Priority = MailPriority.High;
        message.Subject = args[0];
        message.Body = args[1];
        smtpClient.Send(FROM_ADDRESS, TO_ADDRESS, message.Subject, message.Body);
    }
}

The array of strings args parameter corresponds directly to the command line parameters passed to the console application; string[0] is the first parameter, strg[1] is the second parameter and so on. This is different in C and C++, where the name of the console application itself is the first parameter... when in doubt, try it out!

Note that when testing this on the command line initially, that there is a limitation on the size of the strings you can pass. This will not apply when sending the parameters programmatically from the Web form code-behind. You can test that your console app is sending emails by creating a drop folder on your C drive. Download and install Live Mail to view the .eml files generated. You can create a dummy gmail account to get this running and choose not to make Live Mail your default email client during the install (if this is your preference). This is a really simple and useful way to test email functionality locally on your dev machine. Just update your Web.Config file with the following to get it working:

<system.net>
    <mailSettings>
        <smtp deliveryMethod="SpecifiedPickupDirectory">
            <specifiedPickupDirectory pickupDirectoryLocation="c:\maildrop" />
        </smtp>
    </mailSettings>
</system.net>

To generate a test email with the console app and pass the subject and body parameters, call it like this:

// DOS command line

C:\>ConsoleApplication1 "Subject Line Text" "Some body text"

To call the console app from the Web form code-behind we use the Process.Start method. We can avail of the ProcessStartInfo class to set up any properties in advance of making the process call.

// Web form code-behind
// Pass subject and message strings as params to console app

ProcessStartInfo info = new ProcessStartInfo();

string arguments = String.Format(@"""{0}"" ""{1}""",
     subjectText.Text.Replace(@"""", @""""""),
     messageText.Text.Replace(@"""", @""""""));
info.FileName = MAILER_FILEPATH;

Process process = Process.Start(info.FileName, arguments);
Process.Start(info);

We also need to take account of the possibility of quotes being included in the subject line or body text. I enlisted some help on this issue with a StackOverflow question. The solution was a combination of composite string formatting and verbatim "@" string literals. See the String.Format call in the code snippet above.

 

Email Form

If you've been testing the console app and then go on to debugging with VS, you may come up against a file locking issue. This issue is a known bug - I've seen bug reports going back to 2006 on this one.

Error 9 Unable to copy file "obj\x86\Debug\ConsoleApplication1.exe" to "bin \Debug\ConsoleApplication1.exe". The process cannot access the file 'bin\Debug\ConsoleApplication1.exe' because it is being used by another process.

 

Processes

There are two workarounds to this. My way is to close out VS and then kill any remaining processes for the console app: Windows Task Manager -> Processes tab -> Show processes from all users -> right- click each process and kill it (End Process). The second method is to add a pre-build script as described here.

Tags: , ,

ASP.NET | C#




Golden Ratio This article by Ethan Marcotte on Responsive Web Design has been widely touted as the designer's panacea for all things mobile. Other leading designers such as Jeffrey Zeldman and Andy Clarke have all jumped on the band wagon. Considering the amount of influence these guys have on young designers, it saddens me that leading designers, of all people, would sacrifice their art on the altar of a quick fix.

Progressive Enhancement is the accepted philosophical approach to Web development today and demands an increased time investment on the part of Web Designers and Developers. Speaking as a Developer/Designer - yes, I'm one of those "Devigner" unicorns - with a background in ASP.NET Web Forms (gasp), I have finally accepted that my future will involve a return to the three-legged stool of all Web work: HTML5, CSS3 and JavaScript. Because of the importance of Progressive Enhancement and the extra time constraints it poses on any kind of Web project, I am justifiably wary of any and all new fads and buzz words that crop up like a bad outbreak of acne.

So what exactly is Responsive Web Design? In short, it's a technique that adapts a website's layout for multiple screen resolutions using a combination of fluid grids, images and media. CSS3 Media queries are then applied to toggle the layout width in response to the device width. The idea is to take a desktop version of the site and narrow it to fit in the smallest browser - set width breakpoints using media queries, say for mobile, tablet and desktop. This is akin to putting lipstick on a pig, not to mention the scrolling effect the user has to endure on smaller devices.

The focus of this post is on the "fluid" part of RWD and its disastrous consequences on the esthetics of any website built in this manner - designers should be able to get this. The technical problems with RWD are many and varied and have been well documented by others.  First off, here's a simple overview of the technical limitations:

1) Media queries are applied after content has been downloaded. This means that even for a mobile version, all markup, CSS, images and scripts are still downloaded. Considering the bandwidth limitations of most mobiles, this is a performance showstopper.

2) Media queries are not supported by legacy browsers or by most mobile handsets.

3) Fluid images are also a performance killer - you download images at their maximum size and set a maximum percentage width for them, leaving the browser to resize the images as needed - CPU intensive.

The Fluid vs Fixed debate started in the 90s and it's not my intention to fan those flames. Personally, I have always detested fluid layouts; they are anathema to good page composition. Between a mobile browser and a desktop one, there exists an almost infinite range of browser sizes outside of the break point widths used by your media queries. For any of these in-between browser widths, fluid layouts are going to change the composition of your page. And adding even more script to make your images fluid in order to compensate is only adding insult to injury - you just can't fix stupid.

Remember the time constraints imposed by Progressive Enhancement I mentioned earlier - where would you rather invest development time? Do you seriously think that a real world client is going to swallow this extra cost? Real life is all about priorities.

The Desktop and the Mobile are Two Different Animals

The Desktop and the Mobile are Different Animals There is too much over-analyzing of words like "context" going on these days. Is the user going to be lying on the couch or standing in line at the cinema when they access the site? Context? Bullcrap. Don't insult the user - they can figure out how best to use their devices - all we have to do is make sure that we don't try to display something in a smart phone that defies common sense - like 2MB PDF map downloads. And always include a link to the desktop version of the website. It's not rocket science but smart phones and desktops PCs are worlds apart, and it should be obvious that in most cases the mobile version of a website demands to be created separately and given individual attention. In addition, if future development or design enhancements need to be made to the mobile version, creating it separately makes total sense. Re-skinning a desktop version of a website and calling it mobile-ready makes as much sense as asking a whore for a hug.

The RWD zealots often use the "One Web" argument, citing Tim Berners-Lee:

    "The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection."

Henry Ford may have been the first to mass produce the automobile but that doesn't mean I'm going to take driving lessons from him. One Web proponents also misquote the W3C in support of their argument. Here is a direct extract from the W3C on One Web:

    "One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts."

In fairness to the designers mentioned at the start of this article, a few of them have come out recently and advocated a more judicious use of RWD and basically said that each case should be taken on its own particular merits. This may be a little too late in my opinion and I think that Web professionals should think before they speak. RWD as an alternative approach to multi-device layouts fails in so many respects, both technical and esthetic, that it cannot be considered as a responsible approach to Web development going forward. In our world, there is no silver bullet. The myriad of Web-enabled devices out there demand extra work and this is a fact of life.

If you're still not convinced, here's a sobering thought: speed is going to be a make or break factor in all websites going forward. After your client gets past the initial "oohs" and "aahs" of viewing their new site on their iPhone, try explaining to them why their new, expensive site cannot be found via Google search...

Recommended Reading:

Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
Designing with Progressive Enhancement: Building the Web that Works for Everyone
11 reasons why Responsive Design isn’t that cool!
Why Separate Mobile & Desktop Web Pages?



ASP.NET Programming Tips - Tip #2

by agrace 30. September 2010 22:39

Double your BlogEngine Traffic in 60 Seconds

BlogEngine SEOSome time ago, I blogged about the increasing importance of performance, read page load speed, in the determination of "rank" by Google.

Then I noticed that most of my blog posts included an image and that there was a considerable lag, so I decided the quickest method of fixing this was to simply go into my settings and decrease the number of posts per page from five to three.

In just five months, the number of hits per months has gone from 9,977 for May to 13,542 for September, a 35% increase. In that time period, there were only three blog posts put out. Draw your own conclusions!

Tags: ,

SEO