Code Snippets

What would NHibernate ICriteria look like in .net 3.5?

Brendan Kowitz — Sun, 17 Aug 2008 05:12:29 GMT

If NHibernate decided to ditch compatibility with plain old .net 2.0 and focus on 3.5 how would the ICriteria interface change? Previously I was throwing around an idea of using a simple lambda expression to resolve the property name. Well, I couldn't help but build on this a little more. The following idea is not supposed to be LINQ, that would be far more complicated and LINQ is essentially its own interface, which is not the point. The point is, if ICriteria was written today in .net 3.5, what could it look like? How could it change?

So just to recap, the original code sample looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

Paul later come back and suggested I try using a slightly different signature so that the "Person" object doesn't need to be instantiated for no reason, this means the we can do this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.For<Person>(p => p.FirstName), "John"));

I like this a lot more. So this is the point where I started playing around and wanted to try and implement a neater way of integrating this to add Criterion. First off I tried implementing ICriteria.Add(Restrictions.Eq()) as an expression which looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq<Person>(p => p.FirstName == "John" ));

That is where I got up to in the previous post. So after this I started implementing some of the other functions found on the 'Restrictions' class such as:

.NotNull()
.IsNotNull()
.Not()
.Between()
.Gt() (Greater than)

Then I realized all of the above functions are able to be figured out using the syntax I already had: 'p.FirstName == "John"', so how about p.FirstName != "John", or p.ID > 0 or p.FirstName != null, you get the idea. This being the case, now there is no need for the Restrictions class at all, nearly everything can be figured out by using Add(). The other problem I wanted to solve was not having to keep passing the generic <Person> class in all the time. So I created a class which wraps ICriteria and keeps track of these few things, so now it looks like:

ICriteria c = session.CreateExpression<Person>()
     .Add(p => p.FirstName == "John")
     .Criteria;

Most of the other functions on the Restrictions class can be added the same way:

ICriteria c = session.CreateExpression<person>()
      .Add(p => p.FirstName == "John") //Restriction.Eq()
      .Add(p => p.LastName != null)    //Restriction.IsNotNull() 
      .Add(p => p.ID > 0 && p.ID < 1000) //Restriction.Between()
      .Criteria;

There are also other more complex things that the ICriteria interface does such as adding Projections and Joins. So how would the old AddAlias() function work? Like this perhaps:

ICriteria c = session.CreateExpression<Person>()
      .Alias<Address>(p => p.Addresses, "addr")
            .Add(a => a.Postcode != null)
            .AddAndReturn(a => a.Address2 == null)
      .Criteria;

Bringing it all together, here's a comparison between the old interface and the expressions version.

Current ICriteria:

ICriteria o = session.CreateCriteria(typeof(Person))
    .Add(Restrictions.Eq("FirstName", "John"))
    .CreateAlias("Addresses", "addr")
        .Add(Restrictions.IsNotNull("addr.Postcode"))
        .Add(Restrictions.IsNull("addr.Address2"))
    .AddOrder(Order.Asc("ID"));

Same query using Expressions:

ICriteria c = session.CreateExpression<Person>()
    .Add(p => p.FirstName == "John")
    .Alias<Address>(p => p.Addresses, "addr")
        .Add(a => a.Postcode != null)
        .AddAndReturn(a => a.Address2 == null)
    .OrderAsc(p => p.ID)
    .Criteria;

In conclusion, this is probably not going to revolutionize the global economy, but on some levels I think it feels a little more intuitive and a little more modern. In other respects, it's probably not much less typing then the original. Also with the up and coming linq provider, is this a waste of time? or does it complement it?

Feel free to have a poke around the source, and corresponding tests

NHibernate Type Safety using Lambda Expressions

Brendan Kowitz — Mon, 21 Jul 2008 21:38:48 GMT

I can't remember if this has been around before, I do vaguely remember seeing something like it.

However, I just wanted to apply a snippet of code I found on Paul's blog the other day to NHibernate. Of course we will definitely have type safety in queries when Linq-to-NHibernate is completed. But surely linq-to-nhibernate is not going to be the _only_ way of writing queries.

Using the original code snippet 'as is' would look something like this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

This is ok, but a little long winded, so I implemented another class called RestrictBy which can break down a simple lambda expression. So now I can use:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq(() => new Person().FirstName == "John"));
c.UniqueResult();

This also means you'll get compile time errors for incompatible types such as:

Using the lambda expression we get to evaluate the _actual_ property and that property's type. If you wanted to clean this up some more, its not hard to then go and add some extension methods to ICriteria to produce:

ICriteria c = session.CreateCriteria(typeof(Person));
c.AddEq(() => new Person().FirstName == "John");
c.UniqueResult();

So that's it, a simple example at the moment, but it might be an option to look into a little more because the ICriteria interface is still NHibernate's native querying interface and still provides a lot of power, flexibility and programmatic building of queries.

Sourcecode:

RestrictBy.cs also a couple of unit tests here
Paul's Property.GetFor()

EDIT: For further reading, see the follow up post.

IDataErrorInfo for ASP.NET

Brendan Kowitz — Thu, 08 Nov 2007 13:42:42 GMT

As far as I'm aware ASP.NET doesn't support IDataErrorInfo, I've asked about this in many places, including Tech.Ed '07 with no success. The closest things I've seen in terms of Business Object level validation is from Enterprise Library validation block (which is attribute based and can render out with custom EntLib web controls) and another example in the Futures Dynamic Data Controls using Linq (I have no idea how this magic validation magically appears).

It all just seems overly complicated, so, have a look at the IDataErrorInfo interface the methods are:

string this [ string columnName ] { get; }
string Error { get; }

Simple and generic. I've been playing around with an idea about how to get this into a generic web control, introducing:

WebValidationControlExtender

Here is an example of the control in design mode:

Here is an example of the control in action using an ObjectDataSource and a plain old DetailsView:

Here's what's going on under the hood.

All you need to do is tell WebValidationControlExtender what ObjectDataSource to hook in to.
When the page is executing and the user tries to insert a record, the DetailsView control builds up an object and sends it into the ObjectDataSource.
WebValidationControlExtender is already listening for Insert and Update events, all it does is check if the object being passed through implements IDataErrorInfo.
If it does, WebValidationControlExtender interrogates the object's columns/properties for errors.
If errors are found, it adds CustomValidators back to the page then goes searching for controls that are using that object datasource (in this case the DetailsView).
When it finds the details view it searches for BoundFields that are bound to the properties with the error, then inserts the red * like in the picture above.

The point is, you could go an implement whatever validation library suites your needs, as long as the object implements IDataErrorInfo the validation works. I just don't understand why ASP.NET doesn't already use something like this, there are so many complicated implementations for validation, I hope this brings some fresh light.

Stopping ASP.NET web.config inheritance

Brendan Kowitz — Wed, 16 May 2007 03:11:23 GMT

If you are only ever running one ASP.NET application on a website this is not an issue. However, if you are running a site which may have an application at the root and other separate applications running in sub or virtual directories, then Settings inheritance could be a problem.

You can read more about how config files get inherited on msdn but here's a tip for stopping settings in the root app from getting inherited. The <location> tag is the only tag I've come across which has the inheritInChildApplications attribute. So to target the main <system.web> just wrap it in the location tag as seen below.

<location path="." inheritInChildApplications="false">
<system.web>
 ...
</system.web>
</location>

Other Notes:
Although I think the inheritance is in general a good feature to have, especially for inheriting down things such as security settings. It can even support locking certain settings for child applications, but things can be problematic if the child application doesn't share the same libraries, modules, handlers, masterpages or themes.

Most collections in the web.config have the <remove> tag or <clear> tag to remove irrelevant modules or handlers in the child app. The problems I've found occur with settings relating to the <pages> tag, which most items in it don't support <remove>. This means if your child applications doesn't share or have the same registered controls, masterpages or themes then you are probably going to have issues or be forced to specify the settings on a per-page basis. This is where the inheritInChildApplications="false" really comes in handy.

ERROR: 42601: a column definition list is only allowed for functions returning record

Thu, 15 Mar 2007 11:30:35 GMT

Since the postgres forums appear to be a little quite, I'll post my error here as well.

This error is in regards to the postgres .net npgsql driver and seemed to only occur when using stored procs.

The Error
The behavior I experienced happens when using stored procedures started out with me getting the following error:
ERROR: 42601: a column definition list is only allowed for functions returning "record"

After checking and double checking the stored proc and the parameters I was sending in I turned Npgsql's debugging on. The error appears to be coming from a statement that looks like the following:
select * from sitemenus_ins(68::int4,34::int4) as (psitemenuid int4, prowstamp timestamp )
This line of sql fails.

However the following will work:
select * from sitemenus_ins(68::int4,34::int4)
The only difference being that the second one has the 'as(...' clause taken off.

Strange Observation:
The snippet in question is executed automatically by the provider after the NpgsqlCommand.cs class does some other queries to try and match the list of the parameters that are in the stored procedure it is about to execute. However, the 'select' it uses to determine if it should append the 'as(..' clause is queried from the pg_proc table but is matched on the parameter types that are passed in, and not on those of the actual proc.

For example, this means that if I passed in say a 'Text' type (25) as opposed to the defined datatype on a proc (eg. 'Varchar' 1043) The select will fail and the extra 'as (...' on the end of the statement in question will not be appended. So the function call will work

Resolution:
I have no idea what the ideal solution is, I don't have a firm understanding of the ins and outs of the provider, but after downloading the source and removing the check so the 'as (...' never gets appended, all CRUD operations in my unit tests pass.

Another suggestion by Al is that maybe it is a piece of code left in there that was needed from a previous version of postgres (since the code has been around for a few years now). Whatever the reason, it causes errors, I've checked the source for another postgres provider and it doesn't attempt to do the append. The only concern I have if this is an actual bug is that it looks as though the same code has been copied into the branch for the npgsql2 provider, so those wanting to use stored procs on postgres in the future may find the same error I have.

The C# @ String Literal

Brendan Kowitz — Mon, 05 Mar 2007 15:10:56 GMT

C# is a pretty sweet language, and there are many, many, many little things that just make the code that much nicer. Have you ever been in a situation where for some reason you NEEDED to have a string/code fragment/js fragment/sql statement inline in your code because you don't believe in resource files or stored procedures?

Aside from whatever great debate about "if you should or shouldn't". If you are going to, please, please, learn to take advantage of what C# has to offer, yes I'm talking about the '@' string literal.

Now I'm not going to target anyone in particular, but my feeling is that VB as a language seems to be more notorious for having hundreds of lines of String.Append()s. String.Append is the absolute worst, hardest and most illegible way of possibly including your fragment inline in code.

There are also the programmers that 'know of' the @ symbol and prefix all their strings with it because it looks cool or something. Doing this without reason may actually alter the behaviour you excepted because it causes escape sequences to NOT be processed.
Eg. "c:\\my\\file.txt" could be done as @"c:\my\file.txt"
This means your \n and \t or whatever it is will also not be processed.

I'd say the most precious and special super power of a string literal is its multi-line ability. So instead of writing code that may look something like:
var1 += @"some text" + Environment.NewLine;
var1 += @"some more text" + Environment.NewLine;
var1 += @"even more text" + Environment.NewLine;

You could just use the @-quoting and write:
var1 = @"some text
some more text
event more text";

And yes that will compile perfectly fine. Best of all, even without going into the debate of "having inline fragments" at least I can read it and change it.

Search Engine Optimization for .NET

Brendan Kowitz — Sat, 16 Dec 2006 15:42:36 GMT

Search Engine Bot Detection

So after I first noticed a large build up of strange session Urls in Google searches for my domain I've then done a little bit of research into the issue and discovered it was .NET not detecting that the search engine spider was Mozilla/5.0 compliant and inserting some rubbish session id into the url.

It's been nearly a week since my changes to correct this and there's already a small indication of the 'healing' process. The pages are not out of the index yet, (and yes I do know that I 'could' remove them manually) but there are a lot of urls, and I'm in no rush.

Note on Webparts

Another change I have made this week was completing stripping webparts out of my template. Now even though I think webparts are extremely cool...they render HTML Soup. So I'd probably recommend that if you have a site where you are trying to get it to rank via the content, don't use webparts. If its an admin section / personalisation portal / intranet site or any other scenario when content ranking is not important, then by all means, feel the ~~soup~~ power!

Apart from dropping 20k from my page here's another unexpected result:

Yey I pass validation on W3C!!

Evil ViewState

Well I think viewstate is fantastic, its a set-and-forget automagic keep-state for all things on your form. Only problem is it renders before the content. This is a bad thing because search phrases gain more significance the closer they are to the top of the document, so the idea is to keep the soup at the bottom. A bit of Googling shows there are various methods that have been implemented to move it to the bottom. The method I kind of agreed with (although I've lost the link d'oh) was where a basepage class simple overrides handling the viewstate and uses the LosFormatter to store it in the session. Now I only half agree with this, I like the idea of overriding the handling of the viewstate but not putting it in the session. I simply used this but added my own HiddenControl (i.e. __VIEWSTATE_SEO) to the bottom of the form on pre-render, easy.

New Blog Category

In respect of all these new things that appear to be common SEO problems I have created to new category for SEO.NET (Search Engine Optimisation for .NET) blog posts. And in addition to this I will be trying to starting a small toolkit of classes and resources that should be able to be applied to any ASP.NET 2.0 application to make it more SEO friendly.

Download

Move ViewState to the bottom of the form BasePage.cs or view Source online

ASP.NET 2.0 Mozilla Browser Detection Hole

Brendan Kowitz — Mon, 11 Dec 2006 02:58:54 GMT

It has recently come to my attention that there is something drastically wrong with the way search engines have been indexing my ASP.NET 2.0 blog.

As I've started to explain previously, this is because of the way the browser detection is set up. To give a brief rundown ASP.NET 2.0 has a default browser definition which seems to assume that the default browser is fairly capable and supports common things such as javascript and cookies. A browser definition can get inherited into other definitions which can then override specific properties to update it for that specific browser or browser version.

Apparently in around March 2006 Google started rolling out updates that changed the Googlebot's useragent string from:

"Googlebot/2.1 (+http://www.googlebot.com/bot.html)" to
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Now the reason for this is so the Googlebot could identify itself as being Mozilla/5.0 compliant which should allow it to be accepted by more webservers. However this breaks the detection pattern in ASP.NET. (And was always broken in Yahoo Slurp, I just don't know if anyone ever noticed).

When the useragent was just "Googlebot/2.1" it wasn't able to be matched and used the "default.browser" detection file which defaulted to a browser of reasonable capabilities. After the change it found itself in the "mozilla.browser" file because it was detected on the "Mozilla" word. So all the following sets of instructions in the "mozilla.browser" file try to establish exactly what platform and variant of Mozilla it is, for example, if its Firefox running on OSX, or if it's the older Mozilla Gecko rendering engine. But because there is no definition for a Generic Mozilla/5.0 compatible browser it gets the most relevant match, being the lowest Mozilla/1.0 compatible settings. Bad!

Because of this bad detection the default Mozilla/1.0 settings assume NO COOKIES and insert the session ID into the url then issues a response status 302 (content temporarily moved). What makes this situation even worse is that the default behavior of search engines is to follow these redirects and index the content on the other side. So basically everytime some random User-agent that claims to be Mozilla/5.0 compliant hits the site it gets Mozilla/1.0 capabilities. What is needed is something to bridge this gap.

Fortunately there is something that can be done that won't even require a recompile of your ASP.NET 2.0 application. Simply create a "genericmozilla5.browser" file in your "/App_Browsers" folder in the root of your application with the following in contents:

<browsers>
<browser id="GenericMozilla5" parentID="Mozilla">
<identification>
<userAgent match="Mozilla/5\.(?'minor'\d+).*[C|c]ompatible; ?(?'browser'.+); ?\+?(http://.+)\)" />
</identification>
<capabilities>
<capability name="majorversion" value="5" />
<capability name="minorversion" value="${minor}" />
<capability name="browser" value="${browser}" />
<capability name="Version" value="5.${minor}" />
<capability name="activexcontrols" value="true" />
<capability name="backgroundsounds" value="true" />
<capability name="cookies" value="true" />
<capability name="css1" value="true" />
<capability name="css2" value="true" />
<capability name="ecmascriptversion" value="1.2" />
<capability name="frames" value="true" />
<capability name="javaapplets" value="true" />
<capability name="javascript" value="true" />
<capability name="jscriptversion" value="5.0" />
<capability name="supportsCallback" value="true" />
<capability name="supportsFileUpload" value="true" />
<capability name="supportsMultilineTextBoxDisplay" value="true" />
<capability name="supportsMaintainScrollPositionOnPostback" value="true" />
<capability name="supportsVCard" value="true" />
<capability name="supportsXmlHttp" value="true" />
<capability name="tables" value="true" />
<capability name="vbscript" value="true" />
<capability name="w3cdomversion" value="1.0" />
<capability name="xml" value="true" />
<capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />
</capabilities>
</browser>
</browsers>

This will match generic Mozilla compatible browsers and spiders with user-agents strings such as:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Mozilla/5.0 (compatible; AbiLogicBot/1.0; +http://www.abilogic.com/bot.html)
Mozilla/5.0 (compatible; AnyApexBot/1.0; +http://www.anyapex.com/bot.html)
Mozilla/5.0 (compatible; BecomeBot/3.0; MSIE 6.0 compatible; +http://www.become.com/site_owners.html)
Mozilla/5.0 (compatible; MojeekBot/2.0; http://www.mojeek.com/bot.html)
Mozilla/5.0 (compatible; Scrubby/2.2; +http://www.scrubtheweb.com/)

Other Notes

The MSNBOT also never had this problem because it like the original Googlebot string was never detected and thus received the "default.browser" file settings which support the cookies.

My solution is not a complete fix, I think Microsoft could have done one thing better here. Because the browser string goes into the "mozilla.browser" file, they need another level where when it knows its Mozilla/5.0 compliant it gets the appropriate defaults before it starts to figure out exactly what browser it is. Even though with this approach the exact browsing useragent wouldn't be established, it would at least support future browsers claiming to be compliant at a higher level then just "Mozilla".

Downloads

genericmozilla5.browser

Cleaning Up ASP.NET Sessions in Google

Brendan Kowitz — Wed, 06 Dec 2006 13:49:27 GMT

ASP.NET and Dirty Urls

There are two things that have been bothering me about pages that are getting indexed in Google from an ASP.NET application. The first is somehow there are ASP.NET Session Urls ending up in the Google index. This is bad because searchers that actually do click these links are likely to get a 500 error (internal server error) because they will be trying to access a page of an expired session.

How is Google finding all these 'bad' urls?

Well apparently there is no browser definition in ASP.NET 2.0 for the Googlebot's useragent string, so when the spider hits your ASP.NET page it's browser capabilities are not defined.

Edit: The default browser capabilities are defined to use cookies, the issue occurs because the base Mozilla definition is defined to NOT use cookies. If the browser is not able to accept cookeis .NET gets around this by inserting the session information into the Url and issues a 302 (content temporarily moved) in the response header.

This default behaviour is a good and a bad thing. It's good in the fact that if I'm browsing an asp.net site on a pda that doesn't support cookies I still can. However just about every search engine spider ever created has it's own UserAgent string making it a tough task to issue the standard non-crufted url. One solution to fixing the session urls being indexed in Google is to tell your asp.net application that Googlebot supports cookies and the problem is solved.

To read more about the solution please see my next post.

Dynamic Captcha build-up

Another dynamic aspect that is used on this site are Captcha images, and yes Google's image spider finds those too. Upon trying a Google image search on my domain, it's littered with Captcha images! I've also added an exclude to the robots.txt file for this.

Solution for Captcha images build-up and stop-gap solution for Session Urls

Here is my "robots.txt" file so far for my SingleUserBlog install. *Note the last two lines, "Disallow: /(A(*" should exclude any ASP.NET session urls, (this is not recommended unless you have fixed the Mozilla detection hole). The last line should exclude any captcha images from being indexed.

User-agent: *
Disallow: /LoginPage.aspx
Disallow: /Administration/
Disallow: /(A(*
Disallow: /Captcha.ashx*$

Brendan's C# Modifier Keyword Guide

Sun, 05 Nov 2006 01:54:13 GMT

After a little bit of thought from my last post I decided to write a small sample class and use tooltips to document what some of the most common modifiers do. So run your mouse over the boxes below to see the documentation about the keyword.

Edit: In an effort to unbreak my RSS I've moved it to it's own page http://www.kowitz.net/CSharp_Modifier_Keyword_Guide.aspx