Efran Cobisi's Blog

Announcing EmailVerify.NET v3.0

efran.cobisi — Thu, 29 Oct 2009 18:21:00 GMT

As the company lead developer, I'm proud to announce to my readers that our award winning e-mail verification and validation component for Microsoft .NET has reached version 3.0 today!
This new version includes an improved disposable e-mail address validation algorithm and built-in Windows PowerShell support.

Top features:

E-mail syntax verification, according to RFC 2821 and RFC 2822
MX record lookup
Disposable e-mail address (DEA) validation
SMTP availability check
Mailbox existence check, with greylisting support
Catch-all test
Windows PowerShell built-in support
Batch verification capabilities (for multithreaded, parallel validations)
Fully configurable in every setting, including network ones

EmailVerify.NET can be used, of course, within any kind of project, whether it is Windows Forms, Windows Presentation Foundation (WPF) or console based, ASP.NET based or a class library.
It requires .NET 2.0 or newer and runs wherever the framework runs, including Windows Server 2008 and Windows 7, both 32 bit and 64 bit.

For additional details please see EmailVerify.NET web site.
There's also a free trial available for download and an online ajax-based demo to test its functionalities without having to download anything.

My company is hiring in Padova, Italy

efran.cobisi — Mon, 10 Mar 2008 10:13:00 GMT

QBGROUP spa, the company I work for, is hiring new .NET (ASP.NET/AJAX) developers. If you are interested and willing to move to Padova, Italy (a city next to Venice), please drop me a line or send us your resume via our web form. Fluency in written and spoken Italian language is a prerequisite.

2008-05-05 Update: Those two positions have now been filled.

My tutorial on ASP.NET AJAX custom control development is now online

efran.cobisi — Sun, 16 Dec 2007 11:08:00 GMT

After some weeks busy on collecting documentation and dissecting Microsoft's own libraries, I've finally reached the point where I could share my experience about ASP.NET AJAX with my peers; so I published a (quite big) tutorial for ASPItalia (an Italian ASP.NET community) about developing an ASP.NET AJAX custom control, releasing it in two parts, due to its length.

For those of you who are comfortable with the Italian language here are the links for both the parts:

Part #1: http://www.aspitalia.com/articoli/asp.net2/ajax-custom-control.aspx
Part #2: http://www.aspitalia.com/articoli/asp.net2/ajax-custom-control-2.aspx

If you can't speak Italian please add a comment to this post: if I'd receive enough feedback I would propably translate and place it somewhere else (codeproject?). ;)
In the meantime, I've included the links for the Google-translated versions:

Part #1: http://www.google.com/translate?u=http%3A%2F%2Fwww.aspitalia.com%2Farticoli%2Fasp.net2%2Fajax-custom-control.aspx&langpair=it%7Cen
Part #2: http://www.google.com/translate?u=http%3A%2F%2Fwww.aspitalia.com%2Farticoli%2Fasp.net2%2Fajax-custom-control-2.aspx&langpair=it%7Cen

Identifying ASP.NET controls is the first step

efran.cobisi — Thu, 30 Aug 2007 12:07:00 GMT

Every time I build an ASP.NET web form, I invest a certain amount of my development effort in giving each control a meaningful identifier. This practice tends to give back cleaner code, leading the whole code base more mainteinable. And, as you probably know, code mainteinability is a key rule to cut down the total cost of ownership (TCO) of software projects.

I've seen, however, a worrying number of ASP.NET developers who simply do not care about control naming and leave their code full of meaningless identifiers. So, for example, many tend to name their controls after the flow they follow inside the page: HeadLabel, BodyLabel, FooterLabel and so on. Many prefer to use Visual Studio designer and leave it automatically generate identifiers for their controls: this way, each control identifier would be made of a common type prefix, optionally defined by a ToolboxData attribute, and an incremental number (ie. Label1, Label2, and so on). These habits, which could effectively deflate the effort required to build a demo or a very small project, would eventually have the opposite effect in greater projects; trying to find out which of your 100 labels is the right one is like looking for a needle in a haystack.

As general code naming rules suggest, a better approach consists in thinking about what your controls are about and what they are used for within the hosting page. Given that, you have a starting point you could use to give your controls a correct identifier; the string you would eventually come up with is usually made up of one to three-four combined words, in pascal case, for example: TotalAmount, Result, LastInsertedAlert, etc.
Many developers (me included) then tend to prefix this string with a small one (usually two to four characters in length), that should make clear the type of the control at the final users (yes, you included). This practice, which has its roots in the Hungarian code notation, a naming convention created by Microsoft's Charles Simonyi, actually lead to self-describing control identifiers. So, following this convention, a label identifier could be for example lblTotalAmount, where the "lbl" prefix is there just to tell the reader that it is a Label control and the rest of the identifier tells her its purpose. A big improvement over seeing your code full of Label1, Label2, Labeln, eh?

A nice side effect of this good habit is that, whenever you need to access a certain type of control inside your code, you could just type its control prefix (lbl, in my example) and have Visual Studio Intellisense help you, listing all of the labels contained within your page or control.
Even if Microsoft is moving away from the Hungarian code notation in .NET, I think this convention is still very useful with this kind of naming issue.

Here is a short list of prefixes I use in order to give an identifier to my controls:

Control type	Prefix	Examples of use
System.Web.UI.WebControls.Label	lbl	lblAmount, lblGrossPrice
System.Web.UI.WebControls.Panel	pnl	pnlDetails, pnlMain
System.Web.UI.WebControls.Button	btn	btnConfirm
System.Web.UI.WebControls.HyperLink	lnk	lnkAuthorInfo
System.Web.UI.WebControls.Placeholder	hld	hldDetails
System.Web.UI.WebControls.DataGrid	dg	dgCustomers, dgCustomerOrders
System.Web.UI.WebControls.GridView	gv	gvCustomers, gvCustomerOrders
System.Web.UI.WebControls.DropDownList	ddl	ddlStates, ddlJobOptions
System.Web.UI.WebControls.Repeater	rpt	rptDetails
System.Web.UI.WebControls.CheckBox	chk	chkNonSmokingRoom, chkWantsNotification
System.Web.UI.WebControls.Table	tbl	tblDetails
System.Web.UI.WebControls.Menu	mnu	mnuMain, mnuContext
System.Web.UI.WebControls.Wizard	wiz	wizUserRegistration

Beside naming conventions, however, the most important thing to consider while you are giving your controls an identifier is consistency. Whatever technique you adopt, if you are consistent within your code you will eventually end up with more mainteinable software projects.

A simple PowerShell script to find and replace using regular expressions in multiple files

efran.cobisi — Thu, 17 May 2007 13:24:00 GMT

One thing I need which I come across from time to time is the ability to perform a find and replace operation in multiple files, using regular expressions. When this happens, I usually tend to exploit Visual Studio's own support for this kind of necessity; soon, however, I have to give it up and blame my favorite IDE for the lack of adherence with the regular expressions syntax adopted by the .NET framework, which I'm used to.
So, today, after my umpteenth unsuccessful attempt with Visual Studio, I resolved to implement a simple PowerShell script stub, which would act as a strating point for performing this job for me hereafter. No, this is not by far a complete grep-like tool; I would like it to be just a demonstration of how easy, powerful and "clean" are PowerShell scripts like this one. And yes, I know there is plenty of third party tools which do this kind of things...

To go down into the specifics of my problem, I was trying to combine a set of html files, that I grabbed after a CHM to HTM conversion, into a single one; since images inside these documents are just thumbnails contained inside an hyperlink which let the user eventually click to see the image at the original size, I want to perform some regular expressions substitution in order to have the original size image embedded directly into the document, have the thumbnails removed and the header and footer of each individual html file removed before being combined into the target one.
Since PowerShell is a .NET managed shell, we can naturally use our beloved Regex class to perform our regular expressions substitution, thus adopting the syntax we are accustomed with.

Here's the code which today solved my problem; feel free to use it as the starting point for similar issues:


$rxFigure = New-Object System.Text.RegularExpressions.Regex "(?:\<span.class=""figure""\>)\<a.href=""(?<Url>.*?)"".*?\>\</a>"
$rxHeader = New-Object System.Text.RegularExpressions.Regex "<html>.*?</table>", SingleLine
$rxFooter = New-Object System.Text.RegularExpressions.Regex "<table.*?</html>", SingleLine
$combinedOutput = [System.IO.File]::CreateText([System.IO.Path]::Combine((Get-Location).Path, "..\Combined.htm"))

Get-Item "*.html" | ForEach-Object {
    $text = [System.IO.File]::ReadAllText($_.FullName)
    $text = $rxFigure.Replace($text, "<img src=""`${Url}"" />")
    $text = $rxHeader.Replace($text, "")
    $text = $rxFooter.Replace($text, "<br style=""page-break-after: always;"" />")
    
    $combinedOutput.Write($text);
}

$combinedOutput.Close()

Panel's DefaultButton whims: not every IButtonControl is the same...

efran.cobisi — Thu, 15 Mar 2007 12:49:00 GMT

Today's story begins with a poor developer trying to obey his creative director new guidances in terms of how that web application should have its buttons rendered. I will omit the motivation behind this decision, because it is not relevant to this post's subject.
The creative director said: "Hey, I'd like them to be rendered as html anchors!". The poor developer replied saying: "I can't see any difference, what about leaving them as they are (html input buttons)?". And the other: "Well, we can apply CSS styles better to html anchors than to html input buttons!".
So, the poor developer started reflecting his creative director desires.
After some hours spent in playing nicely with the new html anchor based buttons, something hurt the poor developer heart: all the Panels which uses the DefaultButton property in the web application and previously worked well now started behaving in a strange manner. To his amazement, the poor developer discovered that all of the DefaultButtons now worked only in Internet Explorer. Oh my... What about that cross browser thing?

Let's help that poor developer.

Whenever you use the DefaultButton property of the Panel control, you can choose among a set of ready to use controls which could act as buttons, all of them implementing the IButtonControl interface. At runtime, the Panel control registers a client script which would fire that default button, upon the user has hitted the enter key inside one of the html element hosted inside that Panel.
The client function which handles the keypress event for the Panel client element is WebForm_FireDefaultButton. Here's its body:

var __defaultFired = false;
function WebForm_FireDefaultButton(event, target) {
    if (!__defaultFired && event.keyCode == 13 && !(event.srcElement && (event.srcElement.tagName.toLowerCase() == "textarea"))) {
        var defaultButton;
        if (__nonMSDOMBrowser) {
            defaultButton = document.getElementById(target);
        }
        else {
            defaultButton = document.all[target];
        }
        if (defaultButton && typeof(defaultButton.click) != "undefined") {
            __defaultFired = true;
            defaultButton.click();
            event.cancelBubble = true;
            if (event.stopPropagation) event.stopPropagation();
            return false;
        }
    }
    return true;
}

As you could see, it checks (among other things) if the default button "click" property is defined before getting the work done. Unluckily, and this is the culprit of our poor developer pain, the "click" property is not supported by every IButtonControl rendered html element. In fact, html anchors seem to not support that property (yes, IE does support it, but we wanted it to be cross browser, do you remember?).
So, how could we solve this problem and make DefaultProperty works with... say... FireFox? One way could be to redefine WebForm_FireDefaultButton and make it smarter than the original one; we could check for the "click" property first and then for the "href" property, which html anchors have.

So, here's a little smarter reimplementation of the aforementioned client function, ready to be pasted in your web page or client script file:

function WebForm_FireDefaultButton(event, target) {
    if (!__defaultFired && event.keyCode == 13 && !(event.srcElement && (event.srcElement.tagName.toLowerCase() == "textarea"))) {
        var defaultButton;
        if (__nonMSDOMBrowser)
            defaultButton = document.getElementById(target);
        else
            defaultButton = document.all[target];

        if (typeof(defaultButton.click) != "undefined") {
            __defaultFired = true;
            defaultButton.click();
            event.cancelBubble = true;
            
            if (event.stopPropagation) event.stopPropagation();
            return false;
        }

        if (typeof(defaultButton.href) != "undefined") {
            __defaultFired = true;
            eval(defaultButton.href.substr(11));
            event.cancelBubble = true;
            
            if (event.stopPropagation) event.stopPropagation();
            return false;
        }

    }
    return true;
}

As all of the postback event references begin with the "javascript :" fake protocol, we could get the href of the DefaultButton, strip that protocol prefix and evaluate the rest. That will perform our craved postback, in a cross browser way.

And our poor developer is finally happy. Now guess who was that poor developer... :)

Weird trap while using WebForm_DoCallback() inside my external client scripts

efran.cobisi — Mon, 05 Mar 2007 12:23:00 GMT

Today, while I was trying to move large portions of a web application I'm working on from Ajax.NET to ASP.NET AJAX and callback support, I've bumbed into a weird trap related to how callback targets are resolved at server side.
The story begins with me trying to adapt a custom control in such a way that events that originally got fired at client side through the elegant Ajax.NET APIs would instead get fired via ASP.NET callback; the reason behind this decision is twofold.
First of all, I've chosen to leave behind Ajax.NET because I'd like to start using a "standard" library for my ajax behaviors. Even if I've never run into any problems using Ajax.NET and I've loved it for quite some time, I hope Microsoft will make their best effort to support and integrate this platform inside the ASP.NET framework, even better than any other ISV could. Then, why callbacks and not, for example, async postbacks? Well, to my surprise, I've ascertained async postbacks are quite verbose in their communications. Since my project goals include saving as much bandwidth as possible, I've looked for an alternative. Callbacks come to my rescue... And average payloads of this technology are very similar to Ajax.NET ones.

Back to my original problem. I started preparing my control for callbacks support: I've coded its implementetion for ICallbackEventHandler interface and called ClientScript.GetCallbackEventReference() in its OnInit (...in vain, just to setup the callback support. Very annoying!). Now I was trying to use the WebForm_DoCallback function inside my javascript code; yes, I'm using an external script file, so I've no way to use the ClientScript.GetCallbackEventReference() method to obtain what I was looking for.
At first, it seems WebForm_DoCallback expects the control ID of the target as its first argument. So, I've retrieved the control's ClientID and fed WebForm_DoCallback with it. Everything worked as expected and I was very happy: the test page that was hosting my control played very nice.
But, suddenly after I've moved my control inside another page, a page which uses a master page, the trick ceased to work. After my callback started, the page on the server side answer with an exception saying: "The target ... for the callback could not be found or did not implement ICallbackEventHandler.".
I will not tell you how much time I've spent in trying to understand what was wrong with my code...

In short, the answer to my problem was that WebForm_DoCallback() does expect the UniqueID of the target control, not the ClientID. If you miss this point, you will get callback support that wouldn't work with master pages!

Very easy to fall into this trap...

Tips about exam 70-431 (MCTS: SQL Server 2005)

efran.cobisi — Mon, 19 Feb 2007 13:43:00 GMT

On Friday, 9 February, 2007 at about 11:30 AM I passed exam 70-431 and earned the title of MCTS: SQL Server 2005; now that the excitement is growing dim, I'd like to take the time to share my impressions on the new certification model embraced by Microsoft.
First of all, I've been quite impressed by the number of simulations included in the exam. For those of you who are wondering, simulations are a (relatively) new kind of questions, very different from the usual multiple choice ones we were used to face in the past: they consist in a series of interactive screens which (almost) closely resemble the ones you should see while working with the GUI tools included with SQL Server 2005. So, to pass this kind of questions, you should be familiar with these tools.

I must confess, I was always used to think a good DBA should know how to get the job done without GUI tools. As a professional developer, I like very much to code; and I like to work with my SQL Server using just clean TSQL statements. But the truth is that GUI tools often quicken the steps needed to do complete everyday jobs: think about restoring a database which has say 20 transactional backups to restore in order to get it functional... Admit it, how many lines of TSQL code are you going to type? Isn't it faster to click 4 buttons inside Management Studio? Sure, and Microsoft realized it. So, to pass this exam you should also know where to watch inside and how to work with Management Studio, Configuration Manager, Surface Area Configuration and the Profiler.
To my surprise, the number of questions regarding system views (most importantly the objects belonging to the sys schema) was bigger than the number of DML/DDL related questions; I think one of the most important requirement of this exam is to prove the attendee really knows how to check for performance problems inside SQL Server and how to fix them. Index creation and mainteinance is also very important: you should really know how indexes work, clustered vs. non clustered indexes differences and how they relate to performance, columns inclusion inside them, XML indexes (primary, kinds of secondary); two or so of the questions related to full text indexes mainteinance and updates. The total number of questions for my exam was 52.

The result of my exam really dazzled me; I got a 1000/1000 points! Since I'm a developer, I wasn't expecting so much from an exam which should belong more to a system administrator than to my role.
I prepared for the exam with the aid of two books (and Books Online, of course!): MCTS SQL Server 2005 - Self paced training kit from Microsoft Press and MCTS Microsoft SQL Server 2005 - Implementation and Maintenance from Sybex. Both are really good books but I found the Sybex one to be clearer in some aspects; the Microsoft Press one is really detailed and sometimes could lend you to confusion. My advice is to buy both the books and grab the core concepts from the Sybex book and deepen with the Microsoft one.