Software

QRコードのセル数を少なくするために（つまり、印刷されたときの1つのセルを大きくするために）Versionはできるだけ小さく、また、くっきりと印刷するためにSizeは大きめに設定すると良いようです。 ちなみに、合成したQRコードを家庭用プリンタで縦横4cm弱で印刷しましたが、Versionを10に設定した場合はときどきしか認識に成功しませんでした。そこで、Versionを4に設定したところ、認識率が大分改善しました。

管理者としてではなく普通に実行したシェルでwingetコマンドが認識されず実行できない問題が解決しましたので、その現象と原因、そして修正方法をこちらにまとめました。

なお、この問題の解決にはkou1okadaさんの情報が大きな助けとなりました。この場を借りて御礼申し上げます。

現象

管理者として実行したコマンドプロンプトやPowerShellでは問題なくwingetを利用できる。 しかし、管理者として実行しなかったコマンドプロンプトやPowerShellではwingetが「認識されていません」などとなって実行できない。

原因

環境変数のPathに対応するレジストリの値の種類がREG_SZになっている。

原因がレジストリにあるか確認する方法

PowerShellで以下のコマンドを実行したときの結果を見て、

REG Query HKCU\Environment /V Path

以下のように、Pathの種類がREG_SZとなっている場合は、問題の原因はこのレジストリの設定です。

HKEY_CURRENT_USER\Environment 

    Path    REG_SZ    C:\foobar;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps 

修正方法

このWebページに載っている以下のコマンドを実行します。

if ((gi HKCU:\Environment).GetValueKind("Path") -eq "String") {sp Registry::HKEY_CURRENT_USER\Environment Path (gi HKCU:\Environment).GetValue("Path",$null,"DoNotExpandEnvironmentNames") -Type ExpandString; [Environment]::SetEnvironmentVariable("WM_SETTINGCHANGE","","User")} 

修正できたかの確認

PowerShellで、以下のように、先ほどと同じコマンドを実行し、Pathの種類がREG_EXPAND_SZに変わったことを確認します。

PS C:\Users\wakai> REG Query HKCU\Environment /V Path 

HKEY_CURRENT_USER\Environment 

    Path    REG_EXPAND_SZ    C:\foobar;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps 

さらに、管理者として実行していないPowerShellかコマンドプロンプトで以下のコマンドを実行し、バージョンが無事表示されるようになっていれば、修正が出来ています。

winget -v

なお、レジストリを変更した後は、念のためコンピュータの再起動をしておいた方が良いかもしません。

謝辞

この問題の解決では、前述のkou1okadaさんのWebページの情報が大きな助けとなりました。この場を借りて御礼申し上げます。

アプリケーションの更新が失敗したときやエラーが発生したときの表示がwingetは不親切な気がしています。
wingetでエラーなどが発生したときに、wingetが返したメッセージを読んでも、次にいったいどうすればいいのかよく分からないことが多いように感じています。

それに比べると、WingetUIはwingetよりも関連する情報を多めに出してくれるので、親切な気がします。
wingetでもやりようはあるのでしょうが、ライトユーザーが日常的なメンテナンスをする分には、WingetUIの方が適しているのかもしれません。

公式のGitHubのREADMEにも書かれていますが、
インストールはPowerShellかコマンドプロンプトで以下のコマンドを実行することで簡単にできます。

winget install --exact --id MartiCliment.UniGetUI --source winget

インストーラーをダウンロードして実行することでもインストールできるようですが、せっかくwingetがパッケージ管理をしてくれるのですから、wingetコマンドからのインストールの方が良さそうな気がします。

なお、2024年10月現在、前述のREADMEでは、Microsoft Storeからのインストールが推奨(recommended)となっています。winget以外のパッケージ・マネジャーも多数サポートするようになり、利用目的がwinget以外のパッケージ・マネジャーである方への配慮として、推奨をMicrosoft Storeにしたのかもしれません。推測ですが。

ちなみに、初めてwinget upgrade --allを実行したときに、エラーが出たり、更新に失敗したりしたアプリケーションがそれなりにありました。
ただ、それらのアプリケーションを1つずつ確認してみると、サポート切れ等で不要となったアプリが大半でしたので、アンインストールすることで大半の問題は解決しました。
また、wingetでインストールしたアプリでない場合は、エラーに関連するものなど一通りをアンインストールした後で、wingetで改めてインストールするというのが有効な場合がありました。

以下のコマンドで、更新が可能なアプリケーションの一覧が表示されます。

winget upgrade

表示された全てのアプリケーションを更新するには、以下のコマンドを実行します。

winget upgrade --all

IDを指定して、特定のアプリケーションを更新するには、以下のコマンドを実行します。

winget upgrade --id Microsoft.PowerToys

参考

Microsoft Learn: upgrade コマンド (winget)

管理者として実行したシェルでないとwingetが実行できないという症状について、マイクロソフト コミュニティで質問してみました。

https://answers.microsoft.com/ja-jp/windows/forum/windows_10-performance/%e7%ae%a1%e7%90%86%e8%80%85%e3%81%a8%e3%81%97/63903580-72f9-4090-95c0-fc2870029fdb

ちなみにWindows 10で、管理者として実行したシェルでないとwingetが実行できないという症状を直して、管理者としてではなく普通に実行したシェルでもwingetを実行できるようにするにはどうすればいいかをご存じの方は、教えていただけると嬉しいです。

Microsoft Storeからインストールされたwingetが「アプリ実行エイリアス」によってシェルから実行できるようになっていることまでは分かったのですが、管理者権限の有無によってシェルから実行できたりできなかったりするという違いが発生する理由は分かりませんでした。

Windows 10とWindows 11では、わざわざインストール作業をしなくてもwingetがすでに入っていることが多いです。

自分のWindows環境にwingetが入っているか確認する際は、管理者としてPowerShellかコマンドプロンプトを立ち上げて、以下のコマンドでバージョンが表示されるかどうかで確認することがおすすめです。

winget -v

なぜ管理者でのシェルの実行をおすすめするかというと、Windows 10 Pro 22H2で、管理者としてではなく普通に実行したシェルではwingetコマンドが認識されず実行できないことがあったからです。（この問題の修正方法はこちら）

ちなみに、wingetがインストールされているかを確認する他の方法としては、以下の2つもあります。

• ウインドウズキーを押してスタートメニューを開いた直後に「winget」とキーボードから打ち込む。コマンドの検索結果としてwingetがあれば、wingetはインストール済みのはず。
• Microsoft Storeで「アプリ インストーラー」を検索し、「インストール済み」となっていれば、wingetはインストール済みのはず。