しばたテックブログ

気分で書いている技術ブログです。

PowerShellの起動時に表示されるプロファイルに関するメッセージについて

小ネタです。

Windows 10などでPowerShellの起動時に以下の様なメッセージが表示され、プロファイルの読み込みにかかった時間が表示される場合があります。

パーソナル プロファイルとシステム プロファイルの読み込みにかかった時間は xxx ミリ秒です。
(英文だと Loading personal and system profiles took xxx ms.)

表示例)

f:id:stknohg:20170313184238p:plain

本エントリではこのメッセージがどういった場合に表示されるのかについて説明します。

このメッセージの実体について

残念ながらこのメッセージについてのドキュメントはない様です。

仕方ないのでソースファイルを検索して情報を探します。

細かい手順は省いて結果だけ説明すると、このメッセージはConsoleHostクラス(ConsoleHost.cs)のDoRunspaceInitializationメソッドで呼ばれて表示されています。

ソース中で該当する箇所はこちらとなり、その内容を以下に転記します。

// ConsoleHost.DoRunspaceInitialization() メソッドより転記

// Run the profiles.
// Profiles are run in the following order:
// 1. host independent profile meant for all users
// 2. host specific profile meant for all users
// 3. host independent profile of the current user
// 4. host specific profile  of the current user

var sw = new Stopwatch();
sw.Start();
RunProfile(allUsersProfile, exec);
RunProfile(allUsersHostSpecificProfile, exec);
RunProfile(currentUserProfile, exec);
RunProfile(currentUserHostSpecificProfile, exec);
sw.Stop();

var profileLoadTimeInMs = sw.ElapsedMilliseconds;
if (profileLoadTimeInMs > 500 && s_cpp.ShowBanner)
{
    Console.Error.WriteLine(ConsoleHostStrings.SlowProfileLoadingMessage, profileLoadTimeInMs);
}

見ての通り、PowerShellの起動時に呼ばれる4つのプロファイル(AllUsersAllHostsAllUsersCurrentHostCurrentUserAllHostsCurrentUserCurrentHost)が実行されるのにかかる時間を計測し、その時間が500msを超える場合にメッセージが表示されることがわかります。

このメッセージを表示させない様にするにはPowerShellを起動する際に-NoLogoを指定するしかない様です。
ユーザーがこの設定に介入する余地はありませんが、このメッセージが出るのはプロファイルの呼び出しに時間がかかっているのが根本的な問題ですので、プロファイルで呼ばれる処理を見直すことで対処するのが筋だと思います。

また、このメッセージはPowerShell 5.1から導入されており、以前のバージョンで表示されることはありません。

まとめ

とりあえずこんな感じです。

このメッセージが導入された経緯は正確にはわかりませんが、おそらく、起動が遅いと散々言われているPowerShellの起動時間を改善していくなかで、PowerShellそのものに起因する部分とユーザーの設定(プロファイルの設定)に起因する部分を切り分けたいという意図があるのではないかと思われます。

もしこのメッセージが出てPowerShellの起動が遅いと感じる様でしたら各プロファイルで呼ばれている処理を見直すことで改善できますのでぜひ試してみてください。

VisualStudioUninstallerを使ってVisual Studio 2015をアンインストールしてみた

つい先日Visual Studio 2017がリリースされました。

本エントリは、Visual Studio 2017をインストールするために手元の開発機にインストールされていたVisual Studio 2015をアンインストールした際の作業記録になります。

VisualStudioUninstaller

Visual Studioを一発で完全?アンインストールしてくれるすごいやつ。
Visual Studio 2013以降に対応しているそうです。

github.com

作業記録

0.はじめの状態

はじめの状態はこんな感じ。
Visual Studio 2015本体に加え、.NET FrameworkのMulti-Targeting PackやらSQL Sever Express LocalDBやらの関連するツール類が大量にいる状態です。

f:id:stknohg:20170312040519p:plain

1. VisualStudioUninstallerのダウンロードと展開

VisualStudioUninstallerの使い方は、RelesesあるZipをダウンロード+展開して、アンインストーラーであるSetup.ForcedUninstall.exeを管理者権限で実行するだけです。

今回は全て手作業でやりましたが、PowerShellで以下の様にしても良いかと思います。

$Uri="https://github.com/Microsoft/VisualStudioUninstaller/releases/download/v1.4/TotalUninstaller.zip"
Invoke-WebRequest -Uri $Uri -OutFile .\TotalUninstaller.zip
Expand-Archive -Path .\TotalUninstaller.zip

展開した結果はこんな感じ。

f:id:stknohg:20170312041347p:plain

2. Setup.ForcedUninstall.exeの実行

Setup.ForcedUninstall.exeを実行すると本当にアンインストールするか確認されるので「y」を入力するとアンインストールが開始されます。

f:id:stknohg:20170312041552p:plain

アンインストールにかかる時間は環境によって異なるでしょうが、私の環境では10分くらいかかりました。

f:id:stknohg:20170312041640p:plain

Visual Studio本体のアンインストール後に周辺ツールのアンインストール、レジストキーの削除が行われているのがわかります。

アンインストール結果

アンインストールした結果はこんな感じになりました。

f:id:stknohg:20170312041751p:plain

VCランタイムはこのツールでは削除できない様です(多分他で使われているか否かを判別する方法が無いのでしょう)。

他にも若干アンインストールしてくれて構わないツールが残ってしまいましたが、これくらいであれば手作業で構わなかったのでそのまま手作業でアンインストールしました。

Visual Studio以外で使われている可能性のあるツールについて削除しても構わないかの判定が厳しめなのかな?という印象です。

AppImage版のPowerShellが提供されました

PowerShell on Linuxの話です。

先日リリースされた PowerShell 6.0.0.Alpha17 からAppImageの実行バイナリが提供されました。

AppImageについて

公式サイトは以下。

appimage.org

かつてklikPortableLinuxAppsと呼ばれていたプロジェクトで、ディストリビューションを問わずに実行可能な単一のバイナリファイル(*.AppImage)でアプリケーションを提供するための仕組みだそうです。

このツールで作られた*.AppImageなバイナリファイルはダウンロードしてファイルに実行権限を付けるだけでアプリケーションが利用可能になります。

正直まだよくわかっていないのですが、仕組みを調べてみた結果、AppImageではアプリケーションの実行バイナリと依存モジュール一式を一つの*.AppImageなファイルにまとめ、この*.AppImageなファイルの実行時にFUSEを使って仮想ファイルシステムに依存パッケージごと展開して(サンドボックス的な環境を作ってるっぽい?)実行バイナリを起動している様です。

このためディストリビューションを選ばないと言うものの、実行環境にFUSEがインストールされている必要があります。

インストール方法

公式な手順はこちら

今回は例としてCentOS 7.3での方法を紹介します。
他のディストリビューションでも基本的な流れは変わらないはずです。

1. FUSEのインストール

先ほど述べた通りAppImageのバイナリを実行するためにはFUSEがインストールされている必要があります。

今回の検証環境にFUSEはインストールされていなかったのでYum(EPELリポジトリ)からインストールします。

FUSEが利用可能な環境ではこの手順は不要です。

# bash
# FUSEのインストール
sudo yum install -y epel-release
sudo yum install -y --enablerepo=epel fuse-sshfs

2. AppImageのインストールと実行

FUSEをインストールした後はAppImageのバイナリ(PowerShell-x86_64.AppImage)をダウンロードして実行権限をつけるだけでOKです。

# bash
# バイナリのダウンロードと実行権限の付与
curl -OL https://github.com/PowerShell/PowerShell/releases/download/v6.0.0-alpha.17/PowerShell-x86_64.AppImage
chmod a+x ./PowerShell-x86_64.AppImage

# 実行
./PowerShell-x86_64.AppImage

実行した結果は以下の様になり、PowerShellの起動前に/tmp/に対して仮想ファイルシステムの展開がなされているのがわかります。

f:id:stknohg:20170311145017p:plain

あとは普通にPowerShellを利用することができます。

注意点

あまり影響はないと思いますが1点だけ気を付けておいた方がよさそうな点があります。

AppImageの仕組み上、実際の実行ファイル(powershell)は/tmp/.mount_[ランダム文字列]/usr/binに展開されます。
このためPowerShellを実行するたびに$PSHOMEのディレクトリが変わります。

f:id:stknohg:20170311145550p:plain

試してはいませんが都度$PSHOMEが変わってしまう以上PSRemotingのサーバー側になることはできないでしょう。
PowerShellのクライアント側の機能しか使えないと思われます。

また、/tmp/.mount_[ランダム文字列]配下はReadOnlyになります。
このため$PSHOMEにファイルを置くことができずAllUsers*なプロファイルを作ることができません。

最後に

若干制限はありますが、環境によっては一番気軽にPowerShellを実行できる方法かもしれません。

個人的にはテスト用の一時的な環境を作るのに向ていると感じています。