Комментарии 10
Обычно для преобразования используется утилита tlbimp.exe, но по умолчанию данная утилита ожидает что вы будете генерировать исключения вместо возврата HRESULT. Для преодоления этой проблемы
А почему исключения вместо HRESULT — это проблема?
Второй параметр который необходим для правильной сборки это CopyLocalLockFileAssemblies, таким образом все зависимости будут находиться в выходном каталоге и библиотека сможет спокойно к ним обратится.
Или же можно использовать команду publish вместо build, и получить нужный результат безо всяких параметров.
Если все равно без плюсов не вышло, зачем вообще весь огород с .Net городить? Ну т.е. как фокус интересно, но каков практический смысл?
Удобство и интеграция с существующим кодом. Никто не будет всё приложение на С++ переписывать ради одной фичи. На .NET можно быстро и без боли реализовать почти что угодно в отличие от неудобного С++.
Ну и за PoC автору спасибо, сам эту тему тыкал - не получилось заставить работать как надо
Какое "все приложение"? CP - это, в общем, вещь в себе. Даже когда является частью боле объемного решения. А все сильно навороченное, к нему относящееся, если оно есть, все равно в отдельный сервис выносить надо. Вне зависимости от того, на каком языке это сложное написано. Просто чтобы в ноги себе лишний раз не стрелять.
И через пять минут выяснится, что Вам еще нужен subauthentication или типа того, и опять ныряете в нативный код.
Все это заслуг автора не умаляет. Я знаю некоторое число людей, которые пытались, да не совладали, даже с подсказками с GitHub. А он смог.
Всегда можно реализовать CLI обёртку, которая будет проксировать вызовы C# <-> C++. И тогда можно будет часть функционала писать на С++, а часть на C#, пользуясь преимуществами обоих языков и при этом не переписывая всё с нуля.
Пример: часто видел как делают UI на WPF, а бизнес логику на C++.
А еще лучше разделить бизнес-логику и UI вообще на две совершенно разные части и между ними API поставить. И тогда что на чем реализовать вообще без разницы.
И Вы, и немного автор выше, совершенно не учитываете специфику предметной области. Речь идет не о приложении. Речь идет о довольно специфичной штуке. "Совершенно разная часть" которой, отвечающая за UI, реализована за нас (CredUI и проч.). И нужны очень веские причины, чтобы ей не пользоваться (хотя совсем не пользоваться может не выйти).
Идея была, что какую то логику, например ту же проверку OTP мне легче реализовать на C#. Но да можно взять готовый пример от Microsoft на плюсах и использовать его, особенно если необходимо погружаться ещё глубже.
Тут же скорее реализация для каких то простых доработок.
ОК, я примерно так и думал. Если вдруг всерьез что-то такое делать надо, на pGina имеет смысл взглянуть, если еще не. Там совсем не дураки писали, и уже масса заготовок к тому, чтобы вот вынести логику типа проверок ОТП в отдельный сервис, написанный пофиг, на чем.
Кстати, для совсем простых доработок можно взять штатные примеры для wrapper'ов вокруг CP, и даже переписать это на шарпе. Скорее всего, нужда в плюсовом коде вообще отпадет. И возможностей такой подход дает куда больше, чем может показаться на первый взгляд.
Но, повторюсь, заслуг никак не умаляет. Если бы такое появилось лет 8-10 назад, я бы лишился толики денег :-) Индусы, начинавшие писать CP на шарпе, и не совладавшие, приносили небольшой, но стабильный доход. Не знаю, что у них там за поветрие было, но массово писали. Наверное, какая-нибудь кампания типа нашего импортозамещения была.
Пишем свой Credential Provider на C# для авторизации в Windows