追記を見逃していたようです。
過去の内容に追記しても更新メールが届いたりトピックが上に上がるわけではないので返信の形で書いてもらわないと伝わりませんのでお願いします。
>*追記：たとえばCreateWindowの中にSystem::Windows::Forms::Buttonを入れたいんですけど
.NetFrameWorkはフレームワークなので部分的に使うことは不整合を起こします。
なので、環境以前に主をWindowsAPIにして従を.NetFrameWorkにすることは困難です。
これは、.NetFrameWorkを利用できるC#であろうとVB.NETであろうと変わりません。
さて、純粋なＣ言語から.NetFrameWorkを利用できる環境は今のところ存在しません。
代わりに.NetFrameWorkのC++版であるC++/CLIでCLRフォームアプリのプロジェクトを使えば.NetFrameWorkのフレームワーク記述にＣ言語的な物を混ぜることは可能ですが、先程も書いた通り主従を逆にすることは出来ません。
それとC++/CLIのCLRフォームに関してはVisualStudio2012から新規に作ることは見た目上はできなくなっていますので、将来性としてマイクロソフト自体がフェードアウトを狙っているようです。
.NetFrameWorkのＧＵＩは、C#かVBで組んでくれという意向だと思います。それに逆らうのは得策と思えませんので、何か別の方法を検討されたほうが良いと思います。
オカピーα さんが書きました:色々な意味でC言語は不遇の言語です。
言語のコンセプトの問題ですからＣ言語が悪いわけではありません。
まぁ、私も過去の資産を気にせず素早くGUIを組みたいのならC#を使うでしょうから適材適所であり何でもＣ言語で組むのは間違った選択だと思います。
C言語でもGTK+を使えばWin32APIを直接使うよりもＧＵＩが楽に組めます。つまり、面倒なものであるWin32APIを使う必然はないです。
更にC++ならＱｔなどいろいろな選択肢がありますので、環境とやりたい事のために言語を選ぶのはプログラマーとして必要なことです。