Efran Cobisi's Blog

.NET wonders (and alike)
Just released: a new SEO extension for the ASP.NET MVC routing engine
Dear users,

after several months of hard work, we are proud to announce to the world that Cobisi's new SEO routing engine for ASP.NET MVC has been officially released! We even provide a free edition which comes at no cost, so this is something you can't really miss if you are a serious ASP.NET developer. ;)

SEO routes for ASP.NET MVC

Cobisi SEO Extensions - this is the name of the product - is an advanced tool for software developers that allows to optimize ASP.NET MVC web applications and sites for search engines. It comes with a powerful routing engine, which extends the standard ASP.NET routing module to provide a much more flexible way to define search optimized routes, and a complete set of classes that make customizing the entire routing infrastructure very easy and cool.

In its simplest form, defining a route for an MVC action is just a matter of decorating the method with the [Route("...")] attribute and specifying the desired URL. The library will take care of the rest and set up the route accordingly; while coding routes this way, Cobisi SEO Extensions also shows how the final routes will be, without leaving the Visual Studio IDE!

Manage MVC routes with ease

In fact, Cobisi SEO Extensions integrates with the Visual Studio IDE to offer a large set of time-saving improvements targeted at ASP.NET developers. A new tool window, for example, allows to easily browse among the routes exposed by your applications, being them standard ASP.NET routes, MVC specific routes or SEO routes. The routes can be easily filtered on the fly, to ease finding the ones you are interested in. Double clicking a SEO route will even open the related ASP.NET MVC controller, at the beginning of the specified action method.

In addition to that, Cobisi SEO Extensions allows to easily understand how each SEO route is composed by showing the routing model details directly in the IDE, beneath each MVC action route.

Furthermore, Cobisi SEO Extensions helps developers to easily recognize which class is an MVC controller and which methods is an MVC action by drawing a special dashed underline mark under each items of these categories.

Developers, developers, developers, ...

We are really eager to receive your feedback and suggestions - please feel free to ping us with your comments! Thank you!


Efran Cobisi
Cobisi lead developer
Microsoft MVP, MCSD, MCAD, MCTS: SQL Server 2005, MCP
Software Technical Writer needed (C#, .NET, ASP.NET) - Part-time, telecommute

Cobisi, a young Italy-based start-up, aims to build innovative software development tools and components for the Microsoft .NET platform. We are looking for a software technical writer who can prepare documentation and code samples about our products; this is a part-time, telecommute-only position.

Job Functions

- Deliver high quality, user-friendly product documentation for customers.
- Prepare online tutorials, technical manuals, code samples, webinars, technical posts, and marketing materials as needed.
- Understand the audience for documentation deliverables.
- Ensure common look and feel across documentation as needed.

Job Requirements

- Experience with C#, .NET Framework, ASP.NET and web programming in general.
- Ability to write highly-technical software development documentation, targeted to software developers.
- Strong written and verbal communication skills in US English.
- Strong presentation skills.
- Experience developing training materials and manuals.
- Versatility in presenting technical concepts to audiences with mixed capabilities (PMs, for example).


This will start as a freelance position, 5 hours a week distributed as you wish, with the potential of developing into a regular salaried position as the company grows.


To apply for this position, please send your curriculum vitae to: work (at) cobisi (dot) com

EmailVerify.NET now part of the Cobisi family of products, new managed proxy client library, new web site
Dear readers,

the last week was a great one for us, as we have finally succeeded in building the foundation for the new Cobisi family of products. The great experience we have made in the last six years with EmailVerify.NET, our flagship .NET component for validating email addresses, led us to a way better understanding of the software development industry and its needs and still make us believe we wouldn't do anything else but developing software components (apart from listening to Dream Theater in our spare time, of course). Because of our passion and, especially, because of your precious support and always-welcomed feedback, we are now ready to show you the results of our development research and bring to you several new software components in the next few weeks.

EmailVerify.NET reached version 4.5

Our great email validation library finally reached a milestone in its development lifecycle, with version 4.5 bringing even more code robustness and great features. Check out our new free web-based ajax email validation service or just download a free trial and embed it in your own applications!

Our new .NET proxy client library

The second great news is that we now offer a new proxy client component for Microsoft .NET that allows to easily connect to a proxy server, using either a socket or a TcpClient, from your own application; Cobisi ProxyClient.NET - this is the official name for the component - currently supports the SOCKS 4, SOCKS 4a, SOCKS 5 and HTTP-CONNECT protocols, can be easily extended for custom proxy server implementations or requirements and can be, of course, easily integrated into your EmailVerify.NET solutions to support email validations using proxied connections.

And our new web site!

In the effort of a better integration with our current and future products and services, our old emailverify.net web site is now part of the main cobisi.com web site, including the client area section (previously known as customers area), the purchase section and, of course, the EmailVerify.NET overview and download section. Did I mention we also have a great new, ajax-based, free email validation service? :)

As part of this job, we also moved our hosted email validation service (a hosted service based on our email validation technologies, for email list hygiene and cleansing) to a new home, within this site.

Ah... And we have also changed a bit of the previous emailverify.net web site layout, graphics and style. Can you spot the difference? :)

Microsoft MVP award

Dear friends,

with my greatest satisfaction and pride, I'm glad to announce that I have been recently awarded as a Microsoft MVP - Most Valuable Professional - for the PowerShell category!
To me, receiving this award confirms that Microsoft strongly believe in the community commitment and in what everyone of us, in his own, can do to help his peers.

Not only the MVP award represents for me a great goal but, on top of that, it is a great starting point for an even greater experience and passion-sharing activity within the technical communities, powershell.it above all.

Thanks to all my friends at Microsoft Italy and to everyone who helps me gaining this wonderful result and thanks to Laura, my mate, for her continous support.
Finally, thanks to all of the powershell.it community users for their excitement!

Posted: Oct 14 2010, 03:36 PM by efran.cobisi | with no comments
Filed under: ,
Announcing EmailVerify.NET v4.0

We are pleased to announce the release of EmailVerify.NET v4.0!

This release adds several new features to our component and includes significant enhancements to our e-mail validation infrastructure, including:

  • New syntax validation engine, which completely avoids ReDoS (Regular expressions Denial of Service)
  • Support for quoted words and quoted pairs in addresses
  • Support for Internationalized Domain Names (IDN)
  • Support for comments and FWS sequences
  • Support for domain literals (both IPv4 and IPv6)
  • New powerful ASP.NET and Windows Forms designer (other project types can safely use the component in the standard, code-centric, way)
  • New event pattern for better asynchronous usage within Windows Forms and WPF applications
  • Revamped batch validation processing (now called VerificationTaskGroup)
  • 10 new, specific failure codes for syntax errors
  • Improved disposable e-mail address (DEA) validation
  • New ability to customize the local endpoint for SMTP connections in parallel verifications, for each specific address
  • New SQL Server 2008 Integration Services support, with a custom data transformation component
  • Improved e-mail verification results, with new and more detailed information

EmailVerify.NET website: http://www.emailverify.net
Release notes: http://www.emailverify.net/Support/Release-notes
User guide for version 4.0: http://www.emailverify.net/Support/User-guide
End-User License Agreement for version 4.0: http://www.emailverify.net/Support/Eula 

A big thanks to all of our customers around the world for their continued support! :)

Efran Cobisi
Lead Developer and Owner, EmailVerify.NET

Announcing EmailVerify.NET v3.0

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

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

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

Posted: Dec 16 2007, 12:08 PM by efran.cobisi | with 30 comment(s)
Filed under: ,
Identifying ASP.NET controls is the first step

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

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;"" />")

More Posts Next page »