ASP.NET 4.5 MVC 4がWindows Server 2008で機能しないIIS 7
明らかに何かが足りないため、IIS 7のWindows Small Business Server 2008に簡単なASP.NET MVC 4、.NET 4.5アプリを展開できません。
.NET framework 4.5がインストールされています。
アプリケーションのアプリケーションプールの基本設定でそのバージョン（4.5）を表示するはずですか？現時点では、私は2.0と4.0しかありません。4.5は3.5に似ており、4.0フレームワークの上に追加するだけなので、これは正常なことです。
ホームページを閲覧すると、次のエラーが表示されました。
403-禁止：アクセスが拒否されました。指定した資格情報を使用して、このディレクトリまたはページを表示する権限がありません。
Page/page/indexという名前の唯一のコントローラーを要求すると、404 not foundページが表示されます。 ASP.NETプロセスがHTTPリクエストを取得することはありません。
簡単なHTMLページをリクエストできます。
アプリケーションプールは.NET 4.0に設定され、マネージパイプラインモードとして統合されています。
NETWORK SERVICEには、ディレクトリへの読み取り/書き込みアクセス権があります。
もちろん、アプリはVS2012から問題なく動作します。
ここにないものについて私は無知であり、検索エンジンのクエリはあまり役に立ちません。
誰にもヒントがありますか、それは非常に高く評価されます。ありがとう
編集
Dllは、System.Web.Mvc、System.Web.Razorなどのbinフォルダーに既にあります。
空のtest.aspxページを作成して、asp.netワーカープロセスがリクエストを取得していることを確認しました。はい、ページは問題ありませんでした。そのため、MVCルーティングは機能していないようですが、ASP.NET MVC 3 Webアプリはそのサーバーで正常に機能しています。
.NET 4.5のインストール後、aspnet_regiis -iruを実行しました。これにより、アプリにaspnet_clientフォルダーが追加されましたが、それでも問題は解決しません。
匿名認証は、IIS Authenticationセクションで有効であり、Authorization showはすべてのユーザーに対して許可されています。
ASP.NET MVC 4がインストールされているので、確認のために修復しました。
ASP.NET MVC 4がインストールされているにもかかわらず、/ page/indexアクションを要求することによる404エラーは、標準のaspnetエラーではなく、標準のIISによって返されます。したがって、MVCのように見えます。 4フレームワークが正しくインストールされていないため、再確認して修復するだけです。
@Mystere Man、匿名認証を変更して、アプリケーションプールIDを使用し、アプリケーションを停止、起動しても、同じエラーが発生するようにしました。 ASP.NET MVC 4がリクエストを受け取っていない場合は、本当に似ています。
Web.configの一部を次に示します。
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
<runtime>
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
</entityFramework>
編集2012/09/27
Microsoft Framework .NET 4.5を再ペアリングし、ASP.NET MVC 4を修復し、単純なASP.NET MVC 4アプリを再展開しましたが、それでも同じ動作をします。次に何をすべきかわからないので、誰かが問題を見つけるのを手伝ってくれることを期待して、私は賞金を始めました。
2014/01/31の編集
その質問をしたとき、問題を解決したのでrunAllManagedModulesForAllRequestsを受け入れられた答えとしてフラグを立てました。しかし、私はこれを実稼働環境で使用するつもりはありませんでした。なぜそうしなければならなかったのか、何の答えも得られなかったのです。
Martin Hollingsworth 答えは本当に私が探していたもので、runAllManagedModulesForAllRequestsに関連するすべてのパフォーマンスの問題なしでこの問題を修正する良い方法です。
ほぼあきらめて、新しいWindows 2012サーバーを購入しました（そこからASP.NET MVCアプリがそのまま動作します）。 Martinのソリューションを試した後、Windows 2008サーバーは機能しました。
notがkb 980368から QFEを適用できる場合 受け入れられた 回答で提案されているrunAllManagedModulesForAllRequestsソリューションを使用する代わりに 、次のpreCondition = ""でモジュール構成を使用して、ブログ投稿で説明されている静的コンテンツへの悪影響を回避する必要があります asp.NET MVCルーティングの仕組みとその影響静的リクエストのパフォーマンスについて および MVCルーティングを機能させるためにrunAllManagedModulesForAllRequests = "true"を使用しないでください および回答に対するコメントの一部。
runAllManagedModulesForAllRequestsに関するScott Hanselmanのブログ投稿 この引数に重みを追加する必要があります。 Rick Strahlの 投稿 IIS 7/8のrunAllManagedModulesForAllRequestsに関する注意事項 は、私が見つけた設定間の相互作用の最良の説明です。IIS モジュールのpreCondition属性に関するドキュメント も読む価値があります。
この動作がデフォルトになるため、QFEを適用している場合、この構成の変更は不要です。
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>
これを使ってみてください：
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
...
</system.webServer>
編集：
上記のソリューションは、.NET 3.5以前で機能します。 .NET 4.0以降を使用している場合は、 IIS7 QFEのインストール を試してください。
また、 この記事 は、これら2つの違いを理解するために読む価値があります。
同様の問題がありました。ここで説明した多くのソリューション（Web.Config system.webServer構成エントリなど）を試してみましたが、役に立ちませんでした。最後に、特定のインストールの問題を発見しました。私は自分のウェブサイトをローカルファイルシステムに公開し、それらのファイルをサーバーにコピーしていました。ファイルGlobal.asaxは公開されたファイルの一部ではないことが判明しました。そのファイルをコピーすると、エラーはなくなりました。
https://stackoverflow.com/a/12521807/695829
私は同じ問題を抱えており、このホットフィックスはそれを修正しました： http://support.Microsoft.com/kb/980368
SonicTheLichenが述べたように、Visual Studioから公開する場合、gloabal.asaxファイルはデフォルトではコピーされません。 global.asaxをWebサーバーにコピーすることで問題が解決するはずです。ソリューションを証明してくれたSonicTheLichenに感謝します。
よろしく、Saurabh
これで問題が解決するかどうかはわかりませんが、IISにデプロイしていたMVCアプリを修正しました。
アプリケーションのhome/virtualディレクトリのaspnet_isapi.dllにワイルドカードアプリケーションマップを追加する必要がありました。これを行うには、Webサイト/仮想ディレクトリを右クリックし、ホームディレクトリ/仮想ディレクトリタブを選択し、構成ボタンをクリックして、ワイルドカードアプリケーションマップセクションの下にある[挿入]ボタンをクリックします。
C：\ WINDOWS\Microsoft.net\Framework64\v4.0.30319\aspnet_isapi.dll
幸運を！
IISのWebサイトプロパティの[ハンドラーマッピング]セクションでスクリプトを有効にする必要がありました。
IISを開き、問題のWebサイトをクリックします。ハンドラーマッピングを開き、[機能のアクセス許可の編集]をクリックします。 [スクリプト]および[実行]のチェックボックスをオンにして、[OK]をクリックします。行ってもいい！
同様の問題がありました。 Windows 2008およびIIS 7.5がインストールされている新しいサーバーに.net MVCサイトを展開する必要がありました。プログラムと機能を確認したところ、.Net Framework 4.5.1のみが.Net 3.5.1 Windows機能を手動で有効にしましたが、MVC 4.0をインストールした後、ルーティングが機能しませんでした。
私の解決策：
1）.Net 4.5.1フレームワークとMVC 4.0を削除します
2）.Net Framework 4.0をインストールします
3）.Net framework 4.5.1のインストール
4）MVC 4.0をインストールします
私はこれが古いことを知っていますが、Windowsの更新は今私のために数時間無駄にしました：
Global.asaxで例外を処理する場合、Windowsの更新を開発環境と同じに保つことで簡単になります。私のglobal.asaxはこれを処理しようとしましたが、同じ問題を抱えていましたが、根本的な問題を隠しています.....