プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

VisulStudio 2022 をインストールして、チュートリアル試そうとしたらエラーになった

超久しぶりに Visual Studio を触ることになりました。まずはリハビリがてら、インストールして、 C# 触って・・・と一通りのことをやってみようと思います。

で、最初に Visual Studio 2022 をインストールしてプロジェクトを作成したら、早速エラーが出ました。せっかくなのでエラーの内容と解決した経緯をメモっておきます。

なお、環境としてはこんな感じです。

  • Windows 11 Pro (64ビット), 24H2
  • Visual Studio 2022 Community (64ビット), 17.14.7

エラーの内容

Visual Studio 2022 Commynity インストール後、こちらのチュートリアルからコンソールアプリを試すため、プロジェクトを作ってみます。すると、

のような画像が表示されます。

ん?インストールには問題なかったし、インストール直後だからそんな変な構成変更とかもしれないはずなんだけどな?と思いつつ、調べてみると、ダイアログのメッセージの通り .Net SDK がインストールされていない、ということのようです。

確認

まずは、 Visual Studio Installer を起動してインストールしたものを確認してみます。

すると、上記のようにインストールしたコンポーネントにちゃんと含まれています。仕方ないので、ネットを調べてみると、 dotnet --info というコマンドで調べるのがよさそうです。で、やってみると、

あー、『.NET SDKs installed』のところが『No SDKs found』となって、正しく認識されていませんね。どうも、環境変数 PATH が通ってない時も同じ現象になるようなので、それも確認してみると、一応通ってますね。

原因

ここで、ちょっとはまりそうになったのですが、先人がちゃんと解決策書いてくれてました。

.net sdk が見つかりません。

どうも、 32bit 版の SDK と 64bit 版の SDK の両方があるんだけど、そのパスの順序が入れ替わってて、 64bit 版の SDK が見つけられないのが、今回のエラーの原因のようです。

Microsoft のサイトにも載ってました。

Windows に .NET をインストールする - .NET | Microsoft Learn

修正

ということで、パスを修正します。 Windows の設定から、システム環境変数を開いて、PATHをクリックして、編集を行います。

C:\Program Files\dotnet

C:\Program Files(x86)\dotnet

のように上に来るように入れ替えます。こんなかんじになれば OK です。

確認

これで、再度 Visual Studio を起動して、プロジェクトを作成すると、無事にエラーがなくなりました。わかってしまえばこれだけのことなんですが、はまる人多そうだな、これ。

ちなみに、修正後にもう一度 dotnet --info を実行すると

こんな感じになりました。修正前とよく比べてみると、『Host』の『Architecture』のところに、『win-x86』とか、『x64』とか載っていたり、『 Other architecture found 』のところに、 64bit 版(32bit 版)の表記があったり、今回のトラブルの解決のヒントとなる情報がいくつも載ってました。

ま、なんにせよインストーラ直してもらえるとありがたいです > Microsoft さん

QNAP Container Station で動かしている docker 版 Pleasanter のアップデート(1.4.13 -> 1.4.17)

QNAP NAS で利用できる docker (Container Station) 上で、 docker 版の Pleasanter をあれこれ試しています。

いま動いている Pleasanter のコンテナは書籍『入門プリザンター』

が出たときに作ったものがベースのため、バージョン 1.4.13 になっています。

少し前に出たバージョン 1.4.15 で GUI 操作で画面項目を作ることができるなど、なかなか面白そうな機能が追加されていたりします。あと、うれしいことに Pleasanter も結構バージョンアップしているので、若干今の環境が古くなりつつあります。

ということから、思い切って docker 版 Pleasanter のバージョンアップを行ってみたので、その時の作業をメモっておきます。

  • QNAP NAS TS-262, QTS 5.2.4.3079
  • Container Station 3.0.9.1038
  • バージョンアップ前 Pleasanter 1.4.13.0
  • バージョンアップ後 Pleasanter 1.4.17.0

公式の手順の確認

Pleasanter のページには、 docker 版の Pleasanter のバージョンアップ手順も載っているので確認しておきます。

Dockerイメージのプリザンターをバージョンアップする | Pleasanter

なるほど。それほど難しくはなさそうです。

ただ、手元の環境は QNAP の Container Station の docker を利用していることもあり、公式の手順とはちょっと異なる構成になってしまってます。 なので、上記の公式の手順を参考にして、自分の環境でバージョンアップを行ってみます。

Contaienr Station でのバージョンアップ手順

下記の手順でバージョンアップしました。

  1. プリザンターの停止
  2. パラメータファイルの更新
  3. docker-compose.yml の更新
  4. pleasanter アプリケーションの再作成
  5. ファイルのコピー
  6. CodeDefiner イメージの更新と実行
  7. Pleasanter の実行

以下では、実際に試して時の詳細を書いておきます。

プリザンターの停止

これは Container Station から操作します。

pleasanter のアプリケーションを選択して、歯車のアイコンから『停止』を選択すれば完了です。

パラメータファイルの更新

公式の手順『3.パラメータファイルの更新』に書いていることと同等のことを行います。

GitHub のリリースのページから、アップデートしたいバージョンの zip ファイルをダウンロードします。ただ、Docker Hub の Pleasanter を利用する関係で、そちらで公開されているバージョンと同じバージョンを選んでおいた方が無難かと思います。今回の場合だと、 Github ではすでに 1.4.17.1 がリリースされていたのですが、 Docker hub は 1.14.7.0 までだったので、 1.4.17.0 をダウンロードしました。

ファイルを解凍して、

Pleasanter_1.4.17.0\pleasanter\Implem.Pleasanter\App_Data\Parameters

にあるファイルのうち、利用しているパラメータファイルのみをコピーします。

いまの環境なら、

  • BackgroundService.json
  • Mail.json
  • Service.json

の3ファイルです。

次に、コピーした上記3ファイルに、既存ファイルの内容を反映します。

実際には、変更している設定ファイルは git で管理しているので、 git の管理フォルダに先ほどのファイルをコピーして、変更行を見比べながら自分の設定を書き戻すような作業になると思います。

たとえば、 BackgroundService.json というファイルを 1.4.17.0 のフォルダから git 管理化のフォルダにコピーすると

に示すように、 Reminder の行が変更としてマークされています。これは、リマインダー機能を有効にしているので、設定値が true だったのがダウンロードしたファイルの値 false になっているためです。

自分用の設定を反映すると

こんな感じになりました。なお、緑でマークされている行は、バージョンアップに伴い追加された行のようなのでこのままとしておきます。また、ファイルの最後の削除マークは空行の変更なので、これもこのままとします。

この作業を変更している設定ファイルすべてに対して行っておきます。

docker-compose.yml の更新

docker-compose.yml ファイルの pleasanter のバージョンを新しいものに変更しておきます。

(略)
  pleasanter:
    container_name: pleasanter
    image: implem/pleasanter:1.4.17.0
(略)

codedefiner 用の docker-compose.codedefiner.yml のほうは特に変更は加えません。

ここまでで準備完了ですね。

pleasanter アプリケーションの再作成

さて、 ContainerStation の docker を使っている場合、 docker-compose.yml を更新するためには、一度再作成を行う必要があります(こちらの https-portal を別アプリケーションに分離したときと同じですね)。

ちなみに、 ContainerStation からの再作成では、必要な環境変数やファイルがないので、コンテナの起動に失敗します。

こんな感じで、 postgres コンテナはありますが、 pleasanter のコンテナはありません。

ファイルのコピー

pleasanter のアプリケーションを再作成するとアプリケーションフォルダごと作り直すため、既存のファイルは一度消えてしまいます。ということで、次は pleasanter のアプリケーションフォルダに必要なファイルをコピーしてやります。

  • .env
  • BackgroundService.json
  • Mail.json
  • Service.json
  • docker-compose.codedefiner.yml

今回の場合は上記のものになります。

CodeDefiner イメージの更新と実行

ここで、今まで通り CodeDefiner を実行すればいいと思いきや、実はこのままだと CodeDefiner が古いバージョンで実行されてしまいます。というのも、 docker-compose.codedefiner.yml を見るとわかるのですが、 codedefiner のタグにはバージョンが含まれていません。

  codedefiner:
    container_name: codedefiner
    image: implem/pleasanter:codedefiner

試しにこのまま CodeDefienr を実行すると

[ユーザー名@NAS名 pleasanter-test]$ docker compose -f docker-compose.yml -f docker-compose.codedefiner.yml run --rm codedefiner
[+] Creating 1/1
 ✔ Container postgres  Recreated
[+] Running 1/1
 ✔ Container postgres  Started
<INFO> Starter.Main: Implem.CodeDefiner 1.4.13.0
<INFO> RdsConfigurator.UpdateDatabase: Implem.Pleasanter
(略)

のように、 1.4.13 時点のものが実行されます。

でも、 docker hub を見ると、 codedefiner も更新されているのがわかります。

なので、一度 CodeDefiner のイメージを手作業で更新して置く必要があります。

[ユーザー名@NAS名 pleasanter-test]$ docker pull implem/pleasanter:codedefiner

更新前は、

[ユーザー名@NAS名 pleasanter-test]$ docker image ls
REPOSITORY                  TAG                         IMAGE ID       CREATED         SIZE
implem/pleasanter           1.4.17.0                    ecbfb1d0232a   11 days ago     605MB
(略)
implem/pleasanter           codedefiner                 7151e0efaf45   4 months ago    420MB
implem/pleasanter           1.4.13.0                    e2d1ea89cd77   4 months ago    465MB
(略)

とあったものが、更新後は

[ユーザー名@NAS名 pleasanter-test]$ docker image ls
REPOSITORY                  TAG                         IMAGE ID       CREATED         SIZE
implem/pleasanter           codedefiner                 d6311b9e7457   11 days ago     561MB
implem/pleasanter           1.4.17.0                    ecbfb1d0232a   11 days ago     605MB
(略)

のように更新されていることがわかります(CREATED の日付が違いますよね)。

ここまでできたら、あとはいつもと同じです。

[ユーザー名@NAS名 pleasanter-test]$ docker compose -f docker-compose.yml -f docker-compose.codedefiner.yml run --rm codedefiner
[+] Creating 1/0
 ✔ Container postgres  Running
<INFO> Starter.Main: Implem.CodeDefiner 1.4.17.0
<INFO> RdsConfigurator.UpdateDatabase: Implem.Pleasanter
(略)

CodeDefiner も 1.4.17.0 版で動作していることがわかります。

Pleasanter の実行

ここまでできたら、最後は、

[ユーザー名@NAS名 pleasanter-test]$ docker compose up -d pleasanter
[+] Running 2/2
 ✔ Container postgres    Running
 ✔ Container pleasanter  Started
[ユーザー名@NAS名 pleasanter-test]$ 

として、 pleasanter のコンテナを起動します。

動作確認

無事に起動したのを確認したら、 Pleasanter にログインして、ヘルプのバージョン情報を表示させると、

となっています。問題なさそうですね。

まとめ

一度手順がわかってしまうと、バージョンアップもさほど難しくないことがよくわかります。さて、これで最新版を試してみようと思います。

仕事場ルータ (NVR510) のファームウェアアップデート

仕事場ルータ(Yamaha NVR510)のファームウェアをアップデートしたらので、その際の経緯をメモっておきます。

Rev. 15.01.18 -> Rev. 15.01.26

アップデート

ルータのファームウェアのアップデートの手順はこちらのマニュアル(PDF)の『16.8 ファームウェアを更新する』節にあるので、そちらを読んでもらえればいいのですが、一応簡単に書いておきます。

NVR510 の場合、ファームウェアのアップデート方法は3つあります。

  • USB メモリから更新
  • PC からアップロードして更新
  • ヤマハのサイト経由で更新

今回は PC からアップロードして更新を選びました。

まず、作業前にヤマハのサイトから、NVR510 の最新のファームウェア(作業時点で Rev.15.01.26)を PC にダウンロードしておきます。

ルータにログインして、『管理』->『保守』->『ファームウェアの更新』を開きます。

ここの『PC からファームウェアを更新』にある『進む』ボタンを押します。

次に、更新対象のファームウェアのファイルを指定する画面が表示されるので、先にダウンロードしていたファイルを指定して、『確認』ボタンを押します。

実行確認を求められるので、問題がなければ『実行』ボタンを押します。

更新中はこんな感じのダイアログがでていて、更新が完了すると

と表示されます。ダイアログの指示に従って、LEDの点滅終了後(ブザーも鳴ったはず)、『トップへ戻る』ボタンを押すと、ルータのログイン画面になります。

あとは、ログインして動作に問題ないことを確認しておきます。トラブルさえなければあっけないぐらい簡単ですね。

(参考)アップデートに至った経緯

個人的にはこっちのほうが重要なんですが、参考までに上記のファームウェアアップデートに至った経緯を書いておきます。

1 日目:トラブル発生

2025/6/17 の夕方、出先から帰ってきて仕事しようと仕事場に戻ってきて、しばらく作業していたら『ピー』と何かのブザー音がしました。

どれかの機器からの警告音だと思うので、嫌な予感がしつつ、さてどれの音だろうか?と思って、あちこち見渡していました。そのうちしばらくすると、再度同じ音が聞こえてきます。連続してなっているということは、かなりやばそうです。

ふと、確認してみるとブラウザでネットに接続できません。外部への光回線か?と疑いながら、仕事場ルータ(Yamaha NVR510)にログインしてみると、

Rebooted by Malloc Fault (8)

なんて表示があります。

まさかルータの警告音なのか?と思いつつ、ログインしたダッシュボードの画面をしばらく眺めていたら、メモリ使用量がどんどん増えていきます。で、次にCPUの使用率がどんどん上がっていきます。なんだこれは?

しばらくすると、先ほどのブザー音がして、再ログインを求められます。リブートしたときのブザー音ですね。間違いなく、ルータが異常な挙動してます。おまけにこれが何度も繰り返して続きます。

リブート後、しばらくはネット接続も正常になり使えるのですが、そのうちメモリ使用量がどんどん増えて、またリブートです。ルータの電源を切ったりもしてみたのですが、状況は変わりません。

致し方ないのでネットがつながっている間にヤマハのサポートさんに問い合わせだけ投げて、この日はルータの電源を切って帰りました。

2 日目:ファームウェアアップデート

ネットがつながらないので、仕事にはならないのですが、一応ローカルで進めることのできる作業もあるので、仕事場に来ました。PC を立ち上げて、もう一度ルータの電源を入れると、やっぱり前日と同じ状況になります。

どうしようもないですね。

まあ、リブート間のあいだ少しだけはネットにつなげられるので、前日の夜に来たメールなどへの対応だけしておいて、あとはネットなしでローカルで仕事しようとしていたら、いつのまにやらリブートしなくなっています。

うーん、一番困るパターンだな。これは。

そうこうしているうちに、 昨晩投げた問い合わせの返事がヤマハのサポートさんからきて、ログなどいろいろと情報を送ってやり取りしたところ、ファームウェアのアップデートをしてほしい、ということになり、今回の作業に至ったという次第です。

なお、ファームウェアを更新する理由としては、いま使っている Rev. 15.01.18 以降で複数のバグに関する修正が入っているので、まずはこれを更新してほしいということでした。

まとめ

ファームウェアのアップデート自体は非常に簡単でした。

が、原因となったルータの挙動そのものは、とりあえず安定しているようですが、しばらくは様子見ですね。もし、何か進展があれば、続報書きたいと思います。