As I mentioned here, codebeater was hacked over the weekend. Apparently, there was a flaw that would allow username and passwords to be viewed in plain text by simply viewing a specific url.  I am very disappointed to learn that this information is being stored in it's raw form in BlogEngine.NET.  However, kudos to the BlogEngine team for responding to the flaw as quickly as they did.  Unfortunately, I received word of the fix a little too late.  My site had not only been defaced but all content had been deleted. 

If you are using BlogEngine.NET 1.3.0.0 please update your site to the latest version immediately.  You can read more about this exploit here.

P.S.  I've restored much of my previous data, although it does not appear in it's proper chronological order.

ASP.NET processes requests using a pipeline model which makes use of HttpModules and HttpHandlers to process all requests.  When you configure your ASP.NET application to use an HttpModule you're effectively inserting that module into the request pipeline.  This creates a scenario where each request must pass through all of the loaded HttpModules before it can get to the HttpHandler for the request.  If you add ten HttpModules the request will have to pass through all ten modules before it gets to the HttpHandler.

By default, ASP.NET is configured to load several modules that you may or may not be using.  I expected to find this in machine.config but on my machine it wasn't there, instead I located this setting in the WINDOWS\Microsoft.NET\Framework\$VERSION$\CONFIG\Web.Config file with the following entries:

   1:  <httpModules>

   2:        <add name="OutputCache" type="System.Web.Caching.OutputCacheModule"/>

   3:        <add name="Session" type="System.Web.SessionState.SessionStateModule"/>

   4:        <add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule"/>

   5:        <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"/>

   6:        <add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule"/>

   7:        <add name="RoleManager" type="System.Web.Security.RoleManagerModule"/>

   8:        <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"/>

   9:        <add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule"/>

  10:        <add name="AnonymousIdentification" type="System.Web.Security.AnonymousIdentificationModule"/>

  11:        <add name="Profile" type="System.Web.Profile.ProfileModule"/>

  12:        <add name="ErrorHandlerModule" type="System.Web.Mobile.ErrorHandlerModule, System.Web.Mobile, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

  13:        <add name="ServiceModel" type="System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

  14:      </httpModules>

Another way to determine this is to insert a little code into your application to iterate the currently loaded modules:

   1:  protected void Page_Load(object sender, EventArgs e)

   2:      {

   3:          StringBuilder sb = new StringBuilder();

   4:          foreach (string module in ApplicationInstance.Modules.Keys)

   5:          {

   6:              sb.Append(module);

   7:              sb.Append("<br/>");

   8:          }

   9:          Response.Write(sb.ToString());

  10:   

  11:      }

It's likely that you don't need many of these modules.  For example, if you're not making use of the ASP.NET Membership provider then you have an HttpModule sitting in your pipeline running some unneeded code on every request.  It's generally not a good idea to change settings in machine.config or the root Web.Config but ASP.NET provides an easy way to override these settings.  Modules loaded as a result of machine.config can be unloaded from your application by specifying in the <HttpModules> element of your web.config which modules to <remove>.  Just be sure to only remove those items that you don't need.

   1:  <httpModules>

   2:       <remove name="FormsAuthenticationModule"/>

   3:       <remove name="WindowsAuthentication" />

   4:       <remove name="PassportAuthentication" />

   5:       <remove name="Profile" />

   6:  </httpModules>

Seems pretty simple, right?  Well, that's because it is.  This will likely not give you huge performance gains but considering each loaded HttpModule is executed during each and every request, every little bit will help.

Jose Fajardo posted a step-by-step tutorial on how to build a Windows Live Messenger Login using Silverlight / XAML.  Definitely worth taking a look at.

When IE7 came out one of the first things I thought was "wouldn't it be awesome if windows explorer had tabs like this?". Well, apparently I'm not the only one that had that thought. QTTabBar is a program written in C# that adds tabbed browsing to windows explorer on both Windows Vista and Windows XP (requires .net framework 2.0). I'm looking forward to trying it.

Kigg is a very cool sample application developed by Kazi Manzu Rashid using the new ASP.NET MVC Framework.  Kigg is developed with:

• Regular Web Forms for View.
• LINQ to SQL for developing the model.
• ASP.NET Ajax for Ajax operation.
• Both VSTest and NUnit for Unit Test.
• Rhino Mock.

Check out the live version running in DotNetSlackers.

Check out Kazi Manzu Rashid's blog.

Check out the project hosted on CodePlex.

One of the new features in the .NET framework is extension methods.  Extension methods allow you to extend existing types by adding new methods without using inheritance.  Their implementation is trivial and, with a little creativity, it's very easy to find ways in which extension methods can add new functionality to existing types.  Ever wish a variable could have an "IsNull" method?  It's quite easy to add something like this using extension methods.

To create an extension method you create a static class with a static method that takes as it's parameter the type you wish to extend, which you can see in the following example:

NOTE:  In the following example I extend several different types within the same class\namespace.  I think it's probably advisable to avoid doing this and group your items appropriately.

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;

namespace ExtensionMethods
{
    public static class MyExtensionMethods
    {

        /// <summary>
        /// Indicates whether the specified <see cref="T:System.Data.DataTable"></see> object is null or empty.
        /// </summary>
        /// <param name="dt">The DataTable to be evaluated</param>
        /// <returns>True if the DataTable is null or contains no rows, otherwise false.</returns>
        public static bool IsNullOrEmpty(this DataTable dt) 
        {
            if ((dt == null) || (dt.Rows.Count < 1))
            {
                return true;
            }

            return false;
        }

        /// <summary>
        /// Indicates whether the specified <see cref=""T:System.Object"></see> is null.
        /// </summary>
        /// <param name="obj">The object to be evaluated.</param>
        /// <returns>True if the object is null, otherwise false.</returns>
        public static bool IsNull(this object obj)
        {
            return (obj == null);
        }


        /// <summary>Indicates whether the specified <see cref="T:System.String"></see> object is null or an <see cref="F:System.String.Empty"></see> string.</summary>
        /// <returns>true if the value parameter is null or an empty string (""); otherwise, false.</returns>
        /// <param name="value">A <see cref="T:System.String"></see> reference. </param>
        public static bool IsNullOrEmpty(this string s)
        {
            return (string.IsNullOrEmpty(s));
        }
    }
}

In this class I've extended three types;  DataTable, Object, and String.  I can think of some much better uses, such as an "IsValidEmailAddress" method to extend String, or one that I've seen posted by others "IsRegExMatch".  I chose these particular examples because I feel they help convey the ease in which extension methods can be created to add missing functionality or to simply make existing functionality accessible in a different way.  I realize the methods in the example are not very useful or creative, but the point is simply to demonstrate what can be done.

To make use of the extension methods you've created you need to do nothing more than add a "using" to import the namespace containing your extention methods.  For example:

using ExtensionMethods;

Once you've added the "using", all of the extension methods within that namespace are now available to use:

If you haven't looked at extension methods before you may be curious if an "IsNull" extension method will work on a null object and the answer is yes, it does. 

As much as I can appreciate extension methods, I can see where some may prefer to have a separate Utility class. Perhaps they find this approach easier to understand. maintain, or discover.  Personally, I believe they should be used sparingly and with a careful eye to avoid creating code discovery problems.  Also there's some debate as to whether they should be used at all on classes you control, as opposed to intrinsic framework types or those found in third party libraries.  Certainly there is the potential to use them irresponsibly, as is the case with many things within the framework, so just use good judgement.  As with anything, I'm sure extension methods will have their share of both lover's and hater's.  What's your take?

Apparently some people are pretty upset about the Ctrl+Tab document navigator in Visual Studio 2008 (One blogger claimed Visual Studio 2008 was crap because of this feature). Well, if you're one of those people, there's good news. You can turn this feature off quite easily. Just check out Sara Ford's Weblog for instructions. Personally, I kind of like this feature. If they had added the ability to scroll through the docs with the mousewheel I'd probably use it a little more often. However, I tend to use the mouse for most of my navigation anyway so...

What's your thought, like it or hate it?

Standard Regular Expression usage in .NET is the interpreted variety.  In my experience "interpreted" typically means less-than-optimal performance.  The purpose of this post is to describe how to precompile or inline your regular expressions for better performance.  I'm not going to make the argument for or against regular expressions vs. handwritten parsing code, you can search for those answers elsewhere.

It probably doesn't make much sense to even worry about this when your regular expressions will be used only infrequently,  However, if you have expressions that are executed frequently, as in a loop or something, you may find that interpreted regular expressions can drag you down a bit.

Pros and Cons

• Interpreted Regular Expressions start quickly but will not perform optimally at runtime.
• Precompiled Regular Expressions require a little more start time but provide improved runtime performance.  If you have an expression that is executed frequently, you may want to consider this option.  I've read that precompiled regular expressions perform 30% improved performance over the interpreted variety.
• Inline Regular Expressions creates an entirely new assembly that provides the benefits of improved start time as wells as the benefits of precompiled expressions.  Since a new assembly is created it can be reused across applications, which is always, IMO, a good thing.

In the following three examples I will show how to do each with a simple regular expression that checks for a valid email address.

• Interpreted

public bool IsValidEmailAddress(string email)
{
    Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");
    return regex.IsMatch(email);
}

• Compiled

public bool IsValidEmailAddress(string email)
{
    Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$",RegexOptions.Compiled);
    return regex.IsMatch(email);
}

• Inline

Ok, this one's a little, but not much, more complicated.  The goal here is to create an assembly with your expressions built into it.  For my email validation expression we can do this:

 

RegexCompilationInfo regexInfo = new RegexCompilationInfo(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$", RegexOptions.None, "EmailExpression", "MyRegEx", true);
Regex.CompileToAssembly(new RegexCompilationInfo[] { regexInfo }, new AssemblyName("MyRegEx"));

 

This will create an assembly named "MyRegEx.dll" in your Bin directory (see image below).  Then, from the application that will use this assembly you can add a reference to your new regular expression assembly.

 

Making use of the new assembly is quite easy:

private bool IsValidEmailAddress(string email)
{
    MyRegEx.EmailExpression ee = new MyRegEx.EmailExpression();
    return ee.IsMatch(email);
}

That's it.  Pretty simple, eh?

In my previous article about extension methods I discussed how to implement them only in C#, as I had not yet looked at them in Visual Basic.  Today I decided to finally take a look and was expecting something similar to how it is implemented in C# but what I found was different enough to warrant talking about it again, I believe.  Anyway, let's get to it.

The first big difference I notice is that, in Visual Basic, you must define extension methods in a module.  I'm not sure why this is the case, but it is.  The second difference is that you must mark your extension methods with the extension attribute <Extension()> from the System.Runtime.CompilerServices namespace.  So once you have your module and you've imported the System.Runtime.CompilerServices namespace you're ready to create an extension method.  Here's the Visual Basic version of a sample extension from Scott Guthrie's blog:

Imports System.Text.RegularExpressions
Imports System.Runtime.CompilerServices

Module MyExtensions

    <Extension()> _
    Public Function IsValidEmailAddress(ByVal s As String) As Boolean
        Dim regex As New Regex("^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$")
        Return regex.IsMatch(s)
    End Function

End Module

In this function I've extended the string type.  Using this approach I can now call IsValidEmailAddress on the string variable itself.  I think this example is a perfect demonstration of the ease in which extension methods can be created and used.  A word of caution is in order, though, as it is quite easy to cause some namespace and method name collisions or make your code a little more difficult to debug.  As an example, some of the examples I used when creating the C# post on this topic don't seem to work very well using VB, so use with care. 

If you want more information please read the C# post or visit the MSDN article regarding Extension Methods in Visual Basic.