最近、Visual Studio 2022でシステム開発を進めている中で、便利な方法を見つけたので、今回はそのメモを残しておきたいと思います。

問題点：設定ファイルの配置

システム開発では、しばしばログインIDやパスワードなど、設定値を管理するためのファイルを作成することがあります。これまでは、user_account.txt という設定ファイルを bin/debug フォルダ内に手動で配置していました。

ただ、手動で配置するのは面倒だし、開発を進めるうちにどんどん設定ファイルが増えて、管理が煩雑になってきます。

解決方法：プロジェクトに設定ファイルを追加

そこで、Visual Studio 2022での新しい方法を試してみました。この方法では、設定ファイルをプロジェクトファイル（.slnや.proj）と同じパスに配置し、プロジェクトのプロパティで設定を変更することで、ビルド時に自動的に bin/debug フォルダにコピーされるようになります。

手順：

1. 設定ファイルの配置
   user_account.txt をプロジェクトのルートディレクトリ、つまり .sln や .proj と同じパスに配置します。

2. プロパティ設定
   Visual Studio で設定ファイルを右クリックし、プロパティ を選択します。

3. 出力ディレクトリにコピー
   プロパティの中にある 出力ディレクトリにコピー を 常にコピーする に設定します。

これで、ビルド時に user_account.txt ファイルが自動的に bin/debug フォルダにコピーされるようになります。

結論：自動化で開発が楽に

この方法を使うことで、設定ファイルの手動コピーから解放され、ビルド時に自動で反映されるため、開発が格段に楽になります。今後、このような技術的な「ハマりどころ」をブログにまとめていくことで、自分自身の成長にも繋がると感じています。

ぜひ、同じように悩んでいる方がいたら、この方法を試してみてください。

日々の生活で当たり前に使っている都市ガス。しかし、実は「ガスコンロ（カセットコンロ）を使った方がコスパが良いのでは？」と考えたことはないだろうか。今回は、都市ガスとカセットガスのコストを比較し、本当にどちらがお得なのかを検証してみる。

日々の生活で当たり前に使っている都市ガス。しかし、実は「ガスコンロ（カセットコンロ）を使った方がコスパが良いのでは？」と考えたことはないだろうか。今回は、都市ガスとカセットガスのコストを比較し、本当にどちらがお得なのかを検証してみる。

冬の暖房、あなたはどっち派？カセットガスストーブ vs 石油ストーブ

寒い季節に欠かせない暖房器具の中でも、カセットガスストーブと石油ストーブは、電源不要で使えるため非常に便利です。しかし、どちらも使い方を間違えると、一酸化炭素（CO）中毒などの危険が伴います。

今回は、それぞれの安全性や一酸化炭素発生リスク、換気の重要性について徹底比較します。

1. カセットガスストーブの安全性

カセットガスストーブとは？

カセットボンベに充填された液化ブタンやプロパンを燃料とし、燃焼することで熱を発生させるストーブです。軽量で持ち運びがしやすく、キャンプや屋外作業でも活躍します。

カセットガスストーブの安全性と特徴

✅ 一酸化炭素の発生リスクが低い（完全燃焼しやすい）
✅ スイッチひとつで簡単に点火・消火できる
✅ メンテナンスがほぼ不要
❌ 換気をしないと酸素不足で不完全燃焼の危険
❌ 長時間使用するとガス切れしやすい

カセットガスストーブの安全対策

• 室内で使う場合は1時間に1回は換気をする
• 燃焼部が汚れていないか定期的にチェック
• 密閉された車内やテント内では使用しない

---

2. 石油ストーブの安全性

石油ストーブとは？

灯油（ケロシン）を燃料とし、芯に浸透させた灯油を燃焼させることで熱を発生させるストーブです。パワフルな暖房能力を持ち、寒冷地でも人気があります。

石油ストーブの安全性と特徴

✅ 高い暖房能力（広範囲を暖められる）
✅ 灯油が安価で燃料コストが低い
✅ 停電時でも使える
❌ 一酸化炭素発生リスクが高い（不完全燃焼の可能性）
❌ 定期的なメンテナンスが必要（芯の掃除・交換）
❌ 燃料の補充が手間

石油ストーブの安全対策

• 必ず換気をしながら使用する（最低でも1時間に1回）
• 燃焼部分の汚れを定期的に掃除する
• 劣化した芯を交換し、正しく燃焼させる

---

3. 一酸化炭素中毒のリスク比較

	カセットガスストーブ	石油ストーブ
燃料	液化ブタン・プロパン（カセットボンベ）	灯油（ケロシン）
一酸化炭素発生リスク	低い（完全燃焼しやすい）	高い（不完全燃焼のリスクあり）
換気の必要性	換気推奨（長時間使用時）	常に換気必須
メンテナンス	ほぼ不要	定期的な掃除・芯交換が必要
燃料の扱いやすさ	軽量で簡単に交換可能	灯油の補充が必要
暖房能力	小～中規模の空間向け	中～大規模の空間向け

---

4. どっちを選ぶべき？用途別おすすめ

• 「安全性重視、手軽に使いたい！」 → カセットガスストーブ
  → 一酸化炭素発生リスクが低く、初心者でも扱いやすい。室内で短時間の補助暖房として最適。
• 「広範囲をしっかり暖めたい！」 → 石油ストーブ
  → 暖房能力が高く、寒冷地や大きな部屋向け。ただし換気必須で、メンテナンスが必要。

---

5. まとめ：安全に使うなら換気が最重要！

カセットガスストーブと石油ストーブ、それぞれにメリット・デメリットがありますが、どちらも適切な換気と正しい使い方を守れば安全に使用可能です。

とくに、一酸化炭素は無色・無臭のため、換気を怠ると知らぬ間に中毒になる危険があります。

最後に、安全に使うためのポイントをおさらいしましょう。

✅ 1時間に1回は換気をする（どちらのストーブでも共通）
✅ 燃焼部分の掃除や点検を定期的に行う
✅ 車内やテントなど密閉空間では絶対に使用しない
✅ 心配なら一酸化炭素警報器を設置するのもおすすめ

この冬、安全で快適な暖房ライフを過ごしましょう！

風邪薬に含まれるコデインと大麻（THC含有）、どちらが体に悪いのか？法律の問題は抜きにして、純粋に健康への影響を総合的に比較してみる。

1. 依存性・中毒性

コデイン（麻薬性鎮咳薬）

✅ 体内でモルヒネに変化し、強い鎮痛・鎮咳作用を持つ。
✅ 長期使用で耐性がつき、量を増やさないと効かなくなる。
✅ 乱用するとオピオイド中毒になり、最悪の場合、呼吸抑制で死亡するリスクもある。

大麻（THC含有）

✅ 身体的依存は比較的少ないが、心理的依存が生じる可能性がある。
✅ 多量摂取で記憶障害・判断力の低下が起こるが、致死量に達することはほぼない。
✅ 突然やめても禁断症状は軽度なことが多い。

🛑 結論: コデインは強い身体依存を引き起こし、乱用すると致命的なリスクがある。一方、大麻は心理的依存が主で、致死的な影響は少ない。

 

2. 臓器への影響

コデイン

✅ 肝臓で代謝されるため、長期使用で肝機能障害を引き起こすリスクがある。
✅ 風邪薬の他の成分（アセトアミノフェンなど）との相乗効果で腎臓や胃にも負担がかかる。

大麻

✅ 喫煙による肺への負担はあるが、紙巻タバコほどの有害物質は含まれない。
✅ 食用やベイプ（気化摂取）なら肺への影響はほぼゼロ。

🛑 結論: コデインは肝臓・腎臓・胃に負担をかける。一方、大麻は喫煙すると肺に悪影響があるが、摂取方法を選べばリスクは軽減できる。

 

3. 長期的な健康リスク

コデイン

✅ 長期使用で脳の報酬系が破壊され、依存症になるリスクが高い。
✅ 過剰摂取で呼吸抑制を起こし、死亡する可能性がある。

大麻

✅ 記憶力・認知機能の低下が起こる可能性がある（特に10代の使用）。
✅ 遺伝的に**精神疾患（統合失調症など）**のリスクがある人には危険。
✅ ただし、使用をやめると機能が回復する場合が多い。

🛑 結論: コデインは長期使用で命に関わるリスクが高い。大麻は認知機能の低下が問題だが、回復可能な場合が多い。

4. 結論：どっちが体に悪い？

🔴 総合的に見ると、コデイン入りの風邪薬のほうが危険度が高い。
✅ コデインは強い依存性を持ち、過剰摂取で致死的なリスクがある。
✅ 大麻は記憶・認知機能に影響を与えるが、致死的になることはほぼない。

もちろん、大麻も安全とは言えないが、少なくともコデインのような直接的な命の危険は少ない。

とはいえ、どちらも安易に使用するべきではない。特にコデイン入りの風邪薬は、医師の指示なしに長期間使用すると危険な依存症につながる可能性があるため、注意が必要だ。

これまでずっとVisual Studio 2017を使用していましたが、環境の変更に伴い、Visual Studio 2022を使うことになりました。特に問題なく移行できるだろうと考えていたのですが、C#で新しくWindowsアプリを作成しようとした際に、以下のエラーメッセージが表示されました。

発生したエラー内容

プロジェクト作成時に以下のエラーダイアログが表示されました。

プロジェクト XXX の作成中に1つ以上のエラーが発生しました。

生成されたプロジェクトのコンテンツが不完全である可能性があります。指定された SDK ‘Microsoft.NET.Sdk’ は見つかりませんでした。

エラーを解消する方法

システムのプロパティ ＞ 詳細設定 ＞ 起動と回復 ＞ 環境変数(N)…

環境変数 ＞ システム環境変数(S) ＞ 編集

環境変数名の編集

C:\Proguram Files(x86)\dotnet\

これを削除する事でエラーが出なくなりました。

今回紹介したエラーと対処方法は、日本語圏のブログやサイトでは情報が見つからず、思わぬところで時間を費やしてしまいました。

今後、同じように困った経験をした際は、ぜひブログや備忘録として情報をまとめておきましょう。自分の経験が、他の開発者の助けになることもあります。

 

.NET 9.0（最新のバージョン）をインストールする

今回、dotnet-sdk-9.0.100-win-x64.exeをインストールした上でDOSから

dotnet –info

を実行し.NET SDKのインストール状況を確認してみたところ

.NET SDKs installed:
No SDKs were found.

のままでした。

正常に.NETがインストールされるとバージョンごとにこの様に表示されます。

Visual Studio 2022でソリューションにC#のWindowsFormプロジェクトを追加する

ソリューションの上で右クリック ＞ 追加(D) ＞ 新しいプロジェクト

プロジェクト選択時のポイント（Visual Studio 2022）

Visual Studio 2022でC#のWindowsアプリケーションを新規作成する際、画面上部で以下の手順を行うとプロジェクトの種類を絞り込めます。

1. 「C#」を選択
2. 「Windows」を選択
3. 「デスクトップ」を選択

これにより、作成するプロジェクトの種類が絞り込まれます。

プロジェクトの選択ポイント

• Windowsフォームアプリケーション（.NET Framework）
  赤枠で囲まれたこのオプションを選択すると、レガシー（古い）.NET FrameworkベースのWindowsフォームアプリケーションを作成できます。これは、従来のWindowsアプリケーションの開発に適しています。
• Windowsフォームアプリ
  黄色枠で囲まれたこちらを選択すると、.NET（.NET Core以降）を使用した最新のWindowsフォームアプリケーションが作成されます。クロスプラットフォーム対応の.NETで開発を行う場合に適した選択肢です。

---

要点まとめ:

• .NET Frameworkを使用したい場合は、「Windowsフォームアプリケーション（.NET Framework）」を選択。
• 最新の.NETを使用したい場合は、「Windowsフォームアプリ」**を選択。

選択を間違えないよう注意しましょう。

結構ハマった

最近まで、Visual Studio 2017 を使用していましたが、Visual Studio 2022 に乗り換えた際、いくつかの問題に直面しました。ネットで対処方法を解説しているサイトが見つからなかったため、その際の経験を備忘録としてまとめておこうと思います。

Visual Studio2017で元々開発していたプロジェクトをVisual Studio2022にして起動したところ、なぜか

chrome = new ChromeDriver(driverService, options);

の部分でエラーが発生し落ちる様になりました。

try catchで囲んでエラーをハンドリングしてみると

C:\WINDOWS\system32>Install-Package System.Buffers -Version 4.0.2
‘Install-Package’ は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

というエラーメッセージが表示されました。

エラーが解消されるまでに行った事をメモっておきます。

CreateDefaultServiceの引数にchromedriver.exeの含まれているパスを指定

string currentPath = Application.StartupPath;
                var driverService = ChromeDriverService.CreateDefaultService(currentPath);

ツール(T) ＞ NuGetパッケーマネージャー(N) ＞ パッケージマネージャーコンソール(O)

ターミナルが表示されるのでそこに

Install-Package System.Buffers -Version 4.5.0

と入力し実行します。

すると

‘.NETFramework,Version=v4.8’ を対象とするプロジェクト ‘MyBenefitTool’ に関して、パッケージ ‘System.Buffers.4.5.0’ の依存関係情報の収集を試行しています
依存関係情報の収集に 799 ミリ秒 かかりました
DependencyBehavior ‘Lowest’ でパッケージ ‘System.Buffers.4.5.0’ の依存関係の解決を試行しています・・・・

というメッセージが表示され処理が行われます。

コマンド実行でエラーが解消された理由

Install-Package System.Buffers -Version 4.5.0 を実行して正常に動作するようになった理由は、いくつか考えられます。

 バージョンの互換性の問題

System.Buffers 4.0.2 は古いバージョンで、特に .NET Framework 4.8 との互換性に問題があった可能性があります。一方、System.Buffers 4.5.0 はその後のバージョンで、.NET Framework 4.8 や他の環境での互換性が改善されています。4.5.0 は、古いバージョンよりも最新のパッチが適用されており、より安定して動作する可能性があります。

 依存関係の解決

NuGet パッケージには他のパッケージに依存している場合があります。4.5.0 バージョンでは、必要な依存関係が改善されたり、適切に設定された結果として正常に動作した可能性があります。バージョンアップで依存関係の解決が正しく行われ、エラーが解消されたということです。

リリースノートやバグ修正

System.Buffers のバージョン 4.5.0 は、バージョン 4.0.2 に比べていくつかのバグ修正やパフォーマンス改善が行われている可能性があります。特に、アセンブリのマニフェストや参照の問題が解消されている場合、古いバージョンでは発生していたエラーが新しいバージョンでは修正されていることがあります。

ターゲットプラットフォームとの互換性

System.Buffers 4.5.0 は、.NET Framework 4.8 などの古いプラットフォームと互換性があるように最適化されており、そのためエラーなく動作するようになったということも考えられます。特に .NET Framework での依存関係の解決や、バージョン間の整合性が改善されている場合があります。

結論

System.Buffers 4.5.0 バージョンは、より新しいバージョンであり、.NET Framework 4.8 との互換性が向上しているため、古いバージョン（4.0.2）で発生していたエラーが解消され、正常に動作するようになったということです。このように、最新のバージョンを使用することで、互換性や依存関係の問題が改善されることがよくあります。