Уж и не знаю куда писать, то-ли в NET раздел, то-ли в С++.)
Пишу IP-клиента на С++ в управляемом коде под System::Net::Sockets. На C# все отработал, теперь пероношу класс клиента в С++.
Не понимаю, что происходит, и как с этим бороться?

Про байт потом, а остальные пишут примерно одно и то же - Ошибка C3076 cIPClient::ipEndPoint: нельзя внедрить экземпляр ссылочного типа "System::Net::IPEndPoint" в собственный тип.
В справке -"экземпляр":
нельзя внедрить экземпляр ссылочного типа "тип" в собственный тип
Машинный тип не может содержать экземпляр типа CLR.
Что с этим делать?
Код перенесен из С# и понемногу правится под срр.

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

Вроде нашлось решение:
Теперь, чем заменить тип byte[] bytes;?

Пётр Седов,
Спасибо, уже сам дошел. Но там дальше пока не пойму. Ругается пока только и на array<Byte>^ bytes, и на cli::array<byte>^ bytes;

Неожиданно скомпилировалось с
Не понял.

Следующий затык. На С# было:


Как это на с++ сказать? надо аналогичный массив определить. С array(Byte) что-то не идет.
1-й затык с переменной msg. Дальше вроде так:

BarloneА зачем? Из managed C++ можно вызывать код, написанный на C#
http://www.tangiblesoftwaresolutions.com/product_details/csharp_to_cplusplus_converter_details.html А зачем?, если можно сразу на управляемом С++ писать.)
Наверно это кому-то действительно. Ну а мне интересно разобраться в технологии.

IP-клиента на управляемом С++ сделал. Создал консольное приложение Win32, вызываю из него Net класс. Класс создается и присоединяется к серверу. Однако, эту конструкцию победить не могу:
Метод определен как
Пишет:
. Код консоли неуправляемый. Не знаю как быть.

В общем, все получилось. Преобразование сторок std::string в System::String и обратно было последней задачей.
Преобразование в System::String
И преобразование обратно:
MSDN, естественно.
К сожалению, в MSDN полно ошибок или очепаток, потому первые найденные решения не работали, и выдавали ошибки. Но, приведенные, уже правильные.
В общем, NET-код нормально работает совместно с неуправляемым, в данном случае NET IP-клиент с неуправляемой консолью. Никаких особых проблем не отмечено - только первый раз трудно, потом привыкаешь.))

При отладке клиент-сервера возникла следующая проблема. Для проверки восстановления связи клиент или сервер принудительно закрываются, при этом незакрытый клиент(сервер) еще пытаются работать до возникновения Exception, и далее сокет уничтожается, создается вновь и пытается установить связь.
После запуска клиента(сервера) они нормально соединяются, однако вся инфа, которую они пытались передавать уже после разрыва связи до возникновения Exception конкатенируется с новой, и, в итоге, одна из сторон в первом сообщении после коннекта получает полный бред.
Вопрос в том, где и как почистить этот буфер передачи или, м.б. приема, перед повторным установлением связи?
Код уничтожения сокета:
Лучше бы Despose(), но на него выдает ошибку и просит вызвать деструктор.

Я где-то читал, и даже недавно писал на форуме, что NET, это не более чем обертка над обычным нативным кодом. За весь NET не скажу, а большинстве своем это так.
Кажется Изопропил в этом сильно усомнился. Я, вслед за ним, тоже стал сомневаться.
Однако, сделав смешанную прогу на нативной и NET функциональности, убедился, что это действительно так.
Когда я стал обвешивать прjграмму блоками try-catch, моделировать Exceptions, и подробно смотреть точки останова, то открывались h-файлы с точками останова, в которых ничего даже близкого к Framework не было. И даже если смотреть сами исключения, то объясняются они не в рамках NET, а в рамках библиотек Виндовс или MFC.
Конечно безумие, писать на С++ программы на смешанном коде, где переменные вначале преобразуются (или самому необходимо это сделать) к NET формату, затем, в глубинах NET, опять преобразуются к формату С++, а на выходе мы имеем опять тот же самый но обратный процесс.
Безусловно это некий дурдом, но оч удобный.) Я было попробовал тоже самой сделать на MFC и WinAPI, однако это требует значительно больших усилий как по времени, так и просто по количеству кода.
В общем, если мелкосекунды не волнуют, то настоятельно рекомендую.

Изопропил, А откуда там при Exceptions вылезают MFC-хидеры? Да и в хелпах по номерам исключений вылезают либо Win библиотеки, либо MFC. Как это можно объяснить иначе?
Имхо, разумно предположить, что MS не все с нуля делало, а использовало предыдущие наработки, включая и MFC. Хотя, я и не утверждал, что NET построен на MFC, но то, что использует, имхо, очевидно.

Изопропила то что F1 частенько в небо кажет - фактЭт точно. Exception есть, а раздела нет.))

SiemarglОчевидна только твоя безграмотность.Вернейший способ быть обманутым, считать себя умнее других. (народная мудрость.))