YUBAЗаморочился связью между прогами на одном компе - вроде сокеты самое оно.
Как я с этим всем намучился в свое время.
Каждый к чему-то привык это ясно.
Имхо, самое оно это mailslot-ы с придуманными тобой уникальными именами. Нужно общение в 2 стороны - значит в каждой проге по mailslot - и общение по независимым "каналам". Положил msg и забыл.
Еще можно слать SendMessage (COPYDATA) между окнами - но в большинстве случаев неудобно, надо ждать обработки на другой стороне и не работает если NT Service <> User , от этого почти отказался.
Пайпы - зло.
Named Shared Memory - вроде тоже неплохо для определенных целей - как счас выяснил.
Events -тоже хорошо, если просто "стукануть".
И лучше сразу все эти вещи через API делать.

YUBAНо когда оно ANSI C, в шарп не больно то мигрируешь.
Во первых, не обязательно ANSI (functionA), но где это надо всегда дублируется Unicode (functionW).
И если например в VB6 я исторически почти всегда использовал ANSI (functionA), то в .Net стал строго придерживаться Unicode (functionW).

Во вторых, независимо от того используешь ты A или W сообщение что ты передаешь может быть в любой кодировке, да хоть бы UTF8 которая "родная" для .Net, ф-ций WriteFile и ReadFile и т.п. A/W кстати не существует, речь обычно идет о массиве байтов, а как ты это кодируешь/декодируешь твое личное дело (штатных инструментов кодирования в .Net на эту тему хватает), главное чтобы оба конца адекватно понимали в какой одной кодировке они работают. Например в случае если у меня 2 .Net приложения, я использую utf8, а если одно из приложений C/C++ то тут уж кодирую ANSI либо Unicode==UTF16 в зависимости от того скомпилировано ли си в Юникоде или ANSI. Но в только что осиленном примере с Named Shared Memory
20204881 (под спойлером готовый модуль) почему-то использовал Encoding.Unicode хотя у меня 2 .Net приложения - почему-то так захотелось, видимо из соображений что это может пригодиться для пары C/C++ <> .Net. Хотя объясню, только недавно напоролся, все ф-ции для Mailslot у меня были заточены под ANSI и utf8, а сейчас мне понадобилась пара C++(Unicode) <> .Net, и мне эти ф-ции пришлось дублировать для Unicode.

YUBAНесколько h-файлов в с# - эт не для белого человека.))
Вообще-то API ф-ции в .Net как и в VB6 декларируются ручками с четким указанием системных dll, в отличии от C, где включаешь h. файлы заголовков из всяких там SDK/DDK (что кстати часто приводит к конфликтам из-за многообразия версий этих самых SDK/DDK, тасовать include/src ссылки в свойствах C++ проекта - особенно чужого и большого, оч. неблагодарное дело). И вот пока делаешь (в .Net/VB6) эту "черную" работу, выписывая ручками все эти Declare, константы и структуры, параллельно читая документацию, начинаешь эти самые API оч. хорошо понимать и становишься "белым" человеком.

Изопропилна http://pinvoke.net достаточно прототипов для начал работы
Я вот лично туда посматриваю, но за чистую монету никогда не беру.
Очень любят там всякие U Int32 прописывать и <DllImport в стиле C# писать, что как раз не сильно надо и Int32 обычно везде хватает.
А вот с IntPtr и (U)Int32 там как раз часто путаница, а вот это как раз на x64 очень даже стреляет, и лучше себе таких мин изначально не закладывать. Поэтому предпочитаю выписывать ручками и пережевывая каждый параметр, глядя больше в MSDN (Windows) а не в pinvoke.
Еще на счет IntPtr / ByRef <structure> обычно думать приходится, потому как в разных случаях по разному удобней (пятиэтажная <structure> возможно никогда и не понадобится).