Как сделать вообще понятно: компилируем, потом - ildasm, потом руками редактируем, потом ilasm. Пока это мелкий проект (небольшая DLL), все ОК. Есть еще утилиты, кот автоматом это делают. А что делать когда большой проект с ЕХЕ и прочим? Сразу как-то можно без танцев с бубном?

"Есть многое на свете, друг Горацио, что и не сразу в голову придет."
М. Твен "Приключения Геккельбери Финна"

Изопропил,
Надо в экзешнике С# изобразить нечто функционально аналогичное

не заморачиваясь написанием DLL и всяческих оберток. Хотя, в принципе, можно и DLL на С#, но с такой функциональностью. Но лучше прямо из С# экзешника. И при этом избежать стадии сборка ->ildasm -> редактирование -> ilasm, а автоматом из VS.
PS С импортом все ясно.
PS2 MSDN все больше про COM взаимодействие.

Unmanaged Exports (DllExport for .Net) 1.2.7 но это сторонний компилятор c авторедактированием. Не VS.

Еще одно решение найденное в неожиданном месте - Область применения:Excel 2013 | Office 2013 | Visual Studio
Разработка библиотек DLL
Вызывает некоторые сомнения - не ошибка ли это, т.к. повсеместно в инете экспорт из С# в стиле соглашения о вызовах WINAPI / __stdcall решается оч сложно, даже в материалах MSDN. Например это - Exporting functions in C#/VB.NET to native code

Изопропилгде там решение? там просто опечатки с++ => c#Да уже понял, там и написано, что, видимо, ошибка.
ИзопропилYUBAНадо в экзешнике С# изобразить нечто функционально аналогичное
что ты из экзешника экспортить собрался?А почему нет? Из обычных экзешников было можно, и называлось DLL-EXE. Сталкивался с такими. Как делаются не в курсе, в С++ уже давно не работаю, со времен Борланда 5.
Если нельзя, то, тоже написал - и ладно, можно и DLL, но только на C#. Из ДЛЛ по любому должны функции из С#.exe вызываться. Если можно без доп надстроек обойтись, то неплохо бы было.

Изопропилне понял, при чём здесь с++Тогда для приложения я не стал бы использовать NET, и все решалось бы достаточно просто.

Алексей КYUBA, Exposing .NET Framework Components to COM чем не устраивает?Мне не нужен СОМ или WinRT. Мне нужны экспорт функции в стиле WINAPI из NET.
Уже писал, что такие решения есть:
1.редактирование декомпила - пишешь некую абракадабру не понимая что делаешь. Для экземплов это возможно. В реале уже надо понимать что делаешь.,
2. Сторонний компилятор - непонятны границы применимости. И непонятно как отлаживаться.
Задача - найти какое-то решение непосредственно из VS.

ИзопропилYUBA,
у тебя весь проект на c# или как?У меня вообще пока ничего нет.) Будет на С#. Частично С++ - есть документация, экэемплы и h-файлы. Консольное приложение С++ должно цепляться к экспорт функциям С#. Как-то так мыслится.

ИзопропилYUBAЧастично С++
откуда требование?
или просто "так захотелось" ?Я же сказал - документация и все остальное С++. Копать вглубь нет никакого желания и необходимости. Потому консоль на С++ и уходим в С-шарп.
Чтобы было понятней - на консоли все заканчивается - дальше железо.

Изопропилну и пишите всё на с++ , тем более, что GUI не нужен. Весь GUI, обработка и пр. планируется на шарпе. считайте консоль СРР - драйвером.

Консоль, по определению, экзешник и не может быть ничем иным. Устанавливает связь и общается с железом по его протоколам. Функционально это и есть драйвер. Цепляем к нему dllimport и все наше. и больше ничего не нужно. Осталось к этому прицепиться. Я уже писал, что можно сразу срр приложение делать, но не вариант, в этом случае.))

ИзопропилYUBAКонсоль, по определению, экзешник и не может быть ничем иным
слабосвязанный набор слов
имеются с++ исходники консольного приложения, которое общается с железкой?Это как вам угодно.)) Я сказал то, что хотел сказать.
Имеются экземплы и даже частично работают. Остальное h и С-файлы.

Изопропилно вас не поняли.Хорошо, по другому. Коннект с железом осуществляется из работающего приложения, т.е. из экзешника.Ничего другого явно не предлагается. Имеются также доки C-API взаимодействия, на уровне - коннект, дисконнект и пр.
Управление и связь через 232 или 485 и сеть. Передача данных только сеть. Конфигурацию можно частично смотреть и управлять через Терминал, аналогично модему, типа АТ-команд.
Осталось соединить это с С#.
Вопрос такой, можно ли на С++ сочетать куски управляемого (NET) и неуправляемого кода в одном проекте?

Пока не знаю что это, но не исключено что полезно.
Разработка → CXXI: Мост между мирами C# и C++

Изопропил, уже все изложено в первых 3-4-х постах. Одно из решений там-же и написано. Остальные посты можно удалить за ненадобностью.
Допустим, у нас есть самописная нативная ДЛЛ в стиле WINAPI, в кот идут данные.Надо средствами исключительно VS передать их в NET не усложняя уже имеющееся решение.
Все - нет никакой конфигурации системы, железа и пр. Забыли.
2-й вопрос: Возможен ли callback из нативной ДЛЛ в NET приложение?
Да, Терминал - стандартная программа для связи с RS232. До Вин ХР включительно был стандартной программой в Виндах.

Roman Mejtesвообще само понятие терминала подразумевает то, что он имеет ввод и вывод, аля stdin\stdout через который и осуществляется работа с ним. потому он и терминал. Автор либо называет какую то поделку терминалом, которым она не является, либо пытается работать с терминалом через задний проходУмник.)) Прохожий? -Проходи.

Владимир2012, Уже проехали, там ошибка, и вместо С+ в экземплах С#.

В общем, ушел на СОМ - в итоге получается проще. Вот чего не нашел, так как в СОМ организуются события, и как оформляется их перехват в приложении. Когда есть документация перехватить без проблем, а вот самописный - черт его знает.