このリリース ノートの最新バージョンについては、ここをクリックしてください。
この問題は次のような場合に発生します。
エラー メッセージの全文は次のとおりです。
アセンブリ 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' から型 'System.ServiceModel.Activation.HttpModule' を読み込めませんでした。
説明: 現在の Web 要求を実行中に、ハンドルされない例外が発生しました。エラーの詳細およびコード内でそのエラーが発生している場所については、スタック トレースを確認してください。
この問題を解決するには:
IIS 7 または IIS 7.5 が有効化され、.NET Framework 4 がインストールされたコンピューターから Beta 2 リリースをアンインストールすると、applicationHost.config ファイル内に、使用されない "isapiCgiRestriction" エントリが残ります。この現象は Windows Vista、Windows Server 2008、および Windows 7 で発生します。使用されないエントリは、Web サーバーの機能には影響しません。以降の .NET Framework 4 のリリースは、同じコンピューターに問題なくインストールできます (後続リリースのインストールでは "isapiCgiRestriction" エントリが更新されるため)。
この問題を解決するには:
applicationHost.config ファイルから "isapiCgiRestriction" エントリを削除します。ただし、アンインストール後に残ったエントリは、製品の機能および後続リリースのインストールに影響しないため、この手順は必須ではありません。
.NET Framework 4 をインストールした後で、.NET Framework 1.0 をインストールすることはできません。 .NET Framework 1.0 は、.NET Framework 4 をインストールする前にインストールする必要があります。
この問題を解決するには:
.NET Framework 4 セットアップ プログラムをインストールできません。
この問題を解決するには:
.NET Framework 4 セットアップ プログラムのトラブルシューティング ガイド (http://go.microsoft.com/fwlink/?LinkId=186690) を参照してください。
.NET Framework 4 (フレームワーク全体) をアンインストールした後、Windows Presentation Foundation (WPF) 4 Font Cache サービスが完全に削除されていません。
メモ: この問題は .NET Framework の完全バージョンと Client Profile バージョンに影響します。
この問題を解決するには:
"[SC] DeleteService SUCCESS" と表示されます。
サービス コンソールを更新しても、Font Cache は表示されません。 更新しても問題が解決されない場合は、コンピューターを再起動します。
.NET Framework 4 Client Profile をインストールした後に .NET Framework 1.0 をインストールすることはできません。 .NET Framework 1.0 は、.NET Framework 4 Client Profile をインストールする前にインストールする必要があります。
この問題を解決するには:
.NET Framework 4 (Client Profile) をアンインストールした後、Windows Presentation Foundation (WPF) 4 Font Cache サービスが完全に削除されていない場合があります。
アンインストール後に WPF Font Cache サービスを使用することはできませんが、"Windows Presentation Foundation Font Cache 4.0.0.0" サービス エントリはサービス コンソールに引き続き表示されます。
Windows Vista および Windows Server 2008 では、サービス コンソールの "説明" フィールドに次のように表示されます: "<説明を読み取れませんでした。エラー コード: 2 >"。 Windows XP および Windows Server 2003 では、"説明" フィールドに正しい文字列が引き続き表示されます。
.NET Framework を再インストールすると、この問題は修復されます。他の影響は不明です。
メモ: この問題は .NET Framework の Client Profile バージョンと完全バージョンに影響します。
この問題を解決するには:
"[SC] DeleteService SUCCESS" と表示されます。
サービス コンソールを更新しても、Font Cache は表示されません。 更新しても問題が解決されない場合は、コンピューターを再起動します。
.NET Framework 4 Client Profile セットアップ プログラムをインストールできません。
この問題を解決するには:
.NET Framework 4 セットアップ プログラムのトラブルシューティング ガイド (http://go.microsoft.com/fwlink/?LinkId=186690) を参照してください。
IIS 7 または IIS 7.5 が有効化され、.NET Framework 4 がインストールされたコンピューターから Beta 2 リリースをアンインストールすると、applicationHost.config ファイル内に、使用されない "isapiCgiRestriction" エントリが残ります。この現象は Windows Vista、Windows Server 2008、および Windows 7 で発生します。使用されないエントリは、Web サーバーの機能には影響しません。以降の .NET Framework 4 のリリースは、同じコンピューターに問題なくインストールできます (後続リリースのインストールでは "isapiCgiRestriction" エントリが更新されるため)。
この問題を解決するには:
applicationHost.config ファイルから "isapiCgiRestriction" エントリを削除します。ただし、アンインストール後に残ったエントリは、製品の機能および後続リリースのインストールに影響しないため、この手順は必須ではありません。
この孤立した Font Cache サービスを完全に削除するための回避策は次のとおりです。
次のように表示されます。 "[SC] DeleteService SUCCESS"
サービス コンソールを更新すると、Font Cache は表示されなくなります。 サービス コンソールを更新しても問題が解決されない場合は、再起動が必要になる可能性があります。
(メモ: この問題はフレームワーク全体の場合ですが、Client Profile の場合の 877240 と同じ問題です。)
この問題を解決するには:
この孤立した Font Cache サービスを完全に削除するための回避策は次のとおりです。
"[SC] DeleteService SUCCESS" と表示されます。
サービス コンソールを更新すると、Font Cache は表示されなくなります。 サービス コンソールを更新しても問題が解決されない場合は、再起動が必要になる可能性があります。
2種類以上の言語の .NET Framework 4 Language Pack がインストールされている環境において、コントロールパネルのプログラムと機能から、Microsoft .NET Framework 4 Client Profile もしくは Microsoft .NET Framework 4 Extended の修復をしようとした場合、修復に失敗する場合があります。
この問題を解決するには:
コントロールパネル経由ではなく、 .NET Framework 4 のインストーラーを直接起動して修復します。 すでにコントロールパネル経由で修復を実行して 修復に失敗している場合は、一旦 .NET Framework 4 本体及び 関連する Language Pack をすべて削除してから再度インストールし直します。削除する際には、コントロールパネル経由ではなく、インストーラーを直接起動して削除します。また、削除の順番は、Language Pack をすべて削除してから .NET Framework 4 の本体を削除する順番になります。
2種類以上の言語の .NET Framework 4 Language Pack がインストールされている環境において、コントロールパネルのプログラムと機能から、いずれかの言語の Microsoft .NET Framework 4 Client Profile Language Pack もしくは Microsoft .NET Framework 4 Extended Language Pack を削除しようとした場合、見かけ上すべての 言語の Language Pack が削除されたように見える場合があります。
この問題を解決するには:
コントロールパネル経由ではなく、 .NET Framework 4 Language Pack のインストーラーを直接起動して削除します。 既にコントロールパネル経由で削除を実行して、表示上すべての 言語の Language Pack が削除されたように見えている場合は、個々の .NET Framework 4 Language Pack のインストーラーを起動して、削除するべきものを削除し、残すべきものについては修復インストールをします。
Vista/XP/w2k3/W2k8 から .NET 4.0 をアンインストールしても、WPF Font Cache サービスは正しくアンインストールされません。
アンインストール後に WPF Font Cache サービスを使用することはできませんが、"Windows Presentation Foundation Font Cache 4.0.0.0" サービス エントリは残って、サービス コンソールに表示されます。
Vista および W2k8 では、サービス コンソールの "説明" フィールドに次のように表示されます: "<説明を読み取れませんでした。エラー コード: 2 >"。 XP および w2k3 では、"説明" フィールドに正しい文字列が引き続き表示されます。
.NET Framework を再インストールすると、この問題は修復されます。他の影響は不明です。
メモ: この問題は .NET Framework 4 Client Profile および .NET Framework 4 フレームワーク全体についてのものです。
この問題を解決するには:
この孤立した Font Cache サービスを完全に削除するための回避策は次のとおりです。
"[SC] DeleteService SUCCESS" と表示されます。
サービス コンソールを更新すると、Font Cache は表示されなくなります。 サービス コンソールを更新しても問題が解決されない場合は、再起動が必要になる可能性があります。
(メモ: この問題は Client Profile の場合ですが、フレームワーク全体の場合の 888322 と同じ問題です。)
[必須コンポーネント] ダイアログ ボックスの [アプリケーションと同じ場所から必須コンポーネントをダウンロードする] オプションが選択されていて、必須コンポーネントとして次のコンポーネントが選択されている場合、Visual Studio 2010 の簡体字中国語バージョンまたは繁体字中国語バージョンを使用してアプリケーションを発行しようとすると、ビルド エラーが表示される可能性があります。
Microsoft .NET Framework 4 Client Profile (x86 および x64) について生じる可能性のあるビルド エラーを次に示します。
"MSB3152: 必須コンポーネントのインストール場所が、'コンポーネントの開発元の Web サイト' に設定されていません。項目 'Microsoft .NET Framework 4 Client Profile (x86 および x64)' のファイル 'DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe' がディスクに見つかりません。詳細については、ヘルプを参照してください。"
この問題を回避するには:
簡体字中国語の問題を回避するには、次の手順に従います。
<String Name="Culture">zh-chs</String>
繁体字中国語の問題を回避するには、次の手順に従います。
<String Name="Culture">zh-cht</String>
[必須コンポーネント] ダイアログ ボックスの [必須コンポーネントをコンポーネントの開発元の Web サイトからダウンロードする] オプションが選択されていて、必須コンポーネントとして次のいずれかのコンポーネントが選択されている場合、Visual Studio 2010 の簡体字中国語バージョンまたは繁体字中国語バージョンを使用してアプリケーションを発行しようとすると、簡体字中国語または繁体字中国語用の Language Pack をインストールできない可能性があります。
この問題を回避するには:
簡体字中国語の問題を回避するには、次の手順に従います。
<String Name="Culture">zh-chs</String>
繁体字中国語の問題を回避するには、次の手順に従います。
<String Name="Culture">zh-cht</String>
Windows 7 が実行され、IIS 7.5 が有効になっているクライアントまたはサーバー コンピューターに .NET Framework 4 をインストールすると、アプリケーション プールごとに ASP.NET 構成ファイルを設定する機能は無効になります。この問題が発生する原因は、.NET Framework 4 をインストールすることによって、共通言語ランタイム (CLR: Common Language Runtime) の初期化時の既定の動作が若干変更されることです。.NET Framework 4 をインストールすると、Windows 7 上の IIS 7.5 がネイティブ ASP.NET 4 DLL を呼び出して CLR の初期化を実行しますが、この初期化ロジックでは、複数の構成ファイルの使用が有効になりません。
この問題を解決するには:
CLR の初期化ロジックは、構成ファイルの副作用を除き、基本的に .NET Framework 4 および IIS 7.5 の場合と同様であるため、IIS 7.5 を再構成して、CLR の初期化が ASP.NET 4 にデリゲートされないようにすることができます。その方法は 2 つあります。
方法 1
----------
次の例のように、IIS 7.5 の applicationHost.config ファイルで managedRuntimeLoader 属性の既定値を空の文字列に設定します。
<applicationPools>
<applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>
方法 2
----------
IIS 7.5 の IIS_Schema.xml ファイルで managedRuntimeLoader 属性の defaultValue を空の文字列に設定します。たとえば、次の例のような属性があるとします。
<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />
この場合、次のマークアップに変更します。
<attribute name="managedRuntimeLoader" type="string" defaultValue="" />
Windows XP および Windows Server 2003 (すべてのバージョン) では、IIS から ASP.NET 4 の登録を解除して再登録すると、IIS MMC の [ASP.NET] タブの ASP.NET バージョンの一覧に空の値が表示されます。この問題を再現するには、次の手順を実行します。
この問題を解決するには:
IIS MMC の ASP.NET バージョンの一覧で、目的の ASP.NET バージョンを手動で選択し、[適用] ボタンをクリックします。
Windows Vista、Windows Server 2008、および Windows 7 では、IIS ワーカー プロセスに Windows の一時ディレクトリ (%WINDOWS%\Temp) への書き込みアクセス許可がないことが原因で、一部の ASP.NET コンパイル タスクが失敗することがあります。WSDL ファイルに依存する Web サービス参照などの項目をコンパイルしようとすると、"パーサー エラー メッセージ: 一時クラスを生成できませんでした。" のようなエラーが表示される場合があります。
このエラーは、コンピューター上で IIS が有効化され、.NET Framework 4 がインストールされた状態で、ASP.NET および .NET 拡張機能が有効化されていない場合に発生します。
この問題を解決するには:
方法 1
----------
IIS ワーカー プロセス アカウントに Windows 一時ディレクトリ (%WINDOWS%\Temp) への書き込みアクセス許可を明示的に与えます。その 1 つの方法は、IIS_IUSRS など、ワーカー プロセス アカウントを含むグループに書き込みアクセス許可を与えることです。
方法 2
---------
ASP.NET および .NET 拡張機能を有効にします。Windows コントロール パネルの [プログラム] を開き、[プログラムと機能] で [Windows の機能を有効化または無効化] をクリックします。[Windows の機能] ダイアログ ボックスで、[インターネット インフォメーション サービス]、[World Wide Web サービス]、[アプリケーション開発機能] の順に開き、次の機能を有効にします。
.NET 拡張機能
ASP.NET
aspnet_compiler.exe コマンド ライン ツールを使用して、ASP.NET Web サイトをプリコンパイルできます。生成されたアセンブリにキーで署名する場合は、Web サイトの Bin フォルダーではなく、GAC にアセンブリを配置することができます。
ASP.NET 4 では、部分信頼で動作している Web サイトが GAC からアセンブリを読み込もうとすると、System.Security.SecurityException 例外がスローされます。この例外が発生する原因は、ASP.NET 4 で、旧バージョンの ASP.NET よりも新しいコード アクセス セキュリティ (CAS: Code Access Security) の実装が既定で使用されることです。新しい CAS 実装では、SecurityTransparent 属性を使用して、GAC に配置されたプリコンパイル済みで署名済みのアセンブリを明示的にマークする必要があります。
この問題を解決するには:
方法 1
--------
コンパイルする前に、次の例のように、SecurityTransparent 属性を使用してアセンブリにマークを設定します。
[assembly:System.Security.SecurityTransparentAttribute]
方法 2
--------
記事「方法: プリコンパイルされた Web サイトのバージョン付きアセンブリを作成する」(http://msdn.microsoft.com/ja-jp/library/ms228042.aspx) の説明に従って、Web サイトの Web.config ファイルに compilerOptions の設定を追加します。この手順の一部として、compilerOptions の設定で参照される AssemblyInfo.vb ファイルまたは AssemblyInfo.cs ファイルに次の 1 行を追加します。
[assembly:System.Security.SecurityTransparentAttribute]
方法 3
--------
次の属性を含むダミー クラス ライブラリを作成します。
[assembly:System.Security.SecurityTransparentAttribute]
クラス ライブラリをアセンブリにコンパイルし、プリコンパイル済み Web サイトの出力で、次の例に示すように、copyattrs オプションを使用して aspnet_merge.exe コマンド ライン ツールを実行します。
aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll
DLL 名には、SecurityTransparent 属性を使用してマークしたダミー クラス ライブラリの名前を使用します。
方法 4
--------
次の例のように、Web サイトの Web.config ファイルの trust 要素の legacyCasModel 属性を true に設定して、一時的に古い CAS モードに戻します。
<trust level="Medium" legacyCasModel="true"/>
この変更を行った後に、プリコンパイル済みアセンブリに SecurityTransparent 属性を追加するときには、別のオプションのいずれかを使用することをお勧めします。それによって、legacyCasModel 属性を削除して、Web サイトを新しい CAS モードで実行できます。
ASP.NET または Windows Communication Foundation (WCF) アプリケーションのアプリケーション Web.config ファイルに新しい構成セクションを追加すると、そのアプリケーションは IIS 7 Integrated mode では起動しません。
たとえば、WCF アプリケーションの Web.config ファイルに <standardEndpoints> 構成セクションが追加されると、アプリケーションは IIS 7 統合モードでは起動しません。IIS 7 構成システムは新しい構成セクションを認識できず、構成の検証エラーを返します。
この問題を解決するには:
この問題の修正プログラムを、公開されている入手先からダウンロードしてインストールします。 修正プログラムは、http://support.microsoft.com/kb/958854 から入手できます。また、この修正プログラムが含まれている Windows Vista SP 2 をインストールすることもできます。 Windows 7 および Windows Server 2008 R2 では、必要な修正プログラムが既に含まれているため、この問題は発生しません。
.NET Framework 4 をコンピューターにインストールした後に、IIS 7/7.5 または IIS7/7.5 .NET 拡張機能が有効になった場合は、ASP.NET 4 を再登録する必要があります。コンピューターに .NET Framework Version 4 がインストールされている状態で、.NET 拡張機能が削除された場合も、ASP.NET 4 を再登録する必要があります。
オペレーティング システムでの IIS7 と IIS 7.5 および .NET 拡張機能のインストールおよびアンインストールのプロセスの設計が、上位バージョンの .NET Framework が既にコンピューターに存在する場合に対応していなかったため、いずれの場合も再登録が必要です。
この問題を解決するには:
ASP.NET 4 を再登録するには、次のコマンドを実行します。
aspnet_regiis -iru -enable
.NET Framework 4 インストール ディレクトリにインストールされたバージョンの aspnet_regiis.exe を使用してください。
リモート Web サーバーを管理しているときにローカル コンピューターで管理コンソール (MMC) を実行した場合、[ASP.NET] タブが表示されないことがあります。この現象が発生するのは、ASP.NET がインストールされている Web サーバーを IIS 6 管理ツールでリモート管理している場合と、ローカル コンピューターで Windows Server 2008 x64、Windows 7、または Windows Server 2008 R2 (x86 または x64) が実行されている場合です。
この問題を解決するには:
この問題の回避策はありません。
ASP.NET 2.0 バージョンの "aspnet_regiis -ua" コマンドを Windows Vista、Windows Server 2008、Windows 7、または Windows Server 2008 R2 で実行すると、次のエラー メッセージが表示されます。
この要求は、サポートされていません。
このエラーが発生するのは、ASP.NET 2.0 バージョンの "aspnet_regiis" コマンドが、コンピューターにそれ以降のバージョンの ASP.NET が存在していることを検出できないためです。
この問題を解決するには:
ASP.NET 4 バージョンの "aspnet_regiis -ua" コマンドを実行して、コンピューター上のすべてのバージョンの ASP.NET の登録を解除します。
ASP.NET 2.0 では、"aspnet_regiis -i" コマンドにより、Windows Server 2003 上のすべての仮想ディレクトリが ASP.NET 2.0 を使用するように再帰的にアップグレードされます。ASP.NET 4 では、Windows Server 2003 で "aspnet_regiis -i" コマンドを実行した場合、IIS 6 のルートのみが ASP.NET 4 にアップグレードされます。ルートの下の仮想ディレクトリが、特定のバージョンの ASP.NET を実行するように明示的に設定されている場合、それらの仮想ディレクトリは、ルート ディレクトリから ASP.NET 4 設定を継承せずに、明示的に設定されている ASP.NET のバージョンを保持します。
この問題を解決するには:
次のいずれかのコマンドの ASP.NET 4 バージョンを実行します。
aspnet_regiis -s
aspnet_regiis -r
これらのコマンドにより、すべての仮想ディレクトリが ASP.NET 4 に再帰的に更新されます。
ASP.NET 4 が既に登録されているオペレーティング システムの任意のバージョンで ASP.NET 2.0 の登録を解除すると、ASP.NET 4 の一部のパフォーマンス カウンターの登録が破損します。これが発生するのは、ASP.NET 2.0 の登録解除プロセスが、コンピューターにそれ以降のバージョンの ASP.NET がインストールされていることを検出できないためです。結果として、特定の ASP.NET 4 のパフォーマンス カウンターを使用しているときに、アプリケーションのイベント ログに次のエラー メッセージが表示される場合があります。
"ASP.NET" サービスの DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" の Open プロシージャ "%pef_counter_name%" が見つかりません。"
""ASP.NET" サービスのパフォーマンス カウンター ライブラリでエラーが発生したため、このサービスのパフォーマンス カウンター データ コレクションが無効になっています。"
この問題を解決するには:
ASP.NET 4 バージョンの "aspnet_regiis -iru" コマンドを実行します。 これにより、ASP.NET 4 のパフォーマンス カウンターが再登録されます。
既定では、次のシナリオで、SQL Server Express ユーザー インスタンスに依存する ASP.NET 4 Web プロジェクトおよび Web アプリケーションは動作しません。
この問題を解決するには:
これらの問題に対処する方法の詳細については、次の場所にある記事を参照してください。
http://go.microsoft.com/fwlink/?LinkID=160102 (英語)
ASP.NET 4 では、既定の Web.config ファイルのサイズが大幅に縮小されています。その結果、IIS 7 (Windows Vista および Windows Server 2008 上) と IIS 7.5 (Windows Server 2008 R2 上) によって構成エラーがスローされます。具体的なエラーは、オペレーティング システムにインストールされている更新プログラムと、アプリケーションレベルの Web.config ファイルに格納されている構成情報の種類によって異なります。
Windows Vista SP1 または Windows Server 2008 SP1 に、修正プログラム KB958854 も SP2 もインストールされていない場合。この構成では、IIS 7 構成システムによって、アプリケーションレベルの Web.config ファイルと ASP.NET 2.0 の machine.config ファイルが比較され、アプリケーションのマネージ構成が誤って結合されます。 このため、IIS 7 の検証エラーが発生しないようにするには、.NET Framework 3.5 または .NET Framework 4 のアプリケーションレベルの Web.config ファイルに、<system.web.extensions> 構成セクションが含まれている必要があります。 手動で変更されたアプリケーションレベルの Web.config ファイルのエントリが、Visual Studio 2008 で導入された元のスケルトン構成セクションの定義と正確に一致していない場合、構成エラーが発生します (Visual Studio 2008 によって生成された既定の構成エントリは正常に機能します)。よくある問題は、手動で変更された Web.config ファイルで、さまざまな構成セクションの定義に存在する構成属性 "allowDefinition" および "requirePermission" が除外されていることです。結果として、アプリケーションレベルの Web.config ファイル内の省略された構成セクションと、ASP.NET 4 の machine.config ファイル内の定義全体との間に不一致が生じます。 このことが原因になり、実行時に、ASP.NET 4 構成システムによって構成エラーがスローされます。
Windows Vista SP2、Windows Server 2008 SP2、Windows 7、Windows Server 2008 R2、および修正プログラム KB958854 がインストールされた Windows Vista SP1、Windows Server 2008 SP1 の場合。このシナリオでは、IIS 7 および IIS 7.5 のネイティブな構成システムによって構成エラーが返されます。これは、マネージ構成セクション ハンドラーに定義されている "type" 属性でテキスト比較が実行されるためです。 Visual Studio 2008 および Visual Studio 2008 SP1 によって生成されたすべての Web.config ファイルでは、<system.web.extensions> (および関連する) 構成セクションの type の文字列に "3.5" が含まれ、ASP.NET 4 の machine.config ファイルでは、同じ構成セクションの "type" 属性に "4.0" が含まれているため、Visual Studio 2008 または Visual Studio 2008 SP1 で生成されたアプリケーションは、IIS 7 および IIS 7.5 での構成の検証に常に失敗します。
この問題を解決するには:
1 つ目の解決策は、Visual Studio 2008 によって自動的に生成された Web.config ファイルのスケルトン構成テキストを含めて、アプリケーションレベルの Web.config ファイルを更新することです。
2 つ目の解決策は、アプリケーションレベルの Web.config ファイルから、すべての <system.web.extensions> 構成セクションの定義および構成セクション グループの定義を削除するか、コメント アウトすることです。
System.Web.Hosting.IProcessHostPreloadClient.Preload メソッドでは、文字列配列を引数として受け取ります。 ただし、このデータを設定する方法はなく、このパラメーターに情報が渡されません。
この問題を解決するには:
以前の、プレビュー バージョンの IIS 7.5 の自動起動機能では、ASP.NET 4 の IProcessHostPerloadClient.Preload メソッドに渡す 1 つ以上の文字列値を構成する方法がサポートされていました。 ただし、この機能は、Windows 7 および Windows Server 2008 R2 の最終リリースの前に削除されました。
IIS 7 および IIS 7.5 .NET 拡張機能は、[Windows の機能] ダイアログ ボックスで IIS 7 または IIS 7.5 の機能をインストールまたはアンインストールするために使用できる構成オプションです。 この機能は、次のノードにあります。
[インターネット インフォメーション サービス] > [World Wide Web サービス] > [アプリケーション開発機能] > [.NET 拡張機能]
Windows Vista、Windows Server 2008、Windows 7、および Windows Server 2008 R2 では、.NET 拡張機能の影響を受けるのは、ASP.NET 2.0 の IIS 7 または IIS 7.5 との統合のみです。ASP.NET 4 の IIS 7 または IIS 7.5 への登録または登録解除には影響しません。
この問題を解決するには:
ASP.NET 4 と IIS 7 または IIS 7.5 の統合を行うには、ASP.NET 4 バージョンの "aspnet_regiis.exe" コマンドを使用します。
Windows Server 2003 または Windows Server 2003 R2 の場合、IIS 6 上で ASP.NET 2.0 アプリケーションを実行すると、次のようなエラーが発生することがあります。
System.Web.HttpException: パス '/[アプリケーションのルート]/eurl.axd/[値]' が見つかりませんでした。
このエラーは、IIS 6 上で ASP.NET 4 を有効にした後にのみ発生します。このエラーが発生するのは、Web サイトが ASP.NET 4 を使用する構成になっていることを ASP.NET が検出すると、ASP.NET 4 のネイティブ コンポーネントによって、拡張子のない URL が ASP.NET のマネージ部分に渡されて、その処理が続行されることが原因です。
ただし、ASP.NET 4 Web サイトの下の仮想ディレクトリが ASP.NET 2.0 を使用する構成になっている場合は、拡張子のない URL がこの方法で処理されると、eurl.axd を含む URL に変更されてから ASP.NET 2.0 アプリケーションに送信されます。ASP.NET 2.0 は eurl.axd 形式を認識できません。 そのため、ASP.NET 2.0 は、eurl.axd という名前のファイルを検索して実行しようとします。 そのような名前のファイルは存在しないため、要求は失敗し、HttpException 例外が発生します。
この問題を解決するには:
方法 1
--------
Web サイトの実行に ASP.NET 4 を使用する必要がない場合は、ASP.NET 2.0 を使用するようにサイトを再マップします。
方法 2
---------
Web サイトの実行に ASP.NET 4 を使用する必要がある場合は、すべての ASP.NET 2.0 子仮想ディレクトリを、ASP.NET 2.0 にマップされた別の Web サイトに移動します。
方法 3
---------
Web サイトを ASP.NET 2.0 に再マップすること、または仮想ディレクトリの場所を変更することが現実的でない場合は、ASP.NET 4 での拡張子のない URL の処理を、次の手順に従って明示的に無効にします。
1. Windows レジストリで、次のノードを開きます。:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>
メモ: <build#> は .NET Framework 4 のリリース バージョンのビルド番号です。
2. "EnableExtensionlessUrls" という名前の DWORD 値を作成します。
3. "EnableExtensionlessUrls" を 0 に設定します。これにより、拡張子のない URL の動作が無効になります。
4. レジストリ値を保存し、レジストリ エディターを閉じます。
5. "iisreset" コマンド ライン ツールを閉じます。これにより、IIS で新しいレジストリ値が読み取られます。
メモ: EnableExtensionlessUrls を 1 に設定すると、拡張子のない URL の動作が有効になります。値を指定しない場合は、これが既定の設定です。
Entity Framework を使用した Web プロジェクトに必要な名前空間およびアセンブリへの参照は、ルート Web.config ファイルの RTM バージョンから削除されました。そのため、EntityDataSource を使用した Dynamic Data Web サイト、および ASP.NET 4 のプレリリース バージョンを使用して作成された Entity Framework を使用している Web アプリケーションではコンパイル エラーが発生します。
この問題を解決するには:
見つからないアセンブリおよび名前空間をアプリケーションの Web.config ファイルに追加できます。assembly 要素および namespace 要素を手動でアプリケーション レベルの Web.config ファイルに追加する場合の例を次に示します。
<system.web>
<compilation>
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add assembly="System.Web.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add assembly="System.Data.Entity.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
<pages>
<namespaces>
<add namespace="System.Data.Entity.Design" />
<add namespace="System.Data.Linq" />
</namespaces>
</pages>
</system.web>
Windows Vista、Windows Server 2008、Windows 7、および Windows Server 2008 R2 では、.NET Framework Version 2.0 および Version 4 の一定のインストール順序の場合に、ASP.NET 4 アプリケーションの実行中に RoleManagerModule クラスからハンドルされない NullReferenceException エラーがスローされます。このエラーは、IIS 7 または IIS 7.5 に登録されている ASP.NET のバージョンが ASP.NET 4 のみであると共に、ASP.NET 2.0 を IIS に登録したことがない場合、または ASP.NET 2.0 の登録を IIS 7 または IIS 7.5 から解除した場合に発生します。
いずれの場合も、ASP.NET 4 のみの登録では、構成ファイル内で、Integrated-mode のアプリケーションで使用する 2 つの HTTP モジュールが正しい順序ではなくなります。
この問題を解決するには:
ASP.NET 4 のリリース バージョンではこの問題が解決されていますが、プレリリース バージョンでは、モジュールの順序が正しく指定されない場合があります。ASP.NET 4 のプレリリース バージョンから RTM バージョンにアップグレードした後にも、ハンドルされない例外が発生する場合は、次の手順を実行します。
1. 次のフォルダーにある applicationHost.config ファイルを開きます。
%windir%\System32\inetsrv\config
2. 次の要素を検索します。
<location path="" overrideMode="Allow">
この要素では、Integrated mode の HTTP モジュールの一覧を取得します。この情報は <modules> 要素にあります。
3. 次の文字列で始まる要素を探します。
<add name="RoleManager" ...
4. この要素を次の文字列で始まる要素の下に移動します。
<add name="DefaultAuthentication"...
5. ファイルを保存します。
完了後は、<modules> 定義の一部が次の例のようになります。
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />
拡張子のない URL を使用した MVC 2 および ASP.NET 4 の Web フォーム アプリケーションを Windows Vista、Windows Server 2008、Windows 7、または Windows Server 2008 R2 上で実行すると、HTTP 404 エラーが発生することがあります。このエラーが発生するのは、.NET Framework 拡張機能オプションを有効にして、[Windows の機能] ダイアログ ボックスで IIS をインストールした場合のみです。IIS の最小インストールでは、一部の HTTP モジュールが含まれません。ASP.NET および IIS による HTTP パイプライン イベント遷移の管理方法が原因で、HTTP モジュールが不足しているために、ASP.NET の URL ルーティング モジュールが適切なタイミングで実行されません。その結果、拡張子のない URL に対する要求が URL ルーティング モジュールによって処理されず、404 エラーが発生します。
この問題を解決するには:
Windows のコントロール パネルの [Windows の機能を有効化または無効化] ダイアログ ボックスにある
[プログラムと機能] で、次の手順を実行します。
1. 次のノードに移動します。
[インターネット インフォメーション サービス] --> [World Wide Web サービス] --> [HTTP 共通機能]
2. [HTTP リダイレクト] が選択されていることを確認します。
- または -
1. 次のノードに移動します。
[インターネット インフォメーション サービス] --> [World Wide Web サービス] --> [性能機能]
2. [静的コンテンツ圧縮] が選択されていることを確認します。
いずれかのオプションを選択したら、[OK] をクリックして変更を保存します。
[HTTP リダイレクト] モジュールまたは [静的コンテンツ圧縮] モジュールを再度有効にすると、ASP.NET および IIS が HTTP パイプライン イベントと確実に同期し、URL ルーティング モジュールで拡張子のない URL を処理できるようになります。
旧バージョンの ASP.NET では、System.Web.Mobile.dll アセンブリへの参照がルート Web.config ファイルの <system.web><compilation> の <assemblies> セクションに含まれていましたが、パフォーマンスを改善するために、このアセンブリは削除されました。
この問題を解決するには:
System.Web.Mobile.dll アセンブリは ASP.NET 4 に含まれていますが、非推奨です。System.Web.Mobile.dll アセンブリの型を使用する場合は、このアセンブリへの参照を、ルートの Web.config ファイルまたはアプリケーションの Web.config ファイルに追加します。たとえば、非推奨の ASP.NET モバイル コントロールを使用する場合は、Web.config ファイルに System.Web.Mobile.dll アセンブリへの参照を追加する必要があります。
ブラウザー定義ファイルが更新され、ブラウザーとデバイスに関する新しい情報および更新された情報が含まれるようになりました。 Netscape Navigator などの古いブラウザーおよびデバイスが削除され、Google Chrome、Apple iPhone などの新しいブラウザーおよびデバイスが追加されました。
この問題を解決するには:
ASP.NET 4 で古いブラウザー定義ファイルを使用できます。古いブラウザー定義ファイルおよびそのインストールに関するドキュメントは、ASP.NET ブラウザー定義ファイルのリリース (http://go.microsoft.com/fwlink/?LinkID=186493) に含まれています。
Microsoft Ajax JavaScript ファイルのローカライズ版 (MicrosoftAjax.debug.ja.js など) が Microsoft Ajax Content Delivery Network (CDN) に追加されるのは、.NET Framework 4 Language Pack がリリースされた後です。 そのため、.NET Framework 4 および ローカライズ版の CDN の使用時には、ScriptManager.EnableCdn プロパティを有効にしないでください。
この問題を解決するには:
Microsoft Ajax Content Delivery Network (CDN) は .NET Framework 4 Language Pack がリリースされてから使用してください。それまでは、アプリケーションの ScriptManager コントロールに EnableCdn="true" を指定しないでください。
ASP.NET 4 をインストールすると、汎用 ASP.NET パフォーマンス カウンターには、ASP.NET 4 アプリケーション以外からのデータが報告されなくなります。 ASP.NET 1.1、ASP.NET 2.0、および ASP.NET 3.5 のアプリケーションで汎用パフォーマンス カウンターを使用しても、パフォーマンス カウンターにデータは報告されません。 旧バージョンの ASP.NET を実行するアプリケーションのパフォーマンス データには、バージョン付きの ASP.NET パフォーマンス カテゴリを使用する必要があります。
汎用 ASP.NET パフォーマンス カウンターには、パフォーマンス カウンター カテゴリとして、 "ASP.NET" および "ASP.NET アプリケーション" があります。
バージョン付きの ASP.NET パフォーマンス カテゴリには、"ASP.NET v2.0.50727" や "ASP.NET Apps v2.0.50727" のような名前が付いています。
この問題を解決するには:
この動作は仕様です。 コンピューターにインストールされている ASP.NET の最新バージョンが汎用パフォーマンス カウンターのカテゴリを "所有" します。 そのため、異なるバージョンの ASP.NET を実行する複数の ASP.NET アプリケーションからパフォーマンス データを収集する場合は、バージョン付きパフォーマンス カウンター カテゴリを使用することをお勧めします。
既知の問題はありません。
既知の問題はありません。
既知の問題はありません。
既知の問題はありません。
既知の問題はありません。
.NET Framework 4 を Beta 2 から RTM バージョンにアップグレードすると、サービスを開始したとき、または IIS をリセットしたときに次のエラーが発生する場合があります。
"指定されたファイルが見つかりません。"
この問題を解決するには:
コントロール パネルの [プログラム] で、.NET Framework Client Profile を修復します。ただし、複数言語の Language Pack（例えば日本語版とドイツ語版）を既にインストールされている場合は、2.2.1.3 に書かれている方法で修復してください。
ia64 コンピューターで、WPF アセンブリはインストールもサポートもされません。
この問題を解決するには:
この問題の回避策はありません。ia64 で WPF は使用できません。
sizeof 演算子を含むワークフローを検証すると、例外がスローされます。
この問題を解決するには:
ワークフローで sizeof 演算子を使用しないでください。
.NET Framework 4 Client Profile は ia64 でサポートされていません。
この問題を解決するには:
ia64 の .NET Framework 4 をアンインストールする場合は、必ず完全バージョンと Client Profile バージョンの両方をアンインストールします。
© 2010 Microsoft Corporation. All rights reserved.
使用条件 | 商標 | プライバシーに関する声明