ASP.NET 2015の不具合と確定していないのですが、ASP.NET 2015で空のｔｒが勝手に消される不具合に遭遇しました。
なので一応、システム開発備忘録しておきます。

具体的な不可解な現象を引き起こしたコードは以下の通りです。

<table>
  <thead>
    <tr><tr>
  <thead>
<table>

　　↓　※確実にセーブしてもどのタイミングかわかりませんが、以下のようになります。

<table>
  <thead>
  <thead>
<table>

空のtrが不要なタグと判断されたのかな？
実際、今までこのようなケースが無かったので、ASP.NET 2015の不具合かどうかもわかりません。
が、数回同じ現象が起きたので、条件によって引き起こされているのかな？

今回は下のような、動的にth要素をコピーするプログラムを書いていたので、

$(this).clone(true).appendTo($("#tableH > thead > tr");

空のtr(td要素を持たない)をhtmlに書き込んでいました。
静的なhtmlでは空のtr(td要素を持たない)は意味ないですからね。。。

で不具合の対策は、いろいろ考えるのは面倒なので、次のように変更しました。

$("#tableH > thead").append("<tr></tr>");
$(this).clone(true).appendTo($("#tableH > thead > tr");

今回は、空のtr(td要素を持たない)が消えてなくなる(削除される？）とは思って居なかったので、不具合を探すのに少し戸惑いました。
こんなケースも有るんだなぁ・・・程度の備忘録です。

以上、ASP.NET 2015で空のｔｒが勝手に消される不具合報告でした。

今日はajax postで長文を送った場合にエラーになってしまった場合の対策備忘録です。
サーバはWindows IISです。

今までは普通に送れていたのに、長文にした時にエラーになってしまう場合は、IISにはじかれていると考えられます。
ちなみにデフォルトは何バイトか調べて居ません。

で、まずはエラーの内容確認

$.ajax({
   		type: "Post",
   		url: "************",
		contentype: "application/json"
		dataType:"json",
   		success: function(msg){
			document.open();
			document.write(msg);
			document.close();
   		},
   		error: function(XMLHttpRequest, textStatus, errorThrown){
			msg="--- Error Status ---"
			msg=msg+"<BR>"+"status:"+XMLHttpRequest.status;
			msg=msg+"<BR>"+"statusText:"+XMLHttpRequest.statusText;
			msg=msg+"<BR>"+"textStatus:"+textStatus;
			msg=msg+"<BR>"+"errorThrown:"+errorThrown;
			for(var i in errorThrown)
			{
				msg=msg+"<BR>"+"error "+i+":"+ errorThrown[i];
			}
			document.open();
			document.write(msg);
			document.close();
   		}
	});

エラーコードは次のような感じです。
　404.13　：　コンテンツの長さが長すぎます
　404.14　：　URL が長すぎます
　404.15　：　クエリ文字列が長すぎます

各々は以下のパラメータで対応できます。
　maxAllowedContentLength
　maxUrl
　maxQueryString

具体的には、web.congigの中に下のような感じで記述します。

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <requestLimits
           maxAllowedContentLength="30000000"       
	   maxUrl="300"       
	   maxQueryString="10000"/>   
	</requestFiltering>
  </security>
 </system.webServer>
</configuration>

で、今回の備忘録はajax postで長文を送った場合にエラーとなった場合への対応備忘録ですので、コンテンツが長い場合、URLが長い場合は調べて居ませんが、
クエリー文字列が長い場合、上の対応をしたとしても、実はまだエラーになります。

※クエリー文字列が長すぎる旨のエラーになってしまいます。

で、どうすれば良いかと言うともう一つ「maxQueryStringLength」パラメータを設定してあげます。
やはり、web.configの中で設定するのですが、

<configuration>
  <system.web>
    <httpRuntime maxQueryStringLength="10000" />
  </system.web>
</configuration>

私の環境では、

<configuration>
  <system.web>
    <httpRuntime targetFreamework="4.5" maxQueryStringLength="10000" />
  </system.web>
</configuration>

となりました。

これで長い文字列を含むajax Postでも正常にIISで受け付けてもらえました。

以上、ajax postで長文を送った場合にエラーとなった場合への対応備忘録でした。

前回の続きです。
GridViewを利用したExcelファイル出力の際に、『GridViewのコントロールGridView1は、runat=server を含む form タグの内側に置かなければ成りません』のエラーになってしまう対応の続きです。

前回は、

Public Overrides Sub VerifyRenderingInServerForm(ByVal control As Control)
    ' このOverridesは以下のエラーを回避するために必要です。
    ' 「GridViewのコントロールGridView1は、runat=server を含む
    '  form タグの内側に置かなければ成りません」    
  End Sub

を入れることで、VerifyRenderingInServerFormをOverridesして、サーバー フォーム要素の表示方法が異なっているページは、異なった条件の下でこのメソッドをオーバーライドして例外をスローしました。
第一関門突破です。

しかし、『RegisterForEventValidation は Render(); の実行中にのみ呼び出されることができます』
が発生するようになりました。
どうやらGridViewの列にButtonFieldやCommandFieldを使用している場合に、PostBackを検証対象処理として登録を行う際にRegisterForEventValidation を呼び出すようで、この中で Render 中かどうかがチェックされてしまうようです。

で、さらにググると、このチェックを行うかどうかは EnableEventValidation プロパティで制御できるようです。

    Public Overrides Property EnableEventValidation() As Boolean
        Get
            ' 「RegisterForEventValidation は Render(); の実行中にのみ呼び出されることができます。」
            ' を出ないようにする
            Return False
        End Get
        Set(ByVal value As Boolean)
        End Set
    End Property

これでエラーが発生せずExcelファイルの出力が可能になりました。
めでたしめでたし＾＾

ただ、単純にFalseにすると、今回の私のように入力コントロール等があるGridviewの場合、セキュリティ上まずいと思われるので、Excelファイルを作るときのみFalseになるように制御しないといけないと思います。

今回は気になったので調査しました。
以上ASP.NETのシステム開発備忘録でした。

今回はたまに使うGridViewを利用したExcelファイル出力の備忘録です。
Webフォームに更新可能でソートも可能なGridViewを作成しました。
帳票を作るときは、画面で仕様が固まった後、PDFもしくはEXCELをGridView経由で出力できるようにしています。

データ更新できるGridviewにすると、EXCEL出力する際にinputコントロールやSelectコントロールまで付いてしまうのでいつもは画面用のGridViewを流用することはしないのですが、何気なく流用してみたところエラーが出てしまいました。

『GridViewのコントロールGridView1は、runat=server を含む form タグの内側に置かなければ成りません』
です。
グッグってみたところ、

このコードを付け加えてみてください。
Public Overrides Sub VerifyRenderingInServerForm(ByVal control As Control)
End Sub

と言う記述を発見しました。

もう少し調べると
VerifyRenderingInServerFormの解説に、

＜form runat=server＞タグの内側に配置する必要があるコントロールが、表示される前にこのメソッドを呼び出すことができます。その
ため、そのようなコントロールがタグの外側に配置された場合、エラー メッセージが表示されます。登録したスクリプト ブロックをポストバックするコントロール、または登録したスクリプト ブロックに依存するコントロールは、Control.Render メソッドのオーバーライド部で、このメソッドを呼び出す必要があります。サーバー フォーム要素の表示方法が異なっているページは、異なった条件の下でこのメソッドをオーバーライドして例外をスローできます。

上のこのコードを付け加えてみてくださいとは、「異なった条件の下でこのメソッドをオーバーライドして例外をスローできます」のアドバイスに従ったものだとわかりました。

他のページには、更に

Public Overrides Sub VerifyRenderingInServerForm(ByVal control As Control)
    ' このOverridesは以下のエラーを回避するために必要です。
    ' 「GridViewのコントロールGridView1は、runat=server を含む
    '  form タグの内側に置かなければ成りません」    
  End Sub

のように親切に書かれているものもありました。

早速、試してみたところ、該当の『GridViewのコントロールGridView1は、runat=server を含む form タグの内側に置かなければ成りません』は出なくなりましたが、新たなエラーが。。。

『RegisterForEventValidation は Render(); の実行中にのみ呼び出されることができます』
が発生するようになりました。

これの対策はまた後日。。。

今回は以前に試したGridViewのヘッダー行を1行追加するプログラムの備忘録です。
ヘッダー行を複数行にするとPostBackを行った時に、データバウンドでおかしなことになるのですが、それが避けられるケースで有れば有効かと思います。
私はこの方法を使ったことは無いのですが、将来使うかもしれないし、試していないのですがPDFファイルとGridViewから作成するのに使えるのかな？と思っています。

下の例では、行にデータを張り付けたタイミングで追加しています。
この他にもレンダリングの前でも全てのデータ張付け後でも可能と思います。

Private Sub GridView1_RowDataBound(sender As Object, e As GridViewRowEventArgs) Handles GridView1.RowDataBound

If e.Row.RowType = DataControlRowType.Header Then
  Dim row As GridViewRow = New GridViewRow(-1, -1, DataControlRowType.Header, DataControlRowState.Normal)
  For i As Integer = 0 To 11
    Dim cell1 As TableCell = New TableCell()
    cell1.Text = i.tostring + "月"
    row.Cells.Add(cell1)
  Next
  row.RowType = DataControlRowType.Header
  Me.GridView1.Controls(0).Controls.AddAt(1, row)
endif

プログラムは簡単で、GridViewのRowを定義して、その中にCellを追加し、GridViewにRowを追加するだけです。

尚、追加した行をDataControlRowType.Headerとしているのですが、PostBackして再度データを張り付ける時に、追加したヘッダー行にデータを張り付けようとする動きになりました。
どうしてそのような挙動になるか理由は不明です。
ですから、PostBackするような場合は注意が必要です。

以上、VB.NETでGridViewにヘッダー行を追加するシステム開発備忘録でした。

ps.
PostBack時の不具合の原因ですが、他の調査をしていてわかったかもしれませんので、リンクを貼っておきます。
ASP.NET VB GridViewのヘッダーに行を追加する（修正版）