.NET Framework 4.5 は既定で、.NET Framework 3.5 は省略可能です
プラットフォーム
クライアント Windows 8
サーバー Windows Server 2012
説明
Windows 8では、.NET Framework 4.5 が既定で有効になっています。 Windows 8には既定では .NET 3.5 は含まれませんが、.NET 3.5 のファイルはオプション機能としてWindows 8インストール メディアで使用できます。
ユーザーが Windows 7 からWindows 8にアップグレードする場合は、コンピューター上のすべてのアプリが引き続き正常に動作するように、.NET Framework 3.5 が完全に有効になっています。
症状
ユーザーがWindows 8のクリーンインストールを実行し、.NET Framework 3.5 (または 2.0) を必要とするアプリをインストールすると、必要な .NET 3.5 ファイルの要求がトリガーされます。 通常、見つからないファイルはWindows Updateからダウンロードされますが (ユーザーにアクセス許可を求めた後)、Windows Updateへのアクセスが不可能な場合、.NET Framework 3.5 を有効にすると、見つからないファイルの代替ソースが指定されていない限り失敗します。
対応策
.NET Framework 3.5 を、Windows 8のクリーンインストールがあるテスト マシンでのみ有効にするには:
マウントされたオペレーティング システム ビルド ISO イメージから 、\sources\sxs\ を dotnet35 または同様のフォルダーにコピーします。 たとえば次のような点です。
xcopy e:\sources\sxs\*.* c:\dotnet35 /s管理者特権を使用して、次のコマンド ラインを実行します。
Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:c:\dotnet35 /LimitAccess
Note
sources\SxS フォルダーは、サポートされているメカニズムではないため、再配布メカニズムとして使用しないでください。
解決策
コンシューマーの場合:
Windows 8には、再頒布可能パッケージをインストールしようとしたとき、または .NET 3.5 を必要とするアプリケーション インストーラーが再頒布可能パッケージを呼び出すときに、.NET Framework 3.5 を自動的に有効にするメカニズムが含まれています。
アプリ開発者 (および IT 管理者) の場合:
IT 管理者は、.NET 3.5 または .NET 4.5 で実行するように .NET 3.5 アプリを構成できます (既にインストールされている内容に応じて)。 マネージド アプリを 3.5 または 4.5 で実行するには、アプリケーション構成ファイルにセクションを追加するだけです。 これにより、.NET 3.5 がインストールされている場合、アプリは .NET 3.5 で実行されます。それ以外の場合、アプリは .NET 4.5 で実行されます。 構成ファイルの追加セクションの例を次に示します。
<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
</startup>
</configuration>
エンタープライズ OEM の場合:
EEAP ビルドと、Windows Updateにアクセスできないアプリケーションに対して .NET Framework 3.5 を有効にするには:
マウントされた OS ビルド ISO イメージから dotnet35 または同様のフォルダーに \sources\sxs\ をコピーします。 たとえば次のような点です。
xcopy e:\sources\sxs\*.* c:\dotnet35 /sregkey を設定します。
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing] LocalSourcePath = c:\dotnet35
企業の場合:
サービスに WSUS を使用するように構成されているマシンの場合は、レジストリ エントリを設定して、マシンが WSUS ではなく .NET 3.5 を有効にするためにWindows Updateを使用できるようにすることができます (この操作を行うと、WSUS からサービスが引き続き実行されます)。
- regkey を設定します。
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing] RepairContentServerSource =DWORD(2)
このレジストリ エントリは、グループ ポリシー (ローカル コンピューター ポリシー - コンピューター構成 -> 管理用テンプレート ->> システム) を使用して設定することもできます。 [オプションのコンポーネントのインストールとコンポーネントの修復の設定を指定する] 設定を選択します。
Windows Server Update Services (WSUS) ではなく修復コンテンツを直接ダウンロードするために [連絡先Windows Update] を選択した場合、Windows 機能 (.NET Framework 3.5 など) または修復機能を追加しようとすると、Windows Updateからのファイルのダウンロードがトリガーされます。 ターゲット コンピューターでは、このオプションにインターネットと WU アクセスが必要です。 通常のサービス操作では、ソースとして構成されている場合でも WSUS が引き続き使用されます。
レジストリ エントリを使用したローカル ソースの場所の設定に関する注意事項
IT 管理者は、レジストリ エントリを使用して .NET 3.5 ファイルのローカル ソースの場所を設定できるため、ユーザーは [Windows 機能の追加と削除] ダイアログを使用して、ソースの場所を指定しなくてもペイロードが不足している機能を有効にすることができます。 レジストリ エントリの値は、グループ ポリシーを使用して制御できます。
このレジストリ エントリはサポートされています。
| 入力 | Type | 説明 |
|---|---|---|
| ローカル ソース パス | REG_EXPAND_SZ | 既定で使用されるローカル ソース パス。 複数のパスを指定できます。これらは、 で区切る必要があります。 場所は、指定された順序で検索されます。 DISM コマンド ラインで指定されたローカル ソースの場所は、このレジストリ エントリで指定された場所よりも優先されます。 フォルダーの場所は、このレジストリ エントリで指定できます。 WIM を使用できますが、WIM ファイルへのパスを指定する必要があります。マウントする必要はありません。次に例を示します。
マウントされた WIM の場合、ソース パスはマウント ポイントではなく、マウントされたイメージの windows ディレクトリを参照する必要があります (たとえば、/source:mount_point ではなく /source:<<mount_point>>\windows)。 |
リソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示