.NET 3.5 で ListView コントロールと共に導入された DataPager コントロールには、QueryStringField プロパティ周りにバグがあります。

QueryStringField プロパティというのは、クエリ文字列を利用してページの移動先を指定し、ページの移動に HTTP GET コマンド（デフォルトでは POST）を使用できるようにするためのものです。

例えば、QueryStringField="pageNumber" と設定した場合、ページャーをクリックして指定した移動先のページ番号が 5 であったとすると、URL にクエリ文字列 ?pageNumber=5 を追加して HTTP GET コマンドでそのページを要求するようになります。

MSDN ライブラリ「DataPager.QueryStringField プロパティ」によると "検索エンジンですべてのデータ ページにインデックスが付けられるようにするには、このプロパティを設定すると便利です。" とのことです。

ところが、このページを要求する際に、クエリ文字列のキーに null が含まれる場合（例えば、?pageNumber=5& とすると、& の後に null のキーがあると判断されるようです）、NullReferenceException がスローされるという問題があります。

ページ内でページャーをクリックしているだけなら、自動的に ?pageNumber=x （x は要求するページ番号）というクエリ文字列が URL に追加されて要求がかかるので間違いなく動作しますが、別のページでクエリ文字列を組み立ててそのページを要求する場合、間違って ?pageNumber=x& などとすると例外がスローされます

この問題は、2008 年 7 月に Connect に報告されています。

この報告によると、受信したクエリ文字列のキーに null が含まれていると、ライブラリ内のメソッドの以下の部分で key（String オブジェクト）が null になって NullReferenceException がスローされるということだそうです。これはバグとして次期バージョンで修正されるという話になっていました。

foreach (string key in request.QueryString.AllKeys)
{
  if (... && !key.Equals(queryStringField, 
                StringComparison.OrdinalIgnoreCase))

今日、このページをのぞいてみたら、すでに修正済みというようなことが書いてあります。ということは、少なくとも .NET 4 では修正されているはずです。

ということで、早速試してみました。結果は：

• .NET 3.5 SP1: ダメでした。NullReferenceException がスローされます。
• .NET 4: 例外はスローされなかったので、バグは修正されているようです。

というわけで、ASP.NET 3.5 では回避策がまだ必要なようです。上に紹介した Connect のページに回避策も提案されていますので、そちらを参照してください。