Qiita内のC#erのための有用な記事リファレンス(2012年～)

PC版での閲覧を推奨。Qiita内右ペインの目次機能を活用してください

個人的まとめ記事
そのうちフルコンプする予定

• とにかく手当たり次第にC#を学びたい人向け

• 古い情報を漁りたい方向け

• 公開ストックとしても作成予定。

• 収録した記事には以下の内容を含む
  → WPF関連, RX,Winform関連,Linq,Unity
  → その他難解なアルゴリズムやあまり知られていない用語を含む

• 古い記事なので、現在のC#バージョン(.net 9.0以降)ではより効率よく書き直せる場合が多い。

• 記事内には若干の誤りを含む可能性がある。

• いいねが少ないものはかなり難解。

• 特に応用性に富む記事は私的に💡マークとして評価した。

• 記事の内容は恐らくほぼオリジナルだと考えてよいだろうと思われる

• この記事の内容は自由に再編集して構わない(例えばWPFとして再分類して良い)
  →　収録した記事に関しては必ずしもその限りではないが、十分許容されるものと信じる次第である

• 主項目はQiita内の記事のみを含める

• 個人的に調べた事を注釈として書いている※1

• アカウントは放置されて久しい物が多い模様

• 内容を深堀りしてほしい場合はいいねかストック。 内容はコメントへ※2※3

  • 実際に記事内容を実行して検証するのは疲れるので要望待ち。

• ★評価を追加。自分の評価をベースにAIを用いつつ慎重に判断している（つもり）-25/08/02

  • ★4(★★★★☆)以上は応用が利く、現代でも有効等の理由で有用だと見做して良い
  • ★3(★★★☆☆)以下：理解が浅い、内容に誤りがある、古くて時代遅れなど。

• ★評価基準

  • 現代的
  • 正確性
  • 応用性がある
  • テーマが良い
  • 内容的にも高度

$\color{gray}{\tiny \textsf{※1収録しているものは独断と偏見に基づいており、全ての記事を含めているわけではない。}}$

$\color{gray}{\tiny \textsf{※2 気が向いたら応じる}}$
$\color{gray}{\tiny \textsf{※3 編集回数は xいいね数 　 現在の編集回数は約12回}}$　

そのうち誰かがAPIで作ったりするのかもしれない

ワタシは生成ＡＩで意味を解説させてますが、ググっても出ないものがあるので一部の意味だけを含めています(詳しく知りたい場合は各自で研究すること)

この記事のView数

44194 viewsでち(2025/09/08じてん)。
45651 viewsでち(2025/11/16じてん)。
46418 viewsでち(2025/12/20じてん)

2012年

Clickで展開

C#でFizzBuzzをば(★★☆☆☆)

https://qiita.com/Kokudori/items/889d1531b9c635c64668
記念すべき(？)記録上初のC#タグの記事。
Ling の基礎的な使い方。Rangeメソッドから

enumの項目数を取得する(★★★☆☆)

https://qiita.com/kazuhirox/items/12319707ba2eb650e9e8

GPUIDを生成する(★★★☆☆)

https://qiita.com/redtower/items/e08361c35c37a548dde5

１月、2月…をJan. Feb. ...に変換する(★★★☆☆)

https://qiita.com/satrex/items/6bb4c140366263818d36

コンテナに格納したコントロールを取り出す順序(★☆☆☆☆)

https://qiita.com/kazuhirox/items/788508b5dc9546ae9ef0
winform向け

.Net + SQL Serverでテストデータを準備する方法(★★★☆☆)

https://qiita.com/satrex/items/ca08601739d4ce23dcb1

リフレクションで静的クラスのプロパティを取得(★★★★☆)

https://qiita.com/Kokudori/items/7c4b2ca35592e21af1d5
→ 非Staticでも可(BindingFlagsを変える)
→ DLLで読み込んだ型でも使える

💡コンスセルのリストで再帰版直積(★★★★★)

https://qiita.com/matarillo/items/90b4ff8061a3608c4428
コンスセルとは？

「コンスセル」はリストの先頭の要素と残りのリストを持つ構造体

関数型プログラミングの基本的なリストの形で、再帰処理に便利

C#で実装することで、不変で扱いやすいリスト操作ができる

• 直積：複数の集合に対して、すべての組み合わせを作る操作
• 用途
  再帰構文解析、履歴追跡
  スレッドセーフな処理、巻き戻し可能な状態(Undo)
  Lisp/Scheme風実装、数独・迷路・組み合わせ問題など

→　参考 : 代数的データ型 in Unity

→ 要素が増えると 組み合わせ爆発が起きやすいのでフィルタリングや遅延実行が必要

宣伝

これを応用してUndoRedoを実装しました！
いいねしないと消しちゃうかもしれないです（笑）

https://qiita.com/EndOfData/items/6966012efc2c8a11b953

💡コンスセルや再帰を使わずに直積(★★★★★)

https://qiita.com/matarillo/items/7f4f530fdc4130608ef4

• Stack<T>を使う
• 遅延評価
  → 組み合わせ爆発は前者と同じく条件絞り込みで対応

C#って普通に#if true とか #define とか使えるんだね。(★★☆☆☆)

https://qiita.com/ongaeshi/items/88526eafdbea3418ff0e

条件付きコンパイルは今のC#ではあまり推奨されないとのこと。

• 参考
  【C#】プリプロセッサ
  C# プリプロセッサ ディレクティブ(MicroSoft Learn)

既存のDataGridViewの列を持ったDataGridViewRowを作成する(★☆☆☆☆)

https://qiita.com/satrex/items/7171d71461e3cb147b75
Winform向け。

生＆死＝？　(★☆☆☆☆)

https://qiita.com/jumboly/items/d89e704a59ebd6404af8
→ 文字コードが偶然ある文字になることを利用したお遊び。

個数の異なる二つのリストをカンマ区切りで縦に結合する(★★★☆☆)

https://qiita.com/kazuhirox/items/96d2793ae9666eff88d8
→ 要素数が同じか短い方だけ必要ならLinqのZipメソッドが簡潔

💡C#でvar_dump(★★★☆☆)

https://qiita.com/rev84/items/2722096a1adedcdf0bbf
PHPのvar_dumpをC#的に実装したもので、オブジェクトの中身を簡単に再帰的に確認したい場合に便利

このままでは使い物にならない点に注意。

• いろいろと書き直す必要がある。
• シンプルなクラス構造の調査には向いている

→ 通常はリフレクションを使用する方がWPFコントロールには向いてるが、視覚的に表示するというアプローチは面白い

以下のライブラリの使用を推奨。
参考：既存のライブラリ

ObjectDumper
デバッグとログ記録の目的で C# オブジェクトを文字列にシリアル化することを目的としたユーティリティ
Dumpify
コンソール アプリケーション。

.Dump()に拡張メソッドを追加することで、生産性とデバッグ可能性が向上します。 任意のオブジェクトを構造化された多彩な方法でコンソール、トレース、デバッグ イベント、または独自のカスタム出力に追加できます。

nuget:https://www.nuget.org/packages/Dumpify

コルーチンの中で、更にWWWなどを使うメソッドを呼び出したい場合(★★☆☆☆)。

https://qiita.com/shinobu_shiva/items/9e71f4185e7cc01790ef
Unity向け。
ごく短い基本的なCodeで応用例に欠けるので-1
2025年現在、WWWは非推奨（Unity 2018以降）で、UnityWebRequestやUniTask、async/awaitが主流 -1

重い処理の実行中にプログレスバー{IsIndeterminate=True}付きウィンドウを表示する(★★★★☆)

https://qiita.com/dhq_boiler/items/930ff2dc960fd950d7a3

LINQでParserモナド(★★★★☆)

https://qiita.com/matarillo/items/d83a6961243e7c2848ee
HaskellのParserモナド等

モナドは関数型言語で副作用の管理や計算の連結を抽象化する仕組み。

「値を包むコンテナ」のようなもので、コンテナの中の値に対して連続的に処理をつなげていく方法を提供する。

2次元配列を列で取り出して演算する(★★★☆☆)

https://qiita.com/kazuhirox/items/62b46b4889c4d5896a6d
C# 9以降ではdouble型を省略してNew出来る。

LINQを使って、指定個数ランダムで取り出すには(★★★☆☆)

https://qiita.com/rohinomiya/items/2d60bc7b23ceb41fc06a

💡P/Invoke で __in_opt の引数を wrap するクラス(★★★★☆-)

https://qiita.com/AsladaGSX/items/9f911a91bcd3897fc650
C# から Win32 API を P/Invoke で呼び出す際、__in_opt 引数（NULL 指定可能なポインタ）をスマートに扱う方法を解説
__in_opt 引数を持つWin32 APIは多数ある。

• やや特殊な実装になるので-1

Formのローカリゼーションを一括切り替え(★★☆☆☆)

https://qiita.com/krsak/items/79983222c55feed78f0d
Winform向け。WPFではXAMLによるBindingが主流

💡メモリを節約して1000000番目の素数を求める(★★★★★)

https://qiita.com/matarillo/items/1f7af38b7c9f26de5079
エラトステネスの篩と呼ばれるアルゴリズムの使用例。

• 範囲が大きく、メモリ確保が困難な場合 CompositeTableなど動的管理が有利
• 範囲が小さい・固定の時 は配列が有利
  -「配列を使ったエラトステネスの篩」は高速で単純、メモリ使用量は範囲に直結して増加。
• 関連 Qiita記事エラトステネスの篩を使って素数を求める

LINQで7クイーン(書類選考無し＆高級うなぎGET)(★★★★☆)

https://qiita.com/matarillo/items/55f05087507e6b05ded5
構造体は色々と振舞いを持たせられる事を知った。
内容的にもLinqやジェネリッククラスを使い、高度

💡Log4Net を利用してログを記録する(★★★★☆)

https://qiita.com/rohinomiya/items/2b86c4e8d5afd5c2fb39
WPFでも問題なく使用可能とのこと。

→インストール方法：【C#, log4net】log4netを使う

Log4NetのNullオブジェクトを定義してNullチェックを不要にする(★★★☆☆)

https://qiita.com/rohinomiya/items/09a707dc700263bf68b4

💡try ~ catch で捕捉されてない例外をUnhandledExceptionで補足する(★★★★☆)

https://qiita.com/rohinomiya/items/c7f69713654c47f6c7cd
ちなみにVisual Studioの設定で、指定した例外を捕捉することも可能である

「filterM で powerset」をC#らしく(★★★★★)

https://qiita.com/matarillo/items/946fc244e81e3d382978

powerset（べき集合）というのは、すべての部分集合を集めた集合。

用途

• テストケース生成
  ┗　ペアワイズ法（pairwise testing）や組み合わせ削減法と併用することが多い

• ナップサック問題、サブセットサム問題、グラフの部分集合探索など、組み合わせ最適化で部分集合を列挙
  　┗実務例: スケジューラ、在庫管理、プロジェクト最適化、広告予算の配分など。

• 機械学習
  　→データ解析・機械学習:特徴量選択（Feature Selection）で、すべての特徴の組み合わせを試す場合に使用。
  　┗補足: 実際のMLでは、PowerSet列挙は計算コストが高いため、逐次前進選択（SFS）やLASSOなどの手法がよく使われますが、小規模な特徴量集合では全探索（PowerSet）も現実的。

• ゲーム開発・AI
  用途: 状態空間探索、合法手の全列挙、戦略の検討。
  例: ボードゲームで可能な駒の移動パターン、AIエージェントの行動組み合わせなど。
  具体例: 数独の解候補全列挙、パズルの組み合わせ評価。

• 暗号・セキュリティ
  brute-forceアプローチの一部であり、現代では効率化技術やヒューリスティクスが併用される。

　

NDesk.Options を使ってコマンドライン解析を楽にする (★★★☆☆)

https://qiita.com/rohinomiya/items/0b536d32c9e214261299

C# から、Growlを利用する(★☆☆☆☆)

https://qiita.com/rohinomiya/items/7b1ad2bae9aeb26fcce5
古いので非推奨

Rxを使って、LocationChangedイベントを捕まえる --泣きながらC#(★★★☆☆)

https://qiita.com/numa08/items/e9f61340f3de7698c804

Rx（Reactive Extensions）とは、イベントや非同期データをLINQのようにストリーム（データの流れ）として扱えるライブラリ。

→執筆者の理解度が不足しており-1
技術スタックの評価は高いので掘り下げる価値があるだろう

WPFに外部アプリ（Window）を埋め込む(★★☆☆☆)

https://qiita.com/kouh/items/7b55fbc72ffc91983575

• Thread.Sleepの使用はタイミング問題への対処が未熟(-1)
• WindowsFormsHostの使用はWPFとWinFormsの相互運用を知っているが、エラー処理やリソース管理の考慮がない(-1)
  • ex.異なるスレッドでUI操作を行った場合
    → InvalidOperationException（例：「呼び出し元のスレッドがこのオブジェクトを所有していないため、アクセスできません」）

数値文字列を指定桁で0埋めするにはString.PadLeft(桁,'0');(★★☆☆☆)

https://qiita.com/rohinomiya/items/132328fa682962cbc4a6

指定回数処理を繰り返すメソッド(拡張メソッド) (★★☆☆☆)

https://qiita.com/rohinomiya/items/cded0dba429581655db2

ForEach()メソッドをシンプルに書けるようにする(★★☆☆☆)

https://qiita.com/rohinomiya/items/99aa993cfe5def51bbe5

array(配列)に対する拡張メソッド

C#で可変長引数を使うには params(★★★☆☆)

https://qiita.com/rohinomiya/items/b8327999fd835132cb7a

Quine(クワイン、自己言及プログラム)(★★☆☆☆)

https://qiita.com/matarillo/items/c5c804329c92c11c2529
ひろゆきが言及していたらしい

C#　+ LINQ でJSONのパースをする(★★★★☆)

https://qiita.com/numa08/items/475ab3e8aa9e10441a26
Jsonの深い構造の抽出を上手く書いている。

enumの文字列表現を定義する(★★★★☆)

https://qiita.com/kazuhirox/items/d4f2ea04f81bf3da613c
UI表示や多言語化に応用が利く

num < .Count()ではなく.Skip(num).Any()の勧め(★★★★☆)

https://qiita.com/isishizuka/items/d8f3e5219fa933ee7f6f

POCOでDBの型を指定する(★★★☆☆)

https://qiita.com/Tokeiya/items/3a80068be422eae88ca6

POCO（ポコ）とは "Plain Old CLR Object" の略で、
「ごく普通のC#のクラス」を意味する。

意味が分かる人がいるのか？？？

💡イテレーター非同期(★★★★★)

https://qiita.com/matarillo/items/b51d39afebb115a19f0f
難解だが有用な記事
→AIによる解説
・明示的な継続渡しモデルによる非同期制御
・通常のasync/await方式より柔軟性が高い（らしい）
→実際の使用例は要望があれば記事化するかもしれない

既存DLL配布モジュールで発生する PInvokeStackImbalance の回避(★★★★☆)

https://qiita.com/AsladaGSX/items/4ce108a6b7a39cd5bdb2

.NETでアンマネージコードを呼び出す（P/Invoke）際、関数の呼び出し規約が一致していない場合などに起こるエラー

EnumerableEx.Generateを使う際の注意点(★★★☆☆)

https://qiita.com/Tokeiya/items/5f7295e73d3cde646352
前置インクリメント（++i）を初めて知った件。
→　インクリメントしてから代入する

Windows のワイルドカード文字列を正規表現に変換するメソッド (★★★★☆)

https://qiita.com/AsladaGSX/items/5d109cdfb9519e142ad3
→ Windowsのファイル名パターンを正規表現で使いたい時

赤黒木＋graphivizによる可視化(★★★★★)

https://qiita.com/oskimura/items/117a833226d0ec924944
赤黒木について 赤黒木 -Wikipedia

「自己平衡二分探索木」の一種で、木構造のデータを効率よく検索・挿入・削除できるデータ構造です。

赤黒木の用途例

• データベースのインデックス
• C++ STLのstd::mapやstd::setの内部実装
• メモリ管理やスケジューラの優先度管理

MissingManifestResourceExceptionの対処法(★★★☆☆)

https://qiita.com/nicklegr/items/72952aa0948cef741ccc

Link: MissingManifestResourceException 例外と MissingSatelliteAssemblyException 例外を処理する

C#: テキストボックスで、Ctrl+Aですべて選択できるようにする(★☆☆☆☆)

https://qiita.com/nicklegr/items/d3e97d6910a1353ff45b
Winform向け

C#からThrustを使う方法（またはネイティブなクラスを使う方法）(★★★★☆)

https://qiita.com/aokomoriuta/items/41a6dcf221fd3cf67c5b
→Thrustとは

NVIDIAが提供するC++向けの並列アルゴリズムライブラリ

→ C#からネイティブライブラリを呼び出す手法は、ハイパフォーマンスコンピューティングやゲーム開発で有用。ただし、C#でのGPU利用はCUDA.NETやOpenCLにシフトしつつある。

参考：Alea GPUで簡単C# GPUプログラミング

Link: https://developer.nvidia.com/thrust
用途

GPUを利用した処理

1. ソート（thrust::sort）
   a.大量データの高速ソート（int/float構造体なども可）

2. スキャン（累積和：thrust::inclusive_scan / exclusive_scan）
   a. 累積合計や累積処理に最適
   b.GPUの並列性を活かして数百万件を高速に整列

共有フォルダの情報を取得する方法(★★★☆☆)

https://qiita.com/Fuhduki/items/5684422965d769b42721
1.System.Managementの使用はWindows限定
┗NuGet パッケージの追加が必要
Nuget:https://www.nuget.org/packages/System.Management/

C#で、文字コードを表す文字列から、文字に変換する(★★★★☆)

https://qiita.com/rohinomiya/items/ca30f311f881cbb33ca8

使い道

• APIやファイルでUnicodeのコードポイント（16進数表記）だけが送られてくる時、それを実際の文字に変換したいとき。
• 動的な文字生成・操作
  　┗プログラム中で特定の文字コードを変数で受け取り、その文字を表示や比較、加工に使うケース。
  　 ┗ 直接文字列に「が」と書けない、文字コードだけ分かっている場合。
• Unicodeコードポイントと対応文字を簡単に確認・検証するとき。

汎用IsNull,IsNotNullの実装(★★★☆☆)

https://qiita.com/Tokeiya/items/949cf2e2be301f031178

Object型にCastしないと無限再帰になる。
注意点
is Null はC# 7.0以降で使える。
但し、このようなアプローチ(拡張メソッド)で独自実装を書けるという点では有用。

総ページ数の計算方法(★★☆☆☆)

https://qiita.com/ktz_alias/items/387e36ecd9f8a702161e

※記事の内容が誤っているので-1。
WebアプリなどのUI表示におけるページネーションのページ数 を指しているらしい

AI解析によると、Codeは先頭から itemsInPage 件をスキップしたあとの残り件数」を返すものであり、Skip を使えばページごとの先頭要素を取り出せるから、それを数えればページ数になる」と誤解している

正しい総ページ数の計算方法(★★★☆☆)

//ex.WPFでDataGridを使用するものとする

// ItemsSourceを IList にキャストして要素数を取得(dataGrid1から)
System.Collections.IList itemsSource = dataGrid1.ItemsSource as System.Collections.IList;

int totalItems = collection.Count();

int itemsInPage = 20;  // 例：1ページあたり20件表示

// 総ページ数を計算（切り上げて整数に変換）
int totalPages = (int)Math.Ceiling((double)totalItems / itemsInPage);

Unity C# DLL化 メモ(★★☆☆☆)

https://qiita.com/prototechno/items/31791ffce409b29d3ccc
MacOS向け。
→ 当然なのだが2012年時点の情報である
→ .NET 3.5ベースで、最新のC#機能（C# 8.0以降）や.NET Standard 2.1に対応していない。

現在の変更点
Unity Hubの導入（2018年頃～）により、Unityエディターのインストールパスが柔軟に変更可能に。複数のUnityバージョンを管理するため、デフォルトパスは以下のように変化：

Termina

+ mcs -r:/Applications/Unity/Hub/Editor/2022.3.10f1/Editor/Data/Managed/UnityEngine/UnityEngine.CoreModule.dll -target:library -out:hoge.dll hoge.cs

※未検証なので注意。
※当方はMac環境を持ってないので、検証して編集リクエストを

補足:Mac版Visual StudioでUnity用のDLLを出力する方法

C#によるRubyっぽい繰り返し（★★☆☆☆）

https://qiita.com/kazuhirox/items/cd6a0d6ffd100ee48041

個人開発向き。
拡張メソッドでForループ処理をRubyっぽく実装したもの。
慣れた言語の構文をCsharpで使いたい人には良いかもしれない。

テキストファイルを任意の場所から読む方法(★★★☆☆)

https://qiita.com/kazuhirox/items/cb9887fe739c8744f096

ループするページ番号の計算方法(★★★☆☆)

https://qiita.com/ktz_alias/items/6cb831936d9c011e78f6

Unity初心者がハマる11の「罠」～考察編(★★★★☆)

https://qiita.com/gamesonytablet/items/20b25ad9729e4a353c96
C#タグとしてバズってる(いいね100越え)のはここが初出。

[ネタ] C# でDictionary生成リテラル(★★★★☆)

https://qiita.com/wonderful_panda/items/3fe025f4c68855d465ad
式ツリーを使った斬新なDictionary生成
実用性には欠けるもののユニークな発想

Dictionary.FirstOrDefault() で値が取得できたか判別する方法(★★★☆☆)

https://qiita.com/rohinomiya/items/4a3a72b7197e6fdb93df

LINQの集合演算(★★★★☆)

https://qiita.com/kazuhirox/items/afa154232e636c9ca415

Webサービスで公開するエンティティが循環参照する場合の解決法(★★★☆☆)

https://qiita.com/satrex/items/1627d19f232d6b814612
System.Web.Services.WebService（ASP.NET Webサービス）とXmlIgnoreを使用しており、2000年代の技術（ASMX）に依存
現在のC#開発では、ASP.NET CoreやgRPC、JSONシリアライズ（System.Text.Json）が主流

イベントハンドラのスレッドセーフ性(★★★★☆)

https://qiita.com/karno/items/a4b2a744659a5b0a4df4
スレッドセーフ：イベントハンドラがNullReffrenceExceptionにならないための実装方法の提示

C# で シングルトンパターン(★★★☆☆)

https://qiita.com/rohinomiya/items/6bca22211d1bddf581c4
もう知ってるから個人的にはどうでもいい
基本的にコンストラクタでやってる
AIによる説明：シングルトンパターンはC#の標準的な実装（privateコンストラクタ、静的インスタンス）で、2000年代から広く使われている。ただし、C# 4.0以降の**LazyやDI（依存性注入）**が現代的な代替として推奨

スレッドセーフ性の複雑さ：シングルトンの初期化をスレッドセーフにするには、明示的な同期（lockやdouble-checked locking）が必要で、実装が複雑になりがち。
テストの難しさ：シングルトンは静的な状態に依存するため、モックやスタブを使った単体テストが困難。
依存関係の管理の難しさ：シングルトンは依存関係をコード内に硬直化させ、柔軟性や拡張性が低下する。
状態管理の問題：グローバルな状態を持つため、意図しない副作用や状態の共有によるバグが発生しやすい。
これらの課題を解決するために、C# 4.0以降のLazyや依存性注入（DI）が推奨されるようになりました。

NUnitで自作クラスのユニットテストを行う(★★★★☆)

https://qiita.com/rohinomiya/items/47f09523f1b9dfa015b1

ジェネリックと拡張メソッドを使ってみる(★★★★☆)

https://qiita.com/rohinomiya/items/1aa08c088a62f46d9fe1

実行ファイルとDLLを一つにまとめる(★★☆☆☆)

https://qiita.com/krsak/items/75a257cc0866a7e8e4aa
ツールとしては古い
ILmerge : https://github.com/dotnet/ILMerge
対応は.NET Framework 1.0、1.1、2.0、4.0
現在ではVisualStudioに単一ファイル公開機能があり不要。

C#: ウィンドウの位置・サイズ・最大化状態を保存する(★★☆☆☆)

https://qiita.com/nicklegr/items/faefb804697a395b148d
Winform用だがWPFでも同じアプローチは取れる。
この方法はWindows内のUsers\[ユーザー名]\AppDataフォルダ内に保存されてしまうので、何となくお勧めしない(アクセス性が良くないから)。まあせいぜい数十kb程度だと思われるが。個人的にはiniやJsonの方が好き。
使えるとはいえば使えるが

C#でイベントハンドリングによるオブジェクト間データ渡し（原題：C＃でオブジェクトからオブジェクトへ変数を渡すには　★★★☆☆)

https://qiita.com/Feel-Physics/items/4c5b5e4d77350a60cf62
記事のタイトルが誤っているので便宜上変えた。
応用性は高いが書き方は古い。もっといいCodeに書き換えられる。

.Net用DLLを動的に呼び出す(★★★☆☆)

https://qiita.com/kazuhirox/items/55d9cba408eb9c752956

2012年度の（たぶん）有用な記事は以上になります。

2013年

★評価は後日。

C#: 実行時に名前を指定してメソッドを呼び出す

→リフレクションより簡潔に書ける
→インスタンスの型が不明な場面（DIや外部アセンブリなど）でも有用。

注意点：
　┗型チェックが利かないので実行時エラーになる可能性
　　┗Activator.CreateInstanceは通常、Nullにならない。

ディレクトリ内のファイルを正規表現で

正規表現(.txt ファイルだけ取得)

Regex reg = new Regex(@"\.txt$", RegexOptions.IgnoreCase);

→サブディレクトリを含める
Directory.GetFiles(path, "*", SearchOption.AllDirectories)

Listの末尾にListを追加する

→元のlistを破壊的に（そのまま）変更する
この場合は第1引数のlist1が変更される。
→元のListを保持する場合はConcat.toList()を使用する

Xamarin.Android で作った HelloWorld のソースを眺めてみる

https://qiita.com/kazuhirox/items/55d9cba408eb9c752956
Xamarin.Android向け。androidアプリ開発者向け。
IDEも古くてもうメンテナンス以外で使われていない。
現代では.net MauiやFlutter等がトレンド

┗Xamarin.Android で画面遷移時にデータを渡す
　https://qiita.com/amay077/items/8752e7e5db233f5cc73f
┗Xamarin.Android で Reactive Extensions を使う
　https://qiita.com/amay077/items/8f4b33daa6ca4e4c8c9d

LINQメソッドにShuffleを追加する

https://qiita.com/kuchikios/items/6cfc1140a023e3928a17
ユニークなアイディア。これだと真のランダムとは言えないとのこと。
RandomNumberGeneratorを使うと良い。

参考：C# で乱数を生成する方法

AI生成のCodeでは芸がないので割愛。

yieldを使ってみる

• 用途
  逐次的にデータを返す（イテレーションの簡略化）
  複雑な列挙処理をわかりやすく書く
  条件に応じた遅延処理
  再帰的列挙

Xamarin.Android で Google Maps Android API v2 を使う

• 現代で主流のフレームワーク

1. .NET系

.NET MAUI (Multi-platform App UI)
Xamarin.Forms の後継。
1つの C# / XAML コードベースで iOS / Android / Windows / macOS アプリを構築可能。
→ マルチプラットフォーム開発を Microsoft 正式に推している。

Uno Platform
UWP/WinUI のAPIをベースに、WebAssembly・iOS・Androidなどへ展開可能。

2. JavaScript / TypeScript 系

React Native
JavaScript/TypeScript + React でクロスプラットフォーム開発。
エコシステムが大きく、Expo との組み合わせが一般的。

Ionic + Capacitor
Web技術（Angular / React / Vue）でアプリを作り、ネイティブ機能は Capacitor プラグイン経由で利用。

NativeScript
Angular や Vue と統合でき、JavaScript/TypeScriptから直接ネイティブAPIを呼べる。

その他
Flutter (Google製)

一時的に除外したいソースは #if falseで。

Microsoft.Office.Interop.Excelのあれこれ

https://qiita.com/rbtnn/items/881a37e237e8c49f3c97
有用な点
Workbook を New してはいけない、Application オブジェクト経由で操作する、といった注意点は現在でも変わらない。
32bit/64bit や Excel のバージョン依存の問題も同様に注意が必要。
難点
.NET Core / .NET 5 以降では Office Interop はサポートされない
現代ではOpen XML SDKが推奨：https://learn.microsoft.com/ja-jp/office/open-xml/open-xml-sdk

TaskCreationOptions.LongRunning

• 現代の C#(.NET 6以降) では、async/await と Task.Run を組み合わせるのが主流。
• TaskCreationOptions.LongRunning は今でも利用可能だが、用途は限定的：
  → CPU バウンドで長時間走る処理
  → ThreadPool のワーカースレッド枯渇を避けたい場合

参照：TaskCreationOptions 列挙型

Prefab のアタッチメントを効率化させる

https://qiita.com/VoQn/items/0c0d3fe8aa62699b903a
Unity向け。

• Instantiate と Destroy は現在も主要 API
• 注意点（現代向けのベストプラクティス）

破棄の仕組み*

• 直接 Destroy(instance, seconds) を使うほうがシンプル。
• Update で監視するより負荷も低い。

オブジェクトプールの利用

• 頻繁に生成・破棄する場合、今は ObjectPool（UnityEngine.Pool 名前空間）が用意されています。

• 弾・エフェクトのような大量オブジェクトは Destroy せず再利用するのが主流。

• アドレス指定の管理
  Addressables を使うプロジェクトでは、Prefab の生成元を Addressables.InstantiateAsync に置き換えるのが現代的。

MSSQL(SQL Server)のデータサイズをLINQで求めてみた

AI解説： SQL Server には sys.columns、sys.types、sp_spaceused などの公式手段があるので、わざわざ switch で管理する必要はない。

Monoで名前付きMutexが期待通りに動作しない問題の解決方法

https://qiita.com/krsak/items/eca543fe6a6f414d54d7
Mono自体が古いので資料扱い

アプリケーションの多重起動を禁止する

• 基本的にこの方法はまだ有効。
• ただし現代では WindowsFormsApplicationBase や WPF の SingleInstance 実装（CommunityToolkit などのサンプル）を使ったほうが簡潔。

Visual Studioではなく、Windows付属のcsc.exe だけでC#実行ファイルを作る

https://qiita.com/toshirot/items/dcf7809007730d835cfc
今では古く、歴史的資料。
現代なら .NET SDK (dotnet build, dotnet run) を使う方が圧倒的に便利

ワイルドカードを使用した文字列マッチ

https://qiita.com/kazuhirox/items/5e314d5e7732041a3fe7
Windows のワイルドカード文字列を正規表現に変換するメソッド (★★★★☆)との比較

項目	WildCardToRegex	Regex.Replace 簡易版
想定用途	Windowsファイルパスの末尾マッチ	汎用ワイルドカード置換
複数ワイルドカード	; などで区切ってまとめて処理	未対応
入力チェック	厳密（null, 空, 不正文字）	無し
読みやすさ	複雑（実用寄り）	非常にシンプル
柔軟性	低い（パス専用に近い）	高い（応用自在）
学習・記事向け	実務寄りの例として有効	入門記事向けに最適

並列処理してみる

https://qiita.com/krsak/items/bf1c123f41d391539dd0
かなり良い記事
.NETの並列処理記事としては今でも通用する。

参考Qiita記事
https://qiita.com/tera1707/items/5535d730be055b7a6845
https://qiita.com/unsignedint/items/2bb663c8fb92ff0d2b5c

foreach で break された場合に処理を実行する

良記事。

foreach で列挙されない場合に処理を実行する

用途

• 検索処理で最初にヒットした要素で終了する

• 進捗表示や監視
  → 全件処理する前に break された場合に「キャンセルされました」的な通知を出す。

• リソース管理
  → 列挙の途中で break されたら専用リソースを解放したり、トランザクションをロールバックする。

• 途中キャンセルの検出
  → ユーザーが UI 操作などで早めに break した場合に「中断終了」として扱う。

• フェイルセーフ
  → 本来最後まで回るはずなのに途中で止まったら「異常」とみなして補助処理を走らせる。

• 制御フローの明示化
  → break が起きることを意図的にフックして、単なるループ中断以上の意味（例：early return、条件分岐の代替）を持たせる。

.NET で Team Foundation Server に接続する - まずは接続

• 集中型バージョン管理システムでGitの走りみたいなやつで、Microsoft が提供していた集中型バージョン管理システム を中核とする開発支援サーバー
  ソース管理だけでなくバグ管理、ビルド、テストなど開発に必要な機能を一通りまとめた“全部入り”のプラットフォーム。
• 現代ではレガシーで、Azure DevOps Serverと名称が変わってる
• クラウド版（Azure DevOps Services）が基本推奨だけど、金融系や官公庁のようにクラウドに出せない環境では Azure DevOps Server（旧TFS）がまだしっかり使われている。

Concurrent CollectionのGetEnumeratorメソッドの挙動に関して

例外が出ない安全な観察手段
向いている用途

• 監視やデバッグ用のスナップショット取得
  例: ワーカースレッドのキューにどのくらいタスクが溜まっているかをざっくり確認する
  → 厳密な一貫性は不要、例外が出ないことが重要
• 統計やログ出力などの参考情報収集
  例: ある時点の内容をログに書き出す
  → 部分的に古かったり欠けたりしても許容できる
• 処理フローに影響しない読み取り
  例: 状態を UI に表示する（目安でよいケース）

厳密な一貫性が必要な集計や計算や最新状態を保証したい場合には向かない

順列をC#で

https://qiita.com/matarillo/items/7a719fc6d04bc7cf728c
学習目的の色合いが強く、あまり実用性はない。

VB.NETでラムダ式やらデリゲートを扱う際のちょっとした注意点

VB.NETでは､C#で許容されなかったラムダ式に対する推論が許容されますとのこと
呼び出しオーバーヘッドも実測してある

クライアントアプリからブラウザを開いて自動ログインする方法

https://qiita.com/k-kobayashi/items/a741f9da9a0a97ce2c01
セキュリティ的に危険な方法なので非推奨
現代なら

• Web 認証標準を利用する
  OAuth 2.0 / OpenID Connect を使い、アプリからブラウザを開いてリダイレクト URI 経由でアクセストークンを取得する
  → .NET なら Microsoft.Identity.Client (MSAL)
• 安全な資格情報の管理
  平文 HTML にユーザー名・パスワードを埋め込むのではなく、OS の 資格情報マネージャー や セキュアストレージを利用
• 組み込みブラウザ (WebView2 など)
  アプリ内にブラウザコンポーネントを埋め込み、公式のログインページをそのまま表示
  →　自前で POST 用 HTML を生成せずに済む

LangExtの紹介 - LangExtとは何であって、何でないか

LangExt:https://github.com/LangExt/LangExt
日本人開発者によるライブラリ。

今はLanguageExt(https://github.com/louthy/language-ext)
がより広く使われる。スター数も多い

項目	LanguageExt	LangExt
開発者	Paul Louth (louthy)	bleis-tift,otf
規模と機能	包括的で多機能（モナド、アクターシステム、不変コレクションなど）	シンプルで特定の関数型機能に焦点
メンテナンス	活発に更新、最新のC#機能を活用	比較的小規模、更新頻度が低い
標準クエリ演算子	LINQと統合可能	標準クエリ演算子を意図的に排除
F#との相互運用	サポート	特に言及なし
命名規則	キャメルケース（ML風）	C#の慣習に近い
用途	大規模・複雑な関数型プロジェクト	小規模なプロジェクトや特定の問題解決

Partialクラスのファイルを元クラスの子として表示

https://qiita.com/kobake@github/items/87239e4d50fe0031513c
Winfom向けだがVisual Studio2022でかつWPFでも使える。
地味に役立つ？

Prototypeパターン

https://qiita.com/mzks/items/ab73cbfa882993c59fb6
Codeの出来はそれほどでもないようだけど知らなかったのでメモ代わりに。
用途

1. 高コストなオブジェクト生成の回避
   グラフィックエディタで、複雑な形状オブジェクト（例: 3Dモデル）をゼロから生成せず、テンプレートをクローンして再利用。
2. 動的なオブジェクト生成
   例: ゲーム開発で、敵キャラクターのテンプレート（HP、攻撃力など）をクローンし、異なるパラメータ（例: レベル別敵）を生成。

Nancy入門してみた。

https://qiita.com/rbtnn/items/05bb0c1f1a0f810f9cc2
2020年頃にメンテナンスが停止。
後継はCarter、ASP.NET Core (Minimal APIs)、Jasper

(.NET) リストビューのカラムヘッダに設定したアイコンを消す方法

https://qiita.com/kobake@github/items/efe041f779e52bc471cb
Winform向けのニッチ記事。

OmniSharp(on Mountain Lion)導入メモ

https://qiita.com/FGtatsuro/items/ff29b43fcc9cafaf1e4c
時代遅れ。後継：C# Dev Kit、VS Code C# Extension (Roslyn LSP)

数値リストdataの要素中で、値がもっともtargetに近い要素のインデックスを得る

https://qiita.com/kazuhirox/items/26f2632b0cef4a5fed8a
用途：

• センサー値（例: 温度、距離）や時系列データで、特定の値に最も近いデータポイントを見つける。
• 数値リストをループや手動比較せずに、LINQで1行で最小差のインデックスを取得。
  例: 機械学習の前処理やデータ分析で、基準値に近いサンプルを特定。
• Unity（C#ベース）での位置やパラメータの近似マッチング。
  例: プレイヤーの入力値に最も近いプリセット値（例: スライダー位置、角度）を選択。

nunit-console2で指定したテストのみ流す

https://qiita.com/FGtatsuro/items/1aeab6d32ca10997b1db
後継はnunit3-console.exeで、コマンドも異なる

Unity3Dで、スクリプトからカメラを新規作成する

https://qiita.com/JunSuzukiJapan/items/4771b4515d23fd86035d
古いので非推奨のCodeが含まれている。

• 使える点: UnityのEditor API（MenuItem属性、EditorUtility.CreateGameObjectWithHideFlags）はUnity 2023.x（最新安定版）でもサポートされており、基本的なカメラ作成ロジックは動作します。
• 使えない/問題点:
  obj.cameraは非推奨
  MonoBehaviour継承はEditorスクリプトでは不要（静的メソッド中心のため、プレーンクラスで十分）
  現代のUnityでは、Prefab作成やHierarchy統合の進化で、より洗練された方法（例: PrefabUtility）が推奨されます。

Unity3Dで、ラベルの色も変えつつ、EditorStyles.numberFiledみたいな見た目にする。

https://qiita.com/JunSuzukiJapan/items/5e6a9449a5927befa065
コードは明確にIMGUIパターン（OnGUI内で即時描画、EditorGUILayoutのレイアウト関数）。現代ではUI Toolkitが推奨されるとのこと。WPFのPrismみたいなものらしい。

Unityで、自作Assetをdllファイルにコンパイルする

https://qiita.com/JunSuzukiJapan/items/111e583f81ee3d2cbd29
もちろん古い記事なので非推奨

• 現在の推奨手順（Visual Studioを使ったDLL作成）
  元の記事のシェルスクリプトに相当するのは、コマンドラインでdotnet buildを使う方法
  参考：https://docs.unity3d.com/Manual/plug-ins-managed.html

複数の数値型が混在する配列をキャストする

https://qiita.com/gaya_K/items/aa65903bf15d4a49d713
古い記事でも純粋なC#系記事は今でも有用。
。標準的なLINQのCast<int>()ではInvalidCastExceptionが発生することを指摘し、dynamicキーワードを使った拡張メソッドDynamicCast<TResult>()を提案。

複数の数値型が混在する配列が出てくるシーン

• 例: CSVパーサーが数値をobjectとして読み込み、int（例: 42）、double（例: 3.14）、decimal（例: 99.99M）が混在する配列を生成。
  → 典型例: データ分析ツール、Excelインポート、Web APIから取得した動的JSON（Newtonsoft.JsonやSystem.Text.Jsonでパース）。
• Unity特有の動的スクリプト処理
  典型例: プロシージャル生成ツール、データ駆動型ゲーム（例: RPGのステータス計算）で、異なる数値型を一括管理。
• データ変換やテスト時の仮データ
  典型例: データパイプラインのプロトタイプ、アルゴリズム開発時の仮データ。
• リフレクションやジェネリック型を扱う高度なシナリオ
  例: ORM（例: Entity Framework）やカスタムシリアライザで、プロパティ値がobjectとして取得され、数値型が混在。

64bitのODP.NET（Oracle.DataAccess.dll）をVisualStudio（Web）で使う際に注意すべき３つのこと

https://qiita.com/lainzero/items/356d98084bc60bb83ea9
現代でも金融機関やレガシーシステムを抱える企業では、OracleデータベースとODP.NETを使用したWebアプリケーション開発は引き続き一般的。
→ 注 : シェアは減少傾向らしい

• ただし Visual Studio 2013 以降 では既に 64bit IIS Express を選択できるオプションが UI 上にある場合がある。
• 現代の開発では Oracle.ManagedDataAccess.dll（フルマネージド版ODP.NET）を使えば、ビット数の問題はほぼ気にせず使えるため、そちらを推奨。

Console.WriteLine(10 == null);

• LINQでの誤記（Key == null）で意図せず全要素がマッチするバグは 実務で頻発する典型例。
  → 特に Dictionary<TKey, TValue> で TKey が struct のとき、null判定が常にfalseになる危険性を警告しており、防御的プログラミングの教科書的ネタ。

→ C# 1.0から現在（C# 13, 2025年）まで不変

• == 演算子オーバーロードの有無によるコンパイル差異の検証は 鋭い。
  Equatable：op_Equality あり → null まで解析 → ボックス化で比較可能（警告）
  NotEquatable：op_Equality なし → コンパイラが struct == null を プリミティブ比較不可 と即座にエラー（CS0019）
  推察がほぼ正しい。

• 問題点

  • 実際には「== オーバーロードの有無」が鍵ではなく、null リテラルとの比較が許可されるのは、演算子が object 引数を受け取る場合（ボックス化可能）のみ。

WebアプリからOracleに接続するconnectionStrings（tnsname.ora不要）

https://qiita.com/lainzero/items/32f424c98544c7a1b2fe
Oracleシリーズ。
tnsnames.ora を回避して DESCRIPTION= を connectionString に直書きする手法は、今でも普通に通用するとのこと(要検証)。

WebアプリでDebugビルドとReleaseビルド時にconnectionStringsを切り替える

https://qiita.com/lainzero/items/c6221917040784be3150
.NET Framework + Web.config に限定された手法であり、.NET 6以降 の世界では appsettings.Development.json / appsettings.Production.json が主流。
当時の小技として歴史的資料。

^

https://qiita.com/enpel/items/67cef290fbcbed642bcf
Objective-C のブロックと C# のラムダの対比というトピック
内容は正確。
...どうでもいいけどこんなタイトルだと誰も読まないかも

幅優先探索 (BFS) : 第13回オフラインリアルタイムどう書くの参考問題。C#で解く。)

https://qiita.com/norioc/items/9f31d59d4dc135dd87ce
最近でも見かける競プロ系の記事。
幅優先探索は「距離がすべて同じ（＝コスト1）」という前提で、最短経路・最小手順を求めるときにひときわ輝く。
普及度は中ぐらいとのこと。

• 用途

用途カテゴリ	説明	典型例
最短手順の計算（無重みグラフ）	コスト=1 の操作のみの世界で最短ステップを保証	数値操作パズル、Word Ladder、最短移動
迷路探索	最初に到達したルートが最短になる	2D/3D 迷路、ゲームマップ、ロボット探索
レベル分け（距離計算）	開始点から全ノードへの距離を計算	SNS距離、木の深さ、Hop数
連結成分の検出	グラフ内の「島」を数える	画像処理の領域分割、ネットワーク構造解析
最短経路の復元	親ノードを記録し探索後に経路を逆算	迷路の道順復元、ナビゲーション
状態空間探索	状態をノードとみなし、最短手順を探索	スライドパズル、簡易AI、操作最短手順
マルチソース BFS	複数の開始点を同時に扱う	感染シミュレーション、距離場生成
0–1 BFS	辺重みが 0/1 のとき高速な最短経路	軽微なコスト差グラフ、軽量ルーティング
二部グラフ判定	色分けしながら BFS して二部性を判定	グラフ彩色、相性グループ分割
到達可能性判定	特定ノードへ到達できるか判定	依存関係解析、ネットワーク到達性

Unicode Han Database を用いた簡体字 → 繁体字変換の実装

https://qiita.com/atsushieno/items/96d7e18eecdb32b325fc
原理を学びたい人向け。

用途

• 用途1：繁体字版・簡体字版の同時提供（国際化）
• 用途2：データ統合（検索・照合）
• 用途3：機械翻訳や NLP の前処理
• 用途4：文章処理ツール・電子辞書などの内部機能
• 用途5：学術・研究用途
  　→ 歴史学・言語学で異体字リストを引くため。

簡体字 → 繁体字変換は人気ライブラリがある。

.NETで簡体字↔繁体字変換するなら「これ」がおすすめ

ライブラリのCodeを読んでみるのもいい

ライブラリ	対応フレームワーク / バージョン	互換性ノート	依存関係 / 要件
OpenCC.NET	- .NET Standard 2.0 - .NET Framework 4.6.1+ - .NET Core 2.0+ (.NET 5/6/7/8/9/10互換)	.NET Frameworkと.NET Core/.NETの両方をサポート。並列処理やJieba.NET統合が可能で、クロスプラットフォーム。	OpenCCの辞書ファイルが必要（NuGetで自動インストール）。Visual C++ Redistributable推奨（Windows）。
jieba.NET	- .NET Standard 2.0 - .NET Framework 4.0+ (4.0/4.5) - .NET Core 2.0+ (.NET 5/6/7/8/9/10互換)	.NET Frameworkと.NET Core/.NET Standardプロジェクトの両方に対応。Paddleモード非サポート（v0.42.2基準）。	Resourcesフォルダ（辞書ファイル）をアプリディレクトリに配置。app.config/web.configでパス設定可。外部依存なし。

他にもマイナーなライブラリが幾つかある。

x => x.Hoge.Fuga.Piyo と指定しても正しく PropertyChanged イベントを受け取る

https://qiita.com/gaya_K/items/d1f80a295281375adc4c
ネストされたプロパティの変更には、手動でのイベント チェーンが必要になり、面倒。式ツリーを使用してドット表記パスを解析し、プロパティ階層ツリーを構築し、リフレクションを介して各レベルでPropertyChangedという解決策を提示。

同様のテクニックがPrismでも使える。

Unityで画面をタップした時のRayの撃ち方を考えてみた

内容的には現代でも十分に通用するレベルにある。

項目	2013年当時の内容	2025年現在の評価・対応状況	現代でも通用する度
Raycastを1箇所にまとめる	カメラ1個だけがRaycast	モバイル/VR/AR全てで必須の最適化手法	★★★★★
個別オブジェクトが毎フレームRaycastしない	各オブジェクトがUpdateでRaycast	発熱・バッテリー対策として今でも鉄則	★★★★★
イベント駆動で反応させる	TapBehaviour抽象クラスでコールバック	現在はinterface + C# event / UnityEventが主流	★★★★★
Input.GetMouseButtonDown(0)	エディタ＆PC対応の簡易入力	新Input System推奨だが、エディタデバッグでは現役	★★★★☆
abstract classで継承	TapBehaviourを継承	interface + TryGetComponentが現代風	★★★★☆
Collider必須の設計	Physics.Raycast + GetComponent	2DならRaycastHit2D、3Dならそのまま	★★★★★
1フレームに1回だけRaycast	TouchHandlerが一元管理	パフォーマンス設計の教科書レベルで正しい	★★★★★

範囲外の enum

Enum.IsDefined を使ったチェック例や、未定義値を switch 文で扱う方法なども補足すると読者への価値が上がる。

ComboBoxにEnumを列挙する。

現代では使われない古い書き方。2013年当時なら★５だったとのこと

WPFで「同じことをやるならこう書く」サンプル

<!-- XAML -->
<ComboBox ItemsSource="{Binding Fruits}"
          SelectedItem="{Binding SelectedFruit}"
          DisplayMemberPath="DisplayName" />

// C# 13 + .NET 8 + CommunityToolkit.Mvvm 9+
public enum Fruit
{
    [Display(Name = "リンゴ")]
    Apple,
    [Display(Name = "ゴリラ")]
    Gorilla,
    [Display(Name = "ラッパ")]
    Trumpet
}

// ViewModel
public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    private Fruit selectedFruit;

    public IReadOnlyList<Fruit> Fruits => Enum.GetValues<Fruit>();
}

特定のクラスを継承していて、かつ特定のインターフェースを実装している型を受け付けるメソッドの作り方

ジェネリック型制約で両方を強制する方法は C# 的に型安全で洗練されており、実務でもよく使えるテクニック。

Disposed

地味に有用で、即戦力レベル。

強味

1. アンマネージドリソースの安全管理が入っている

アンマネージドリソース（IntPtr やファイルハンドルなど）まで扱うと GC に頼れない部分 が出てくる。
デストラクタ（ファイナライザ）と Dispose(bool) の二重レイヤーで管理する設計は .NET Framework から推奨される公式パターン。
誤って解放タイミングを間違えるとクラッシュやメモリリークにつながるため、意外と高度な内容。

2 二重解放防止（Disposed フラグ）

_disposed フラグで二重解放や破棄済みアクセスを防ぐのも単純に見えて 安全設計の重要ポイント。

これを抜かすと、オブジェクトの状態を保証できず、バグが潜む可能性がある。

3 継承可能で拡張性のある設計

DisposeManaged() / DisposeUnmanaged() を protected virtual にしてオーバーライド可能にしている点は、単なる使い捨てクラスではなく ライブラリやフレームワークレベルの再利用性 を意識した設計。

実務で「継承階層の中でリソースを安全に解放したい」となると、この設計は必須レベル。

C#10〜11 でinit プロパティやusing varが使用でき、可読性が上がる。

// init プロパティ（ラムダ式用のカスタム Dispose）
//初期化時のみ設定可能で、その後は変更できないプロパティ」
//つまり完全コンストラクタパターンのキーワード化
public Action? OnDisposeManagedAction { get; init; }

public Action? OnDisposeUnmanagedAction { get; init; }

// using var 宣言
using var d = new LambdaDisposable
{
    OnDisposeManagedAction = () => Console.WriteLine("マネージド解放"),
    OnDisposeUnmanagedAction = () => Console.WriteLine("アンマネージド解放")
};

async void 回避策？

https://qiita.com/pierusan2010/items/76b7a406b3f064193c88
古い部分が多い。

この記事で使われている古い部分(2025年視点付き）

登場箇所	具体的なRx要素	コード例	2025年現在の評価
1	Observable.Create<T>(Func<IObserver<T>, CancellationToken, Task> subscribeAsync)	記事の中心	このオーバーロード自体は Rx v2.2 (2014年) で追加されたもの → 2025年では ほぼ誰も使っていない死にオーバーロード
2	Observable.Create<T>(observer => { … })	実装内部	古典的だが今でも生きてる書き方（ただしasync対応は非推奨）
3	task.ToObservable()	task.ToObservable().Subscribe(...)	2025年最大級のNGパターン → Task → IObservable 変換で無駄なスケジューラ起動＋余計な割り当てが発生 公式に「遅いからやめろ」と警告が出てるレベル
4	CompositeDisposable	return new CompositeDisposable(...)	今は Disposable.Create(() => { cts.Cancel(); subscription.Dispose(); }) が主流 CompositeDisposable自体はまだ生きてるが「重い」と言われ始めてる
5	CancellationDisposable	new CancellationDisposable(cts)	Rx公式付属のヘルパ → 2025年では ほぼ絶滅（自分で cts.Dispose() 書くのが普通）
6	IObserver<T>.OnError / OnCompleted	error => logger.WriteLine(...)	正しい使い方だが、目的（例外捕捉）が本末転倒 → async void の例外を捕捉したかっただけなのに、超重い仕組みを導入してしまった
7	Subscribe(_ => { }, error => …, () => …)	3つのデリゲート指定	典型的な「OnNext不要」パターン → 今なら Subscribe(onError: ..., onCompleted: ...) の名前付き引数で書くのが主流
8	IObservable<Unit>	ObservableExt.Create<Unit>	非同期処理の完了だけ見たい典型パターン → 2025年では Task か ValueTask をそのまま使うのが普通

ドラクエの戦闘開始時の敵モンスター名表示 #C#

内容の有用性: Unityでドラゴンクエスト風の戦闘開始メッセージ（例: 「スライム か あらわれた！」）を、専用フォント（ドラクエフォント）の制約下で正しく2行表示する方法を具体的に解説。濁点（ﾞ）を別文字で表現するフォントの特性を考慮した文字列構築ロジックを提供しており、レトロゲーム再現プロジェクトに特化した実践的なTipsとして役立つ。

C#とLINQで直積集合

LINQを使って2つの集合の**直積（Cartesian product）**を生成する方法を、九九表の出力という具体例で解説。クエリ構文（nested from）とメソッド構文（SelectMany）の両方を示しており、LINQの重要な仕組み（SelectManyが直積を実現する）を理解するのに適したサンプル。

初心者〜中級者向けの理解促進に十分役立つが深堀りがない

ローカルスコープの変数がスコープを抜ける前にガベージコレクションされる #C#

C#のローカル変数がスコープ終了前にGC対象になる現象（ReleaseビルドのJIT最適化による）を、Mutexを使った多重起動防止とファイナライザ付きオブジェクトの2つの実践的なコード例で明確に解説。

多くの開発者がハマりやすい「Debugでは動くのにReleaseで失敗する」バグの原因をピンポイントで説明しており、.NETのGC/JIT動作理解に非常に役立つ。

↦　2013年の記事だが、C#のこの挙動は現在（2026年）でも基本的に変わらず有効（JITの最適化は進化しているが、同様の注意点が必要）。

TransactSql.ScriptDomを使ってTransact-SQLのコーディング規約をチェックする

内容の有用性: JOIN後の列参照でテーブル名（エイリアス）を省略しないという実務的なコーディング規約を、MicrosoftのTransactSql.ScriptDomライブラリを使って自動チェックする方法を解説。

→　記事内に完全なC#コードがなく、GitHub参照に頼っているため、即コピーして試すハードルが少し高い。

→　現代（2026年現在）でも通用し、実務的な価値が高いままです。

オブジェクト初期化子の罠 #C#

内容の有用性: C#のオブジェクト初期化子（new MyClass { Member = ... }）を使った場合、初期化中に例外が発生すると変数代入が完了せず、usingステートメントのDisposeが呼ばれないという落とし穴を解説

→　.NET 10 でも同じ挙動になります。
これはランタイムの世代差ではなく、C# 言語仕様そのものの性質。

→　但し、最新C#では通常は ```
→　「初期化子の中に例外を投げうる処理を入れない」これだけで大半は防げます。
知らないと原因が分かりにくいという好例

NMeCabで形態素解析してみよう

内容の有用性: NMeCab（MeCabの純粋C#ポート）を.NETプロジェクトに導入し、日本語形態素解析を行う基本的な手順を解説。ダウンロードから辞書設定、シンプルなコンソールサンプルまでをカバーしており、当時（2013年）のC#開発者で日本語テキスト処理を始めたい人には実践的な入門記事として機能した。

→　MeCabは今でも使う人はいるけど、かなり少数派になってきている
NMeCabが選ばれるケース（2026年でも）
・10年前に作った社内ツールが今も動いてて、.NET Frameworkで回してるレガシー案件
・UnityでC#使ってて、外部プロセス起動したくない超軽量ケース（稀）
・「どうしてもネイティブバインディングじゃなくて純粋C#で完結させたい」というこだわり

２０２６年時点での代替

ほとんどの人が以下のどれかを使ってる：

選択肢	主な利用シーン	速度	新語対応	メンテ状況	2026年のおすすめ度
MeCab + mecab-ipadic-neologd	昔ながらの最高精度を求める人	★★★★	◎	生きてる	★★★★☆
MeCab + UniDic	現代語・書き言葉重視	★★★★	○	とても活発	★★★★★
Sudachi	辞書がモダン・分割粒度調整しやすい	★★★★★	◎	超活発（2025年も更新中）	★★★★★
Kuromoji (Java)	Elasticsearch / Solr / Java圏	★★★★	○	安定	Javaならこれ
fugashi + unidic	Pythonで一番軽く動かしたい人	★★★★★	◎	めっちゃ活発	Python民のデファクト
NMeCab	純粋な.NET / C#プロジェクトでDLL地獄回避したい人	★★★	△	ほぼメンテなし	★★☆☆☆

NUnit実行時における設定ファイルの場所

記事の内容はNUnit 2.x時点のもの

内容の有用性: NUnitでテストを実行する際のアプリ設定ファイル（app.config）の場所が、直接実行時と異なる挙動（Process Model: Default/Multiple/Separateなどによるパス違い、ユーザー設定ファイルのAppData下配置）を、観察ベースで整理・表形式でまとめている。

→　NUnitテストは今でも活発に使われている（2026年1月現在）
→ .NETのユニットテスト界隈では今でもトップクラスの選択肢の一つとして選ばれている

現在の最新NUnit（2026年時点：NUnit 4.x / NUnit 3.x後期）でも使えるのか？

→　NUnit 3.x以降（特に4.x）ではプロセスモデルやAppDomainの扱いが大きく変わったため、記事の表や詳細は古く、一部無効または異なる。

• .NET Core / .NET 5+以降: appsettings.jsonが主流で、ConfigurationManagerは非推奨（Microsoft.Extensions.Configuration使用）。app.configは互換モードでしか動作しないため、記事の現象自体が発生しにくくなっています。

• 現代の回避策（おすすめ）:

  • .nunitプロジェクトを使わない → Visual Studioのテストプロジェクトでapp.config（またはappsettings.json）をプロジェクトに追加し、出力ディレクトリにコピー（Build Action: None, Copy if newer）。
  • NUnitコンソール実行時: --configfileオプションで明示的に指定。
  • .NET Standard/Coreプロジェクト: Microsoft.Extensions.Configuration + Json/FileConfigurationで設定を読み込むのがベストプラクティス。
  • テストで設定をモック: AppSettingsを直接注入するか、TestInitializeでConfigurationBuilderを使う。

あとがき

20015年分までは続ける。

AI生成に頼るだけの 底辺Coder AI依存開発者には限界があります。学ぼう。

宣伝

WPFでVisualStudioライクなSpellCheckerを自作した話

nugetで2000ダウンロード行きました。