すでに何度か「C++とC#は基本的に別物で、C(++)文法で書かれる（Garvage collection－以下GC－のある高級言語の）Visual Basicみたい」と書きましたが、益々その感を強めています。
今までC#を学習してきて引っ掛かりを覚えた所とかをランダムに上げていくと．．．
１．Stream、Serialize and que
リソース関係で中核となるResourceManager、ResourceSet、ResourceWriter、ResourceReader辺りをMicrosoft Docで眺め、"GetObject"（注）と"GetStream"が目に付きます。（一度GetObjectでbitmapを読もうとして読めず、Streamにして読んだら読めたから印象が深い。）
（注）C#で「リソース」という場合、C++プログラマーがすぐに思い浮かぶ「（正にBCCFormで扱ってきた、メニュー、ダイアログやコントロール等の）Win32リソース」の概念とは全く違うことを肝に銘じる必要があります。あるサイトではC#の「リソースの種類」として「文字列、イメージ、アイコン、オーディオ、ファイル（text、binary）その他」に区分していましたが、（直球ど真ん中で「リソースの種類」で言及はしていないものの）Microsoftは「アプリ リソースとリソース管理システム」の中で「...
アプリの文字列、画像、ファイル リソース...アプリ リソースには、次の 2 種類があります。
ファイル リソースは、．．．埋め込みリソースは、」と書いております。
Microsoftは昔からMFCの中で"Serialize"をよく使っており、「様々な複雑なデータも順に一直線のデータにすること（注）」だと理解しており、その理由（必要性）は移動、複写、参照等データ処理の為です。
注：「シリアライズとは、複数の要素を一列に並べる操作や処理のこと。単にシリアライズといった場合には、プログラムの実行状態や複雑なデータ構造などを一つの文字列やバイト列で表現する「直列化」を指すことが多い。」（IT用語辞典）
で、データ処理となると"FILO（First-In、Last-Out）"（スタック、stackですね）や"FIFO（First-In、Last-Out）"（キュー、queですね）が思い浮かびますが、将にStreamとは大量のデータを待ち行列（que）に均して直線化すること、されたもの、と理解しており、まぁ、間違いはないでしょう。
２．Object、Field、Property、Method
別に碌に詳しくないOOP（「オブジェクト指向プログラミング（Object Oriented Programing）」）の講釈をたれようとは思いませんが、C++をやっているとObjectが「設計図」としてのクラス（それを「実体」化させるとインスタンス）、そのObjectが持つProertyがメンバー変数等（Propertyは財産、資産の意味だけど、resources－資源の概念とは違います）、そのObjectがする仕事（動作）のMethodがメンバー関数として覚えていましたので、Propertyが「Field（データベース用語ですね－C++ではメンバー変数）にアクセス（get;、set;）するクラス」であることを知り、感慨にふけったものです。
３．CLR、CIL、CLI、CTS、CLS
このうちいくつ分かりますか？（「なんのこっちゃ？」と感じるのが普通の人です。）
これらはC#とは直接関係がありませんが、その背景となる現在のMicrosoft（およびWindows）の「根っこ」と「構造」を理解する為に必要ですね。私の理解だと↓のようになります。
共通言語ランタイム（CLR－Common Language Runtime）→やはりC#とVBは同じ実行基盤（例外処理、ガーベジコレクション、スレッド管理などを共通とするDLL）で動作していたようです。これがC#やVBの共通データ型仕様（CTS－Common Type System/共通型システム）や共通中間言語（CIL：Common Intermediate Language→異なるプログラミング言語に共通の仕様（CLS－Common Language Specification/共通言語仕様）に基づく）で書かれたプログラムを、起動時にその環境（OS）用にコンパイルして実行するようです。
↑
CLI (Common Language Infrastructure/共通言語基盤)→共通データ型仕様（CTS－Common Type System/共通型システム）、共通プログラミング言語仕様（CLS－Common Language Specification/共通言語仕様）に基づくそうです。
これらによって".NETは、"異なるプログラミング言語のみならず、異なるハードウェアやOSを超えてプログラムを共有することが可能になるわけです。（出典）
４．Assembly
C++だとCompile、Linkして生成する「（実行）プログラム」といいそうな、データと実行コードの集合体をC#ではこう呼ぶような。（例：GetExecutingAssembly()でEXEファイルかDLLファイルかを識別する、等）じゃぁ、「Assemblyを作り出すのはAssemblerじゃないの？」と突っ込みたくなるけど、それは大昔ニーモニック（mnemonic）を機械語にするアッセンブラーがあったのでいまだにコンパイラー、リンカーと呼んでいますね。あー、混乱する。
５．（余談）CloseとDispose
CやC++というアッセンブラー的にメモリー管理をプログラマーがやらなくてはならない低級言語を経験せずに、C#という高級言語から入った方が「CloseとDisposeとはどう違うのか？」で、これとかあれとか結構論争しているのを見るのも新鮮です。この論争の原因は、以下のような状況の為かもしれません。
・CやC++の言語仕様に則ったC#ですが、GCがあるので（メモリーリークという恐怖を背景にした）「newしたら必ずdelete」「openしたらなからずclose」「createしたら必ずdelete」等の「お片づけ」作法をしつけられていない"spoiled children"という印象を受けます。
・GCもすべてMicrosoftが完璧にやってくれるのならよいのですが、実行基盤であるCLR（↑参照）が管理するプログラム資源（リソース）は危なくなったらGCをかけて甘やかす一方、ユーザー管理にゆだねなければならない「ファイル」「リソース」関係は「自分でお片づけしなさいっ！」と突き放すので、「Managed resources、Unmanaged Resourcesってなに？（要すれば、CLRが自動的にGCしてくれるリソース、そうでないリソース）」と混乱し、Win32 APIをいじったことがない人には「CloseとDisposeってどう違うの？」ということになります。（Open-Closeはデータへのアクセス可否、Dispose（廃棄）はメモリーを含むプログラミング資源の開放<delete－削除、release－解放、destroy－破壊等の用語がWin32 APIでも混在していますが．．．>）
・その混乱を助長するようにMicrosoftが提供するメソッドでCloseの中にDisposeがj入っていたり、Disposeの中にCloseが入っていたりすることもあるようです。
私なんかですと「メモリーリークしないように、コンピューターで遊んだ後は、ちゃんとお片づけすればよいだけ」と感じますが、どうでしょう？
閑話休題。
MSCompAssに続く、C#用の外部リソース（*.resx、*.resources）、埋め込みリソース（*.resources－*.resxも埋め込めますが、テキストファイルを埋め込むよりはバイナリーの方がサイズが小さいので実質的に*.resources一本やりでよいのでは？）を作成するツールのスケルトンは完成していますが、未だ入出力管理仕様が決まっていません。
その理由は以下の通り。
（１）リソースの種類は、実質GetStringかGetObjectしかなく（ローランド風に）「俺（string）か、俺以外」しかない現状です。（注）
注：Win32リソースのようにDIALOG、MENU,BITMAP、ICON等の区分はなく、基本「一本化」されていますが、文字列（string）だけはUnicodeなので「カルチャ（注の注）」という要素があり、ローランドになったように思えます。
注の注：「カルチャ」とは「軽茶」ではなく、Cultureのこと（理科系の人は「ー」を使いません！）で、C++では"locale"といってました。これも↑のネタにしたかったですね。
（２）したがって、テキストファイル、（画像を含む）バイナリーファイル等ファイル系は皆シリアライズしてストリームにしてもよいのですが、それを受け入れるときにBitmap、Icon、Byte等「異なる器を用意する」必要があるので「読む」際にどうするか？
（３）「書く」際は皆AddResourceでよいのですが、その対象をGetString、GetObject、FromStreamの区分があり得るので、これはどう判断すべきか？
（４）そもそもリソース周りはResourceManager、ResourceSet、ResouceReader、ResourceWriterｍの4役で仕切ることでよいと思うのですが、これらが必ずしも排他的な関係ではないので、相互に役割がどう関係づけられるのか、を整理しないといけないのではないか？と考えています。
まぁ、これができちゃうともうやることがなくなるので楽しい「おもちゃ」としてゆっくりと作りましょう。