Windows 8 における .NET Framework 3.5(2.0) の扱いについて

Question

Windows 8 Consumer Preview では、.NET Framework 3.5(2.0) がインストールされていません。

そのため、.NET 3.5 を利用したアプリケーションのインストールが出来ません。

現状、「コントロールパネル」－「プログラム」－「Windowsの機能の有効化または無効化」 から 「.NET Framework 3.5」 を有効にする必要があります。

　

このとき、Windows Update からインストールを行うと異常なほど時間がかかります。

この仕様は、Windows 8 の最終版でも変わらないのでしょうか？

　

また、ユーザーの手間を取らせずに、簡単に素早く .NET Framework をインストールする方法はあるのでしょうか？　

ご存じの方がいらしたら、ぜひ教えてください。　

以上、よろしくお願いします。

Answer 1

>このとき、Windows Update からインストールを行うと異常なほど時間がかかります。

>この仕様は、Windows 8 の最終版でも変わらないのでしょうか？

最終版でどうなるかは誰もわかりません。
しかるべき手段でもってリクエストをあげればそうなるかもしれません。

> また、ユーザーの手間を取らせずに、簡単に素早く .NET Framework をインストールする方法はあるのでしょうか？　

.NET FrameworkはWindowsUpdate以外にも再頒布版からインストールできます。
Windows8にインストールできるか知りませんが、試してみてはどうでしょうか。

Answer 2

> 最終版でどうなるかは誰もわかりません。

それはそうなんですけどね。

マイクロソフトの人が方向性だけでも回答してくれないかなとの期待で質問してみました。

　

> .NET FrameworkはWindowsUpdate以外にも再頒布版からインストールできます。

再配布版は実行すると、キャンセルされ、「Windowsの機能」から Windows Update へと誘導されて、同じ対応となります。

ただ、こちらの方がダウンロードはかなり早いようです。

　

.NET 3.5 以前のアプリを提供している方々は、どう対応するのでしょうね？

サポートも含め考えると、　.NET 4.5 で再ビルドして、テストしてリリースした方が良いかもしれませんね。

Answer 3

.NETではビルドに使用したバージョンと、実行に使うバージョンを切り替えることができます。また実行に使うバージョンは複数指定することもできます。

ですので、3.5でビルドしたモジュールを、「通常は3.5で（なければ4.0で）」という指定もできます。4.5でビルドし直す必要はありません。もちろん4.5でビルドし直すのは自由です。

Answer 4

佐祐理さん、返信ありがとうございます。

　

現在リリース済みのアプリに対し、ビルドせずに実行に使うバージョンを切り替えることも可能なのでしょうか？

よろしければ、情報の書かれたサイトをご存じであれば、教えていただけないでしょうか？

　

ちなみに、VS2005 で作成した .NET 2.0 アプリを Windows 8 に、出来るだけユーザーに負担がない形でインストールしたいと思っています。

以上、よろしくお願いします。

Answer 5

アプリケーション構成ファイルの<supportedRuntime> 要素に記述することで実現できます。

「リリース済み」という言葉が引っかかります。当該アプリケーションがアプリケーション構成ファイルを既に導入していれば、リンク先を参考に記述を追加するだけです。導入されていないようでしたら新たに「実行ファイル名.exe.config」で追加する必要があります。

ユーザーに対して「アプリケーション構成ファイルを書いてね」と言えるかどうかはわかりません。普通は製品に組み込むためリリース済みでは手遅れかなと。そういう意味ではなんらか後付な対処であり、ビルドし直しと何ら変わりがないです。

Answer 6

現在リリース済みのアプリに対し、ビルドせずに実行に使うバージョンを切り替えることも可能なのでしょうか？

この「リリース済み」とはどんな状態でしょうか？

すでにリリース済みと言われると、インストーラーでまとまっていて、ユーザーはインストールして使うだけという状態を思い浮かべます。その状況から、.NET のランタイムのバージョンを切り換えようとする場合、Program Files などのインストール先で EXE名.config なファイルに要素を書き足さなければなりません。「ユーザーに負担がない形」とはいえません。

また、.NET のランタイムのバージョンを切り換えた場合、開発者（メーカー）がきちんと動作を検証し、ユーザーに対して保障する必要があるかもしれません。互換性は高いと思われますが、保障する（必要な検証を実施する）のは開発者（メーカー）の責任です。（参考リンク）
インストーラーも作り直さないといけないでしょう。
そういう意味で、「ビルドし直しと（開発者側の負担は）何ら変わりがない」と、私も思います。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 7

マイクロソフトの人が方向性だけでも回答してくれないかなとの期待で質問してみました。

　ここはマイクロソフトが回答をするために用意している場ではないので無理です。

　もちろん、フィードバックによって「インストール イメージに含めろ」と言うことはできます。この時、実際にどれくらいの時間がかかるのか計り、「エンド ユーザーn人（あるいは、エンド ユーザーのn％）に対してx分の損失を与える」という言い方をすると、効果的です。また、当然ですが、Windows 8 には .NET Framework 3.5 を添付しないというアナウンスがされているのですから、開発者が .NET Framework 3.5 を使い続ける理由も説明しましょう。

---

Jitta＠わんくま同盟

Answer 8

左祐理さん、 Azulean さん、 Jitta さん、

情報ありがとうございます。

　

「リリース済み」とは、現在製品として市場に出ているという意味です。

対応としては、config ファイルを追加するか、リビルドするか、どちらかの対応が良さそうですね。

どちらにしても、インストーラの変更は必須であるということになります。

そして、もちろんテストも行います。

　

本来なら、ランタイムを標準で入れていて欲しいところなのですが．．．

無いものと考えて対応していこうとおもいます。

　

ありがとうございました。

Answer 9

Jitta さん、

たまにマイクロソフトの人から回答がくるので、だめもとで聞いてみました。

　

フィードバックするなら、定量的に必要性を説明すべきと言うことですね。

了解しました。

Answer 10

たまにマイクロソフトの人から回答がくるので、だめもとで聞いてみました。

　ああ、そっち狙いでしたか。今、日本に Windows 開発チームがあるのかな？私が知っている Windows 開発チームの方々は皆、他の開発チームに移ってしまいました。その方々に直接連絡をすると、「聞いてみる」とは言ってくださるのですが、どこ（本国なのか、日本国内なのかの意味でのどこ）に回してくださっているのかは、わかりません。それっきり、なしのつぶてなので。。。

---

Jitta＠わんくま同盟

Answer 11

当方の環境はインターネットへの出口にプロキシが用意されており、Proxy 設定を行うことでそこまで時間をかけずに .NET Framework を Windows update からインストールできましたので報告させていただきます。

　

当然ですが、Internet の設定では既にプロキシ設定を行っていましたが、Win 8 CP ではそれだけでは足りないようで、コマンドプロンプトから以下のコマンドでプロキシを設定することで対応できるようになりました。

　　netsh winhttp set proxy [プロキシサーバー]

　

気にしていたインストール時間ですが、このくらいのインストール時間であれば許容範囲かなと思います。

　

また、このコマンドを実行することで、それまでできなかった Live ID でのログインもできるようになりました。

Win 8 の最終版ではどうか分かりませんが、プロキシ内の Win 8 では、インターネットの設定でプロキシを設定するだけではいくつかのサービスが正しく動作しないようです。

Answer 12

"netsh winhttp" で検索すると出てきますが、Windows 8 からではなく、Windows Vista 時代から存在していたものです。
たとえば、CRL、無効になった証明書の検証プロセスなどは、WinHttp を使っているのでプロキシ環境で適切に WinHttp が設定されていないと、特定のアプリケーションの起動が遅くなるといった問題がありました。

// お手軽には netsh winhttp import proxy source=ie なのかもしれませんが。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 13

Azulean さん、

これは既存の問題だったのですね。

知っている人には常識なのかもしれませんが、インターネットオプションから設定した内容がすべてに反映されて欲しいですね。

Answer 14

知っている人には常識なのかもしれませんが、インターネットオプションから設定した内容がすべてに反映されて欲しいですね。

インターネットオプションのプロキシ設定はユーザーごとだったと思います。
一般ユーザー権限で Windows Update や CRL などのサービスが実行するような HTTP 通信のプロキシを安易に変えられないようにする（プロキシを勝手に変えられるとセキュリティ的にも弱くなる）ためにも、あえて分離しているのだと思っています。

管理者ユーザー向けにわかりやすい UI を提供するべきだということに関しては、もっともだと思いますが…。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 15

インターネットオプションのプロキシ設定はユーザーごとだったと思います。

一般ユーザー権限で Windows Update や CRL などのサービスが実行するような HTTP 通信のプロキシを安易に変えられないようにする（プロキシを勝手に変えられるとセキュリティ的にも弱くなる）ためにも、あえて分離しているのだと思っています。

管理者ユーザー向けにわかりやすい UI を提供するべきだということに関しては、もっともだと思いますが…。

あ、そういうことですね。
ログオンユーザーはインターネットオプションで設定されているけど、管理者権限が必要な処理時は管理者権限のプロキシ設定を変更する必要があるということですね。

しかし、Windows Update や Win 8 の Microsoft ID でのログオンは一般ユーザーも行う作業なので、やっぱりわかりやすくして欲しいですね。

Answer 16

それは違います。Windows Updateは管理者が行うことに変わりはないでしょう。Windows 7にも「全てのユーザーにこのコンピューターへの更新プログラムのインストールを許可する」というオプションはありますが、インストールできるよう設定するのは管理者の仕事です。

また一般ユーザー云々を考慮するなら、個々のブラウザーに対してプロクシーの設定を個別に操作させる時点でわかりやすくないと思います。Web Proxy Auto-Discovery Protocolを使用して、ネットワークからプロクシー情報を取得し、コンピューター上では設定不要にした方がいいかと。

Answer 17

佐祐理さん、

情シス管理と個人管理で別々に考えた方がいいですね。

後者では一般ユーザー（ログオンユーザー）＝管理者なので。

確かに、プロキシを用意している時点で、企業であり情シスがある可能性が高いので、Windows Update などは管理者の仕事の可能性が高いです。

私の場合、情シスの管理下から離れた Win 8 PCを利用していたため、紛らわしい表現をしてしまいました。

まぁ、こういうケースもあるということと、私の知識不足が原因ですね。

（これまでは大抵 Internet Option のプロキシを設定すれば、Windows update もアクティベートなども問題なく動いていたので。）

勉強になりました。

ありがとうございました。