[ASP.NET MVC] Release ビルドでコントローラークラスが消える…?

実はさっきまで sorceryforce.net のルートページを開こうとしてもエラーになっていました。原因ははっきりとはしていないのですが、HomeController クラスで何らかの処理をさせようとすると NullRefenenceException で落ちるというエラーが発生していました。単純に Index メソッド内で「int a = 0;」とさせるだけでも Null 参照で落ちます。おそらく HomeController のインスタンス自体が null になっているような感じでした。(C++言語なんかだと自分自身のインスタンスを delete するなんて裏ワザもあったりするんですけどね。インスタンス要素にアクセスしなければ処理は継続できるという)

私が想定する原因としては Release ビルドを行う際にコードの最適化が実行されるのですが、HomeController クラスに処理を入れた場合でも、HomeController クラスは実際にはどこからも参照されていないクラスなので最適化した際にごっそり削られたのではないかと思っています。ためしに「コードの最適化」のチェックを外して Web サイトにアップロードすると問題なく動作します。なので今は適当なクラスで HomeController クラスのインスタンスを生成するコードを入れておいてビルドするようにしています。こうするとコードの最適化が実行されても HomeController クラスは正常に動作します。でも他のコントローラークラスは正常に動作するんですよね…。

]]>

[ASP.NET MVC] Redirect メソッドと RedirectPermanent メソッドの違い

Redirect メソッドと RedirectPermanent メソッドはどちらも同じ別ページに遷移するためのメソッドですが、クライアントに返すステータスが異なります。Redirect メソッドが「302 (Moved Temporarily)」を返し、RedirectPermanent メソッドが「301 (Moved Permanently)」を返します。

これはサイトを閲覧しているユーザーのためというよりは検索エンジンのクローラーに対してのメッセージとして使われます。302 は一時的に生成したページに遷移するという意味を持ち、クローラーはそのリダイレクト先の情報を収集しようとはしません。301 は古いページから新しいページに移動させるためのリダイレクトとして解釈され、クローラーは新しいリダイレクト先の情報を収集します。(収集しない、すると明言して書いていますが、実際の挙動はクローラーに依存します)

ですので、ユーザー登録のための画面や一時的なダウンロードページなど、クローラーに収集されたくないページへリダイレクトする場合は「Redirect メソッド」、遷移先のページをクロールされてもいい場合は「RedirectPermanent メソッド」のように使い分けをします。

]]>

ドメイン間ポリシーファイルの配置場所

Silverlight や Flash などのアプリケーションが提供されたドメインと異なる URL の Web サービスを使用するには「ドメイン間ポリシーファイル」が「Web サービス側」に配置されている必要があります。(Silverlightドメイン間ポリシー(clientaccesspolicy.xml)や Flashドメイン間ポリシー(crossdomain.xml))

イントラネットワーク内のサイトで提供している Web サービスでも同様でドメイン間ポリシーファイルを配置する必要がありますが、配置する場所は必ずホスト名直下の URL で取得できる位置に配置する必要があります。(例:http://<サーバー名>/clientaccesspolicy.xml など)

IIS などで同じポートで複数のアプリケーションを配置するために Default Web Site の下にアプリケーションを作成する場合があると思いますが、その場合も個々のアプリケーションごとにドメイン間ポリシーファイルを配置するのではなく、Default Web Site が使用している物理フォルダ (デフォルト「C:inetpubwwwroot」)に配置する必要があります。

]]>

[T-SQL] データベースのテーブル、ストアド、関数の一覧を取得する SQL

-- テーブル一覧取得 select name from sysobjects where xtype = 'U' order by name -- スカラー値関数一覧取得 select name from sysobjects where xtype = 'FN' order by name -- ストアド一覧取得 select name from sysobjects where xtype = 'P' order by name ]]>

ASP.NET MVC で AsyncOperationManager.CreateOperation メソッドを呼び出すと ActionResult が効かなくなる

理由はわかりませんがクライアントから何らかのリクエストを受け、アクション処理実行中に AsyncOperationManager.CreateOperation メソッドを呼び出すと ViewResult や FileContentResult を返してもクライアントでは何も反応しなくなります。エラーや例外が発生するわけではないのでなかなか原因の発生元がわかりづらいので注意です。

]]>

[SSRS] Tablix の列ヘッダを改ページしても表示させたままにする方法

設定がわかりにくかったのでメモ。

下のような列ヘッダー1行と詳細データ1行の Tablix を配置しているものとします。

列ヘッダーA 列ヘッダーB 列ヘッダーC 列ヘッダーD
詳細データA 詳細データB 詳細データC 詳細データD

 

レポートを表示した際に詳細データに表示される行数が多くなると自動的に改ページされるようになりますが、改ページを行った場合、2ページ目以降も列ヘッダーを表示してほしい場合が多いと思いますが、残念ながらデフォルトでは最初のページにしか表示されません。(改ページさせない設定は Tablix のプロパティにあります)

2ページ目以降も列ヘッダーを表示するために画面の項目を調べていくと一般的に Tablix のプロパティに「すべてのページにヘッダー行を表示する」というチェックボックスを見つけられると思いますので、そのチェックで解決すると思われがちなのですが、このチェックをつけても期待した動作にはなってくれません。(このプロパティがどんな動作をするかはわかりません)

改ページでも列ヘッダーを表示させるには以下の手順を踏む必要があります。

  1. Tablix をクリックして選択
  2. デザイナの下にあるグループペイン(行グループ、列グループのエリア)の「右上」にある「▼」をクリック。(行グループ、列グループの下ではなく右側にあります)
  3. 「詳細設定モード」を選択
  4. 行グループの下に「(静的)」の項目が追加されるのでそれを選択。(列グループにも同様に表示されますが、列ヘッダーを表示させたい場合は行グループの方を選択します。選択するとデザイナ上の Tablix で左上のセルが選択されると思います)
  5. プロパティペインを開き(ない場合は表示メニューから「プロパティ ウインドウ」)、「KeepWithGroup」のプロパティを「After」に、「RepeatOnNewPage」のプロパティを「True」に設定します。
  6. プレビューで動作確認
]]>

SSRS でグラフのサイズを動的に変更する

SSRS やレポートビルダーでグラスのサイズを指定する場合 Size プロパティの Width や Height を変更することになると思います。デザイナ上でドラッグして変更した場合もこの値が変更されます。

しかし、Size プロパティには「式」を設定することができないため、このプロパティではパラメータやフィールドを使って動的にグラフのサイズを変更させることができません。

Size を動的に変更するには「DynamicWidth」と「DynamicHeight」プロパティを使用します。こちらはデータの型に「ReportExpression<ReportSize>」が適用されているので式を埋め込むことができます。

]]>

Silverlight でファイル選択ダイアログ、または保存ダイアログを表示する前にブレークポイントを挿入してデバッガーを起動するとエラーになる

意外とはまるのでメモ。

Visual Studio を使っているとブレークポイントを使ってプログラムの流れをチェックすることはよくあると思いますが、Silverlight で同様にブレークポイントでデバッガーを立ち上げた状態でファイル選択ダイアログなどのコモンダイアログを表示させようとすると SecurityException がスローされます。

同じことを書くのも面倒なので詳しいことは下記のリンク先を参照してください。

ファイル選択、ファイル保存、印刷ダイアログはそれぞれクライアント PC に直接影響するので Silverlight アプリケーション以外でのプロセスでローカルリソースにアクセスするのはだめということみたいです。リソースに影響しないメッセージボックスは例外はスローされません。

]]>

ビルド構成ごとの We.config の作成方法

Visual Studio 2010 からの ASP.NET には Web.config をビルド構成ごとに分けて作成することができます。デフォルトでは「Web.Debug.config」と「We.Release.config」の2つのファイルが作成されており、「.」の中央にある名称がビルド構成の名称と一致するようになっています。

新しいビルド構成を作成すると、対応する Web.config がなくなってしまい、ベースのWeb.config のみが適用されますが、新しいビルド構成に対応した Web.config がほしい場合は Web.config ファイルを右クリックし、「構成変換の追加」を選択することによって新しいファイルを作成することができます。

]]>