しばたテックブログ

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

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を実行できる方法かもしれません。

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

PowerShell on Linuxに普通にPSRemotingしてみる - その3

その1その2の続き的な。

以前のエントリで書いた、

github.com

のIssueがクローズされ、OMIおよびPowerShell on Linux OMI Providerpackages.microsoft.comリポジトリからインストール可能になったので試してみました。

インストール

私が使い慣れているCentOS 7.3で検証します。

はじめにpackages.microsoft.comリポジトリの追加とPowerShellのインストールをしておきます。

# CentOS 7, Bash
curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo
sudo yum install -y powershell

こちらは以前のエントリで書いた通りですのでとくに問題はないでしょう。

続けてPowerShell on Linux OMI Providerをインストールします。

パッケージ名はomi-psrp-serverで、依存パッケージにOMI(omi)が登録されているので、こちらをインストールすればOMIも同時にインストールされます。
ですので以下の様にyum install一回でインストールできます。

# CentOS 7, Bash
sudo yum install -y omi-psrp-server

実行結果は以下の様な感じになります。

f:id:stknohg:20170309185812p:plain

インストールが完了したあとはOMIDが動いてればOKです。

OMIDが起動しているかはservice(またはsystemctl status)コマンドで確認してください。

# OMIDが動作しているのを確認
service omid status
# または
# systemctl status omid.service

f:id:stknohg:20170309190015p:plain

ちなみに、現時点の各パッケージのバージョンは、

  • PowerShell - Ver.6.0.0.alpha16
  • PowerShell on Linux OMI Provider - Ver.1.1.0-alpha18 (1.0.0.18)
  • OMI - Ver.1.2.0

となっています。

接続確認

例によってWindows Server 2012 R2(PowerShell 5.1)から接続確認をしてみます。
接続先のIPは192.168.33.209、ユーザーはvagrantおよびrootで試しています。

# Enter-PSSessionで接続
$o = New-PSSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck
Enter-PSSession -ComputerName 192.168.33.209 -Credential vagrant -Authentication basic -UseSSL -SessionOption $o

f:id:stknohg:20170309183812p:plain

普通に使えますが、切断時に謎なエラーが出ました...

f:id:stknohg:20170309183837p:plain

とりあえずこいつは気にしないことにして、CIM情報の取得をします。

# Get-CimInstanceで情報取得
# こっちは要root
$o = New-CimSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck -UseSsl
$s = New-CimSession -ComputerName 192.168.33.209 -Credential root -Authentication Basic -SessionOption $o
Get-CimInstance -CimSession $s -Namespace root/omi -ClassName OMI_Identify

f:id:stknohg:20170309183853p:plain

こちらもこれまで試した結果と同じです。

最後に

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

各パッケージのインストールがかなり楽になったのであとは動作が安定してくれれば使い物になるのかな、と思います。