.NET Frameworkと少しばかりのWin32 APIの組み合わせでできています。ちょっぴりややこしい部分もありますが、根気さえ続けば解析できると思います。気が向けば、お好きなように改造してください。
変数の意味や技術的な概要（そんな大げさなものじゃないけど）については、コード中に注釈として書いてあるので、参考にしてください（なれば良いのですが…）。
ソリューションを開く
ソースフォルダを配布するにあたって、".vs","bin","obj"フォルダを削除しています。
そのため、Visual Studioでソリューションを開くと、ユーザーコントロールを使用しているフォームにエラーが出てしまいます。一旦ビルドして、開き直してみてください。これで正常になると思います。
二重起動の禁止
多重起動してメニューを使い分けるのもありかと思ったのですが、結局シンプルに二重起動禁止に落ち着きました。
と言うのも、実行ファイルは別々のフォルダに存在しなければならない（ランチメニュー登録フォルダ・設定ファイルの重複回避），異なる実行ファイル名でなければならない（スタートアップ用ショートカット名の重複回避）など、なにかと面倒過ぎるのです。そこまでしなくてもメニュー階層を分ければ済むじゃないかと考えて見送りました（タスクトレイのアイコンやランチメニュー登録フォルダを変更できるのは、その名残だったりします）。
多重起動というアプローチでは駄目だとハッキリしたので、再挑戦するとしたらタスクトレイにアイコンを多重登録する手法になるでしょう（なぜ最初からそう考えなかった…）。
自動起動
【システムメニュー】-[自動起動]は、Windowsのスタートアップ フォルダに実行ファイルと同名のショートカットがあるかどうかで、チェックマークと動作を切り替えています。なので、ショートカット名の都合等で正しく認識できない場合があります。ちなみに、【システムメニュー】を開く時に登録状況を確認しています。
設定ファイル
設定ファイルには、"SystemSetting.xml"と"KeySetting.xml"があります。
これらは、作業フォルダ（カレントディレクトリ）に作成されます。作業フォルダは、通常、実行ファイルと同じフォルダです。実行ファイルのショートカットアイコンを作成し、その[作業フォルダ]欄を変更することで、保存先を変更することが可能です。
"SystemSetting.xml"は、システムに関する設定内容が保存されます。
設定コンソールのOKボタンをクリックしたタイミングで、変更の有無にかかわらず作成（上書き）されます。
このファイルには、設定コンソールからは変更できない項目が存在します。詳細は、“資料”⇒“表1”の通りです。
"KeySetting.xml"は、裏メニューで使用する鍵が保存されます。
鍵を変更して設定コンソールのOKボタンで確定したときに作成（上書き）されます。
ファイルには、『隠しファイル（不可視属性）』が設定されます。ただ、暗号化・難読化は難しそうだし、裏アイテムも単なる隠しファイルで鍵だけ厳重に守ってもあまり意味がないので、平文で書き出しています。よって、誰にでも見られますので、絶対に過信しないでください。
両ファイルとも、XML形式のテキストファイルなので、テキストエディタで変更可能です。ただし、大文字と小文字が区別されるので十分注意してください。システムメニューを経由せずに変更された内容は、【システムメニュー】-[設定]を選択し[適用]ボタン（設定ファイルの更新日時が変わっていたり、ファイルが削除または作成されていたりすると表示される）をクリックすれば反映されます。
前述の通り、これらのファイルは起動しただけでは作成されないので（デフォルト値と同じ値を、ファイルから読み込むのはなんとなく無駄な感じがして…）、直接書き換える場合は、予め作成しておく必要があります。
設定ファイルが保存される時に、旧ファイルのバックアップを残します。"*.old"はリビジョン更新前、"*.bak"は変更前のファイルです。
タスクトレイアイコンの上にマウスカーソルが乗ったことは、NotifyIcon.MouseMoveイベントで検知しています。
ところが、タスクトレイにアイコンを登録したときにも、このイベントが発生することがあるようで、ホバー展開に失敗する事態が発生していました。
しかし、マウスカーソルがタスクトレイアイコンの上に乗っているのかを知る術がありません。そこで、起動後初のNotifyIcon.MouseMoveイベントを無視するようにしました。
この挙動は、設定ファイルの<初回イベント無視>（“資料”⇒“表1”参照）で制御できます。
本作では、【ランチメニュー】をマウスカーソルのホバーや左クリックで展開しようと目論みました。
【ランチメニュー】の正体は、タスクトレイアイコンに登録されたコンテキストメニュー（【ランチメニュー】と【システムメニュー】を適宜差し替えている）なのですが、右クリック以外で展開するとなると、自前で何とかしなければなりません。そこで、下に記す3つの手法を組み込みました。なぜ、1つに絞れないのかというと、そこには何ともスッキリしない事情が横たわっているのです。
最初に試みた手法が、『メソッド呼出』です。
単純にコンテキストメニューの展開機能（《ToolStripDropDown.Show》メソッド）を呼び出します。このメソッドを呼べば、確実に開きます。反面、タスクバーに重ねられなかったり、メニュー以外をクリックしても閉じられなかったり、キー操作を受け付けなかったりと、なぜかコンテキストメニューとしての普段通りの振る舞いをしてくれません。
『メソッド呼出』の症状を解消すべく、ネットを彷徨って見つけてきた手法が、『メソッド抽出』です。（“参考・引用文献／拝借物”⇒“リファレンス／サンプル”参照）
これは、タスクトレイアイコン（《NotifyIcon》）が（内部に？）持っている『自身に登録されたコンテキストメニューを開く機能（メソッド）』を叩く裏技的（？）なテクニックのようです（作者自身よく解っていません）。掲載元の解説には「メニュー以外のクリックで閉じられる」と謳われていますが、実際のところ100%とはいかないようです。
そんな『メソッド抽出』ですが『自動撤収』を組合せることでお茶を濁せたし、怪しい振る舞いもOSあるいは.NETの問題だとすれば作者の関知する所ではない（いずれ解消するかも）と、放ってきました。ところが、環境がXP→8.1→10と移り変わるにつれ、閉じない頻度が増したように感じたり、ホバー展開に失敗するようになったりと、何だか雲行きが怪しくなる一方です。
こうなると、こちら側で抜本的解決策を探らねばダメかもと、既知の諸症状から仮説を立ててみました。「タスクトレイアイコンまたはコンテキストメニューがアクティブになっていないのが原因？」→「OSによるフォーカス捌きがこちらの思惑と異なっている？」→「展開のトリガーとしてクリックが存在しないから？」→「クリックさえ伴えば万事解決！」するのではないかと。そう睨んで引っ張り出してきた奥の手が、『疑似右クリック』です。
少々力業な感は否めませんが、マウス操作やキーボード操作を再現できるWin32 APIの《SendInput》を使って、『タスクトレイアイコンを右クリックした』という状況を作り出します。そんなこんなで慣れない（扱いづらい）APIに四苦八苦した成果やいかに…やはり、厳密には実際のマウスのクリックとはどこか違うようで、芳しくありませんでした。
これまでの制作過程で、上に挙げた症状が現れる場面をいくつか発見しました。
例えば、“タスクマネージャーやノートンのウィンドウがアクティブな時”や“ノートンのタスクトレイアイコンのコンテキストメニューが表示されている時”にホバー展開すると、『メソッド抽出』では閉じられなくて、『疑似右クリック』では開かない症状が見られました。
また、スタート画面を開いたり閉じたりした直後にタスクトレイアイコンのコンテキストメニューを開くと、タスクバーの裏側に表示されて、閉じられずキー操作も受け付けない状態になります。これに関しては、他のアプリケーションでも同様なので、Windows側の問題だと思います。
これらの条件に当てはまらない不確実な発症もあり、なかなか尻尾を掴めません。
幾多の手を講じようとも根治できぬなら、せめて粗が目立たないようにせねばと、あの手この手で取り繕っておきました。
閉じない問題を回避するために、ランチメニューのトップに[閉じる]を設けました。でも、「いちいちマウスで選択するのは美しくない！」ので、『自動撤収』を編み出しました。
開かない問題に対しては、一定時間後に開いていなかったらやり直す処理を加えました。この時、エラーメッセージを出してクリックしてもらうことで確実にフォーカスを奪取します。フォーカスさえ手中にできれば、もう思うが儘です。
更に、動作検証も考えて、ランチメニューの開き方毎にどの手法を採るか決める項目を、設定ファイルに追加しました（“資料”⇒“表1”参照）。デフォルトでは、ホバーには『疑似右クリック』、それ以外は『メソッド抽出』としましたが、この2つの差に確たるものは何もありません。ただ感覚的に、『疑似右クリック』の方が不確実な発症が少ない気がしただけです。『メソッド呼出』は、さすがに苦しいでしょう。
【ランチメニュー】は、登録内容を読み込み構築しながら展開するので、それなりの時間を要します。そのため、構築中にメニューを操作されてしまうと都合が悪いです。
具体的には、あるドロップダウンメニューを構築中に、他の格納アイテムをポイントすると、複数のドロップダウンメニューが表示されてしまいます。また、構築中に実行アイテムをクリックすると、表示済みのメニューは消えて、構築中だったドロップダウンメニューだけが取り残されてしまいます。
これは、ドロップダウンメニューの準備処理（《DropDownOpening》イベントを発生する）部分と表示処理（《DropDownOpened》イベントを発生する）部分の間に、他のイベントが割り込んでしまうためだと思います。
しかし、この問題を回避する方法が思いつきません。ドロップダウンメニューの展開やメニュー項目の選択をキャンセルできれば解決しそうですが、そのような機能は用意されていないみたいです（《ToolStripMenuItem.DropDown.Opening》イベントを使えば何かできそうだけど、上手く行かなかった）。とは言え、メニューが機能しなくなるようなことはないので、今の所諦めています。
残骸が残ってしまった場合は、メニューを開き直すか、項目を選択すれば消えます。
【ランチメニュー】の複数層一括構築は、“再帰呼び出し処理”で行っています。
再帰呼び出し処理は、簡単にツリー構造を読み込めるため便利なのですが、階層が深くなり過ぎるとエラー（StackOverflowException）が出てしまいます。
どのくらいで駄目なのか不明な（知らない）上に、マイクロソフトの説明によると「.NET Framework Version 2.0 以降は、StackOverflowException オブジェクトを、try-catch ブロックによってキャッチすることはできません。」ということなので、設定ファイルに<再帰呼出限界深度>を設けて適当な値に制限してしまうことにしました。したがって、この値が、一括構築深度機能の上限値となります。
<再帰呼出限界深度>のデフォルト値は、10階層にしていますが、これだけあればとりあえず十分だろうし、この程度ならエラーにもならないと思います（ちゃんとテストしていません、ごめんなさい）。エラーにならない範囲で、お好みの値に書き換えてください。
【ランチメニュー】に表示するアイコンは、《System.Drawing.Icon.ExtractAssociatedIcon》メソッドで取得しています。（“参考・引用文献／拝借物”⇒“リファレンス／サンプル”参照）
しかし、このメソッドには弱点があります。
1つ目は、32*32ドットの画像（大きいアイコン）しか取得できないことです。16*16ドット（小さいアイコン）が欲しいので、試しに《New System.Drawing.Icon(～取得アイコン～,16,16)》としてもくれません。なので、縮小して使う破目になるのですが、補間が働くとは言え潰れてしまいます（CRTから液晶に代わったからか多少は見られるようになったけど）。でも、ただ潰したので勿体無いので（あぁ貧乏性）、アイコンを大きくする機能も設けました。
2つ目は、フォルダのアイコンを取得できないことです。メニューは階層構造なので、アイコンがなくても格納アイテムであるのは判るのですが。より区別し易いようにと着色しておきました。
Win32 APIの《SHGetFileInfo》関数ならどちらも取得できるみたいなのですが、遅いらしいし（画像の縮小だってリソースを喰うだろうに）、せっかくメソッドを用意してくれているので…（メソッド名からしてAPIの《ExtractAssociatedIcon》関数をラップしているのかも）。
ランチメニューに並ぶ実行アイテムのソート方法として『自然順』を選択できます。これで、エクスプローラの名前順と同じ並びになると思います。
この順序判定には、Win32 APIの《StrCmpLogicalW》関数を使用していますが、ネットの情報によると「推移的ではない（『A<B 且つ B<C である』なら『Cは最大である』と推定してくれない？）ため、無限ループに陥る可能性がある」とされています。
しかし、例え比較式がそうだとしても、全ての文字には一意のコードが割り振られている（はずだよね？）わけで、矛盾を来す事態など起こり得るのか…作者には想像できません。
特に対処法もないので、何もせずそのまま使用しています。とはいえ、素人考えなどあてになりません。万が一『応答なし』になってしまう場合は、他のソート方法に切り替えてください。
ランチメニューの土台となるコントロールに、《ContextMenuStip》から派生したユーザーコントロールを使用しています。マウスホイール・PageUp/PageDownキー・アクセスキー使用時のスクロールを改善しています。
ランチメニューへの登録
アイテムの登録機能を自前で用意するのは面倒臭いので、エクスプローラに丸投げしました（Windowsユーザーで使えないなんて極少数でしょうし、ネットで簡単に得られる知識で、覚えて損もないですから）。
どうしても登録機能が欲しいなら、作ってみてはいかがでしょうか。
ショートカットの作成方法は、後述の“参考・引用文献／拝借物”⇒“リファレンス／サンプル”参照に記載したサイトで紹介されています。ただし、DOBON.NETさんによると「WSHでは、フォルダのショートカットが作成できない」そうなので、少々ハードルが高いかもしれません。
あるいは、コマンドプロンプトで「rundll32 appwiz.cpl,NewLinkHere ～path～」（"～path～"にショートカットアイコンの作成場所を記入）を実行すれば、エクスプローラの[新規作成]-[ショートカット]と同じウィザードを呼び出せるという情報もあるので、もしかしたらこっちの方が使えるかも知れません。（と思って、Win8.1で《Interaction.Shell》メソッドを使って試作してみたけれど、呼び出すことができませんでした。）
結局の所、格納アイテムや複数登録することも考えるとエクスプローラが効率的だろうし、技術的にも機能的にも現実装が実用的な気がします。
登録内容の変化は、《FileSystemWatcher》クラスで監視しています。変化を感知すれば、ランチメニューの当該箇所を再構築するようにフラグを立てます。ただし、監視対照はあくまでも登録内容なので、登録フォルダ自体の改変（名前の変更など）には対応できません。また、なにぶん初めて使う機能であり、何らかの問題で上手く反応しない事態が発生するかもしれません。
そんな万一の備えとして、【システムメニュー】に[ランチメニュー再構築]項目を忍ばせておきました。
タスクトレイアイコン
タスクトレイにちゃんとアイコンが表示されているかを知る術を持っていません（ゴメンなさい）。なので、タスクトレイアイコンにフォーカスがある状態でAlt+F4キーが押されたり、アイコン登録時のタイムアウト等で、アイコンが無い事態に陥ってしまうと二進も三進も行きません。タスクマネージャから直接終了するか、PCを再起動して復旧してください。
