The Future of ASP.NET Web Forms

by admin 17. April 2012 23:00

Web Forms - MVC ChoicesI've been working with ASP.NET Web Forms for nine years now and have acquired a comfortable familiarity with its strengths and weaknesses. We've all seen the growing popularity of ASP.NET MVC over recent years and the most common reaction is to want to play with it but when it comes time to making the switch, we often experience the "don't move my cheese" syndrome. Now that I'm finally leaning towards MVC, I'm faced with the fact that it would not be a practical option for the company I work with. I do outside work and will somehow have to find enough breathing space to move over and ramp up.

What were once the strengths of Web Forms are now clearly it's weaknesses and can not be sustained in the rich, interactive, Ajax-enabled environment we operate in today; think RAD and ViewState. This richness brings with it a level of complexity for even the most mundane of applications, and an even more compelling reason for formal testing; think more complex client-server life-cycles, asynchronous requests and you get the idea. Our stateless HTTP protocol is being dragged kicking and screaming into this error-prone battlefield and it's only going to get more complex over time. Maybe in five years, there will be a move back to the server and we'll start the whole cycle again! However, in a jungle such as this, the ViewState becomes too difficult to manage, not to mention a performance killer with an increasing payload. In addition, the page life-cycle abstraction is totally removed from the reality of a normal request/response transaction in our stateless HTTP world. Web Forms stand as proof that we can become a slave to a framework.

 

The ASP.NET Stack

 

There is no right time to make such a big paradigm switch as moving from event-driven Web Forms to the close-to-the-metal MVC architecture; the best option is often just to pick a small project and jump right in. On a personal level, it behooves me to start planning now for my learning curve and the difficulty of maintaining two different approaches to programming going forward. What is, is.

Microsoft are now talking of "One ASP.NET" where we can mix and match among the different project templates. If you wanted MVC4 scaffolding in an Web Forms site, there is nothing stop you from doing it. Scott Hanselman even alludes to it in his blog post "One ASP.NET Sneak Peek: Elegant Web Forms and Snowballs in Hell". Honestly, I think that would be the biggest architectural screw up since the Spruce Goose tried to fly. Can you imagine a novice programmer five years from now trying to get his head around a mish mash of an application like this? Some things are not good just because they're new; for example the spaghetti hell of the razor syntax. Who in their right minds would go back to mixing code with markup - lunacy, yet idiots are doing it and worse still, Microsoft are promoting it.

Microsoft are continuing to support and invest in ASP.NET Web Forms, at least that is the corporate sound bite. For years now, my take on it has been that they would make some gestural investment in it in the form of trivial new features but basically let it die it's own death. Don't get me wrong, it will be around for a long time to come and has it's place. But Microsoft does not want a repeat of the fiasco they found themselves in when they deprecated the Web Forms project template for the release of VS 2005. The outcry from developers was such that they had to endure the public embarassment of scrambling to do a 180-degree turn with the SP1 release to re-introduce it.

For me the biggest selling point for Web Forms is how productive it makes me. For the vast majority of projects I work on, it is still the best fit. Each of these approaches to Web development have their place. The trick is being honest enough with yourself when trying to make a rational decision. I see Web Forms largely out of the picture within the 3/5 year range and I am planning accordingly. They may still exist but people won't be choosing to work with them. Would you choose Cobol for your next business application? I thought so...




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#



ASP.NET Programming Tips - Tip #1

by agrace 26. September 2010 09:20

Google Cannot Solve your Coding Problems

Using GoogleStop and think before you do this. Googling for code samples is usually the final step when designing solutions. Start by defining the problem; if you can't define the problem, how can you solve it? Then, and only then, start working on a black-box solution of your own; identify the basic inputs, general logic (phrase it in a single sentence - this is the black box), and outputs of this black box. Even if you're not artistically inclined, always opt to take pencil to paper - it will help.

Finally, with a clearer perception of what it is you need to do, use Google to focus in on relevant code samples. Doing this in reverse order leads us to try and re-imagine the problem to fit somebody else's solution. I imagine 80/90% of programmers, myself included, are guilty of this everyday form of insanity.

kick it on DotNetKicks.com