WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

Mvc.dll のバージョン相違

by WebSurfer 2015年1月12日 16:06

Windows Update によって、知らないうちに System.Web.Mvc.dll のバージョンが変わり、突然 Visual Studio で MVC アプリケーションのビルドが通らなくなったという話を書きます。ちょっと古い話ですが、またあるかもしれませんので、備忘録として。

System.Web.Mvc.dll

2014 年の 5 月中旬の Windows Update に含まれる Microsoft ASP.NET MVC セキュリティ更新プログラム MS14-059 (KB2990942) によって、参照先(C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies\System.Web.Mvc.dll)の System.Web.Mvc.dll のバージョンが 3.0.0.0 から 3.0.0.1 に変わってしまいました。上の画像を参照ください。

Visual Studio 2010 の MVC3 インターネットアプリケーションのテンプレートを使って Web アプリを作ると、「ローカルコピー」が False になっているので(上の画像を参照・・・True にすると bin フォルダにコピーされる)、アプリは上に書いた参照先の .dll を参照しますが、プロジェクトファイル (.csproj) では 3.0.0.0 の指定のままなので、バージョン不一致でビルドが通らないと言うことのようです。

解決策は stckoverflow の記事 ASP.NET MVC security patch to version 3.0.0.1 breaks build [duplicate] にありますように、以下の手段を取るのがよさそうです。

  1. Visual Studio の「ソリューションエクスプラーラー」で、System.Web.Mvc の参照設定を一旦削除してからやり直す。

    蛇足ですが、手動でプロジェクトファイルを編集する方法もあるそうです。興味がありましたら、msdn ブログの記事 Visual Studio で現在開いてるプロジェクトファイル (.csproj, .vbproj) を編集する方法 を見てください。
  2. 「ローカルコピー」プロパティを False から True に変更する。(上の画像を参照。今後の Windows Update による影響を受けないようにするため)
  3. web.congfig の bindingRedirect 要素を以下のように修正する。
<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity 
          name="System.Web.Mvc" 
          publicKeyToken="31bf3856ad364e35" />
      <bindingRedirect 
          oldVersion="1.0.0.0-3.0.0.0" 
          newVersion="3.0.0.1" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

なお、MVC4 でも System.Web.Mvc.dll のバージョンは 4.0.0.0 から 4.0.0.1 に変わっています(未確認ですが、MVC2, MVC5 も同様だと思います)。ただし、MVC4 の場合、参照設定と参照先の .dll のバージョン不一致の問題は出なかったので気がつきませんでした。

参考までに、なぜ MVC4 では問題が出なかったかを以下に書いておきます。

Visual Studio 2010 のインターネットアプリケーションテンプレートで MVC4 アプリを作ると、アプリケーションルート直下の packages フォルダに System.Web.Mvc.dll ほか必要な .dll がコピーされます。(NuGet によるパッケージ管理のため?)

コピーされる .dll のバージョンは 4.0.0.0 で、当然ですが参照設定もそのバージョンになります。

Visual Studio で System.Web.Mvc のプロパティを見るとわかりますが、「ローカルコピー」が True に設定されているので、ビルドする時に bin フォルダに .dll がコピーされます。

Windows Update によって packages フォルダの .dll は書き換えられることはないので、参照設定と参照先(bin フォルダの .dll)のバージョンの不一致は起こらないという仕組みです。

なお、Windows Update 後に新たに MVC4 プロジェクトを作っても、使われる System.Web.Mvc.dll は 4.0.0.0 のままとなります(自動的に最新バージョンが参照されることはない)ので注意してください。

具体的に言うと、C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies の方の System.Web.Mvc.dll は 4.0.0.1 に更新されますが、C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Packages の方は 4.0.0.0 のままになり、プロジェクトの packages フォルダにコピーされるのは後者のフォルダにある 4.0.0.0 となるようです。

4.0.0.0 から 4.0.0.1 への更新が必要であれば、Visual Studio のテンプレートで Web アプリを作成後、NuGet のパッケージマネージャーを使って手動で行う(「NuGet パッケージの管理」を起動して、その中から「Microsoft ASP.NET MVC 4」を選択して更新をかける)必要があります。

Tags:

MVC

FileUpload と form 要素 の enctype

by WebSurfer 2015年1月3日 13:54

ファイルアップロードに用いる ASP.NET サーバーコントロールの FileUpload をページに配置すると、ASP.NET がブラウザに送信する html コードをレンダリングする際、form 要素に enctype="multipart/form-data" を追加します。

下の画像で、赤線で囲った部分がそれです。ちなみに、ソースコードでは form 要素は <form id="form1" runat="server"> となっています。

enctype の追加

FileUpload コントロールに限らず、HtmlInputFile や Ajax Control Toolkit の AjaxFileUpload, AsyncFileUpload を使ったり、<input type="file" ... /> 要素に runat="server" 属性を追加(結果、HtmlInputFile と同じになる)しても同様です。

普通の html 要素の <input type="file" ... /> を使った場合はそういうことはなく、自力で enctype="multipart/form-data" を form 要素に追加してやらなければなりません。

form 要素に enctype="multipart/form-data" 属性の設定がないと、ファイルはアップロードされません。当然、サーバー側でファイルを取得できません。

知ってました? 実は、サーバーコントロールしか使ったことがない自分は、知らなかったです。なので、そこに気がつかず、ちょっとハマってしまいました。(汗)

Tags: ,

Upload Download

ブラウザーモードとドキュメントモード

by WebSurfer 2014年12月29日 14:56

Internet Explorer (IE) で F12 キーを押して開発者ツールを起動すると、下の画像のようにブラウザーモードとドキュメントモードというメニューが表示されます。これについていろいろ調べましたので、後日役に立ちそうなことを忘れないように書いておきます。

ブラウザーモードの設定

ブラウザーモード

F12 開発者ツールのみで設定が可能なオプションで、IE 自体の動きが選択されたバージョンになります。

例えば、実際に使っているブラウザが IE9 でも、ブラウザーモードで他のバージョンを選択するとそのバージョンの動きになります。

試しに IE9 で[Internet Explorer 8(8)]を選択してみると、サーバーに送信される User Agent は Mozilla/4.0 (compatible; MSIE 8.0; ... というように IE8 のものになりました。(サーバーに送られる User Agent は、IE の互換表示の設定によっても変わってきます。詳しくは下の「2016/3/1 追記」を見てください)

また、<!--[if IE 8]> のような条件付コメントも、ブラウザーモードの選択によって影響を受けるとのことです(未検証です)。

ドキュメントモード

これはレンダリングエンジンのみを変更します。ブラウザーモードの切り替えのように IE 自体の動きは変更しません。

F12 開発者ツールを使う以外にも、(1) meta タグ (X-UA-Compatible) で指定、(2) IE の[ツール(T)]⇒[互換表示設定(B)]、(3) IE のアドレスバー右横の互換表示ボタン (IE11 では無くなった) で設定可能です。

ただし、IE9 で試した限りですが、上記の (2) と (3) では[Internet Explorer 7 標準(7)]相当になり、IE8 や Quirks モードを選ぶというようなことはできませんでした。

Quirks モードというのは IE6 で導入された旧バージョン(ということは IE5 以前のはず)のブラウザーと同じようにページが表示されるモードです。CSS の IE 独自実装である expression 関数が使えるのが Quirks モードです。

その他

IE10 以降では条件付コメントはサポートされなくなったそうです。

Conditional comments are no longer supported (条件付きコメントがサポートされなくなった)

IE10 以降では Quirks モードの既定の動作が修正されているそうです。

Interoperable (HTML5) quirks mode (相互運用可能な (HTML5) Quirks モード)

IE11 以降ではエッジモードが使われており、ドキュメントモードは廃止される可能性があるとのことで、将来的には切り替えることができなくなる可能性があるようです。ただし、現時点では F12 開発者ツールや meta タグ (X-UA-Compatible) での設定は可能な様子です。

Compatibility changes in IE11 (IE11 の互換性の変更点)

Web制作者は注意! Internet Explorer 11で変更された「互換性」

meta タグ (X-UA-Compatible) で指定する content="IE=7" とか content="IE=EmulateIE7" の違いは、以下のページが参考になると思います。

Defining document compatibility (ドキュメント互換性の定義)

Specifying legacy document modes

上の後者の記事によると、以下のように edge を指定した場合、IE6 ~ IE11 では "the highest standards mode supported by Internet Explorer" になるとのことです。

<meta http-equiv="x-ua-compatible" content="IE=edge" />

ただし、この先 meta タグで X-UA-Compatible は無視されるという話もあります。

"living" Edge ドキュメント モード

一体何を信じたら良いのかって感じですが、とにかく X-UA-Compatible でドキュメントモードを古いものに指定するようなことをしなければ今後も問題が起こることはなさそうです。

------- 2016/3/1 追記 -------

サーバーに送られる User Agent は、ブラウザモードの設定だけでなく、IE が互換表示するサイトと認識すると旧バージョンのものになるようです。

IE9 で試してみましたが、[ツール(T)]⇒[互換表示設定(B)]で表示されるダイアログで、要求するページのサイトが[互換表示に追加した Web サイト(W):]に含まれている場合とか、[すべての Web サイトを互換表示で表示する(E)]にチェックを入れた場合は IE7 の UA が Web サーバーに送られます。

[イントラネット サイトを互換表示で表示する(I)]にはデフォルトでチェックマークが入っているので要注意ですね。

Tags:

その他

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar