Connectでの .NET Framework CoreのRCに感化されたわけではないのです。が、.NET Framework 4.6.1 RC1が先月でています。

https://blogs.msdn.com/b/dotnet/archive/2015/10/29/announcing-net-framework-4-6-1-rc.aspx

それも受けて、.NET Frameworkのインストールを自動化しようと思ったのですが、公式、コミュニティともに既存のDSCリソースには.NET Frameworkのインストール可能なものがないので作りました。今回はその紹介です。

• GitHub
• なぜ DSC でインストールを制御したいのか
• 前提
• インストール
  • KB
  • Ensure
  • InstallerPath
  • NoRestart
  • LogPath
• アンインストール
• インストール判定について
  • ログの文字列解析
  • レジストリでの判別
  • ファイルでの判別
  • KB での判定
• .NET 4.6 のアドバイサリについて
  • KBをインストールすればいい環境やその他RyuJIT起因の問題かの切り分け
  • それぞれの無効化方法
• まとめ

GitHub

ver.3.6.0から入っています。

https://github.com/guitarrapc/DSCResources/releases/tag/ver.3.6.0

なぜ DSC でインストールを制御したいのか

.NET Frameworkは、.NETのインフラ基盤なのでこれを数百台にスクリプトや人力展開とか刺身たんぽぽ業は間違ってもやってはいけません。

スクリプト展開は規模が小さいならいいのですが、

• 環境に応じてパラメータを変えて実行する
• 実行結果が将来も適用されていることを保証する

といった、継続的にあるべき状態を維持する仕組みを作るのは面倒なのです。DSC (あるいはChefなど)を使うのはそういう理由もあります。

さくっと捨てて、サクッと起動するので、1回だけ走らせればok。も事実ですが、展開状況が見やすいか、保証されているか。というのも考慮して選べばいいでしょう。

前提

GraniResourceにGrani_DotNetFrameworkを作りました。

ので、 GraniResourceをモジュールパス$env:ProgramFiles\WindowsPowerShell\Modulesに配置しておきましょう。

インストール

ダウンロードからインストールまで行っています。*1

https://gist.github.com/guitarrapc/dc8464775016c163e46e

パラメータを説明します。

KB

.NET Frameworkは、インストールされると実質KB扱いになります。またOS環境によって、同じ.NET FrameworkでもKBが変わるのでご注意ください。

今回作成したリソースは、OS環境を透過的に扱うためKBで判別することにしました。

KB自体はMicrosoftから公開されているので見ればいいでしょう。

• Windows 用の Microsoft に.NET Framework 4.6 (Web インストーラー)

Ensure

インストールされていてほしいなら、Presentを指定します。アンインストールされてほしいならAbsentを指定します。

InstallerPath

このリソースは、.NETFrameworkのオフラインインストーラを前提としています。IntallerPathに.NETFrameworkのオフラインインストーラのフルパスを指定します。

NoRestart

DSCには、コンフィグレーションの適用後に再起動するスイッチがあるので、その制御です。

.NET Framework自体は、/norestartでインストールされています。

LogPath

ログの掃き出し先にどうぞ。

アンインストール

すでにインストールされていたら、アンインストールしてくれます。インストールされていなければ何も設定しません。

https://gist.github.com/guitarrapc/483c3d7bc902ad185597

シンプルですね。KBとEnsureさえ渡せばokです。これも実行後に再起動するかは選択してください。

インストール判定について

.NET Frameworkは、インストール判定にいくつかの手段が考えられます。

1. ログの文字列解析
2. レジストリでの判別
3. ファイルでの判別
4. KBでの判定

今回利用したのは、KBでの判定です。

ログの文字列解析

なしです。おしまい。

レジストリでの判別

これはMSDNでも推奨されています。

https://msdn.microsoft.com/en-us/library/ee942965.aspx#Anchor_5

以下のレジストリパスをみることで確認できます。

https://gist.github.com/guitarrapc/3e2eded77db734ee529d

が、この反映はインストール後の再起動後です。オンタイムでの確認ができない時点でありえないですね。おしまい。

.NET Framework 4.6 installed on all OS versions other than Windows 10の場合は393297になっているか確認となります。

ファイルでの判別

よくあるのが、C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFrameworkや、C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFrameworkですがなしですね。

バージョン判定まではここでは確定できません。おしまい。

KB での判定

.NET FrameworkがKB扱いであることを利用するのが一番素直でしょう。

• Windows 用の Microsoft に.NET Framework 4.6 (Web インストーラー)

再起動なしにオンラインで確認できるので、テストも容易です。今回のリソースは、そのKBを判定することを前提にしています。

幸いにも、インストーラーによるプロセスのExit Code判定も公開されているので容易です。

.NET FrameworkのアンインストールはKBのアンインストール。ここを .NETでやるのはちょっとつらさがあるので、wusa.exeの利用が一番素直かなと。

ここまで考えると、実装と、確実性とコストパフォーマンスを考えるとKBが一番いいと判断しています。

.NET 4.6 のアドバイサリについて

.NET 4.6では末尾最適化に関してRyuJITでバグが報告されています。特定の状況で発生しうる、RyuJITの末尾最適化に関するバグがあったよということです。

https://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx

https://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/

これに関してはKBが発行されているのでいれればokです。

[MS15-092] .NET Framework の脆弱性により、特権が昇格される (2015 年 8 月 11 日)

また、4.6.1 RC1では当該問題は発生しません。

KBをインストールすればいい環境やその他RyuJIT起因の問題かの切り分け

アドバイサリーにあるようにRyuJIT無効化と末尾最適化の無効化で状況を切りわければいいのです。

• If you run into an issue that you cannot diagnose, try disabling RyuJIT. (再現するか調査できない環境なら RyuJIT 無効化)
• If disabling RyuJIT resolves the issue, please re-enable RyuJIT and disable tail call optimization.(RyuJIT 無効化で当該問題がでないなら、RyuJIT有効かして 末尾最適化を無効化)
• If your issue is mitigated with the tail call optimization disabled, then you know that your app is subject to this issue. You can run your app in production in that configuration (tail call optimization disabled), to get the other .NET Framework 4.6 benefits. This work around will disable only the tail call optimization feature and should not negatively impact performance.(もし末尾最適化無効化で問題がでなくなったなら該当していることがわかる。プロダクションでも RyuJIT有効、末尾最適化無効で走らせることができるでしょう。4.6の他のメリットを享受できるし、悪い影響は他には基本的にはないはず。)
• If your issue is not mitigated with the tail call optimization disabled, but is mitigated with RyuJIT disabled, we want to hear from you on .NET Framework Connect. You can also run your app in production in this configuration (RyuJIT disabled).(末尾最適化無効でも問題があって、RyuJIT無効で問題でないなら .NET Framework Connect で報告がほしい。プロダクションでも RyuJIT 無効で実行できる。)
• If your issue is not mitigated by disabling RyuJIT or tail call optimization, then it something else and unrelated to this advisory.(RyuJIT 無効化でも末尾最適化無効でも問題が改善しない場合、このアドバイサリとは別問題の可能性がある。)

それぞれの無効化方法

KBを入れれば関係ありませんが、それ以外でRyuJITなどで問題が起こったときのために使うのもありでしょうか。すでに公開されています。

• RyuJIT 無効化
• 末尾最適化無効化

まとめ

刺身タンポポだめ絶対