.NET в unmanaged окружении: platform invoke или что такое LPTSTR

На самом деле, работать с unmanaged-кодом приходится не много. По факту, буквально два-три случая вынудили меня изучить этот раздел .NET.

Несмотря на всю мощь фреймворка, многие узкоспециализированные задачи на нем не решаются. Например, установка integrity level (англ.) с помощью SDDL невозможна во встроенных классах безопасности .NET (попытка подать SDDL с описанием integrity level не вызывает ошибки, но не выполняет требуемых действий), поэтому приходится работать через p/invoke. Ну а COM применяется достаточно часто в больших проектах, а писать их на C# куда проще, чем на С++. Мне показалось проще один раз изучить все проблемы взаимодействия, чем учиться правильно и грамотно писать на С++.

Отмечу, что многие задачи на C# решить все-таки не получится. Например, работа с MAPI требует такой тонны рутинной работы по COM Interop (здесь фреймворк не справляется), что легче написать требуемый код на C++, обернуть его с помощью ATL в COM и заинтеропить уже получившийся объект. Получается что-то вроде Redemption, только заточенного под собственные нужды.

Нам тоже приходится много взаимодействовать с неуправляемым кодом. На это две причины: взаимодействие через COM (например, с Microsoft Office или 1C) и работа с нативными длл (последнее — на Mobile Devices через .NET CF).

С первым пунктом всё должно быть очевидно — лёгкость разработки на .NET приводит к экономии времени, которая в несколько раз превышает затраты на исследования COM Interop.

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