Предложения и пожелания

Предложение разработчикам добавить в утилиту GrdUtil, и соответственно в базу, поле "Проект". Чтобы можно было разделять клиентов, маски и прошивки одного приложения от другого.

Не собираетесь ли вы в будущем сделать встроенную XML-документацию кода для C#

http://msdn.microsoft.com/ru-ru/library/b2s063f7.aspx

Примеры обучающих уроков написаны на Delphi и C#, хотелось бы видеть готовые примеры и на C++Builder.
(Имеется ввиду файлы)

Хорошо было бы иметь на сайте раздел "Загрузить/Для пользователей", где бы лежали

1) Драйверы
2) Сервер
3) Утилиты (ActivationWizard, GrdDiag, TRU)
4) Документация

В общем, то что нужно конечному пользователю

А еще можно это все включать в комплект разработчика в отдельную директорию "Redistributable"

Летом планируется очередной релиз комплекта разработчика Guardant 6.3. Состав изменений все еще до конца не сформирован, так что после майских праздников я отпишусь здесь какие из собранных пожеланий мы реализуем, какие отложим и т.д.

Добрый день.
Предлагаю изменить названия перечислений GrdFM GuardantDotNetApi. Сейчас :

  public enum GrdFM
    {
        ALL = 0,
        ID = 2,
        Mask = 0x10,
        NProg = 1,
        SN = 4,
        Type = 0x20,
        Ver = 8
    }

На самом деле All скорее означает None. All = 63   None=0
Как-то так....

Исходные данные.
При инсталляции защищенного приложения, наш инсталлятор проверяет текущую версию установленных драйверов ключей Guardant и при необходимости выполняет инсталляцию драйверов ключей нужной версии.

Проверка версии драйверов делается с помощью grddrv.dll. При отсутствии доступа к grddrv.dll считается, что guardant ключи не установлены, при наличии - дополнительно определяется версия драйверов.

Проблема.
Однако, при инсталляции драйверов ключей, grddrv.dll в систему устанавливается той же разрядности, что и разрядность драйверов ключей (x32/x64). Инсталлятор же защищенного приложения сам по себе является 32-разрядным приложением, и, следовательно не может работать с grddrv.dll 64-разрядной версии.

Предложение.
При инсталляции драйверов ключей, дополнительно, всегда поставлять библиотеку grddrv.dll в как 32, так и 64 - битной разрядности, именуя их grddrv32.dll  и grddrv64.dll.

Примечание
В данный момент наш инсталлятор защищенного приложения просто "носит" с собой  grddrv.dll 32-разрядной версии.

Интересует возможность реализации аппаратных ключей в формате mini-SIM-карты.
Доступ к ключу производить на основе семейства протоколов ISO-7816.

Данные техническое исполнение ключа возможно использовать во встраиваемых системах, где есть слоты.

Таким образом, получится SAM - Secure Access Module.

Спасибо. Передадим нашим специалистам.

Делаю первые шаги в освоении технологий Guardant, возможно еще не разобрался в ряде вопросов. Если это так, то поправите меня.
Думаю следующее развитие будет полезным.
1.    Расширить набор примеров на C#.
Примеры на C# не охватывают всю функциональность API. Нет примеров для Code. Нет примеров для TRU.
Думаю, что более предпочтительны примеры в виде консольного приложения, нежели оконного примера как в уроках практического курса.
2.    В обфускатор .Net включить поддержку переименований в BAML файлах.
Это крайне важно для WPF приложений. Иначе много придется исключать из офускации т.к. и наименование контролов,  и дата биндинг, и ресурсы XAML, привязываются к именам кода. Если поддержки переименования в BAML не будет, то проще использовать внешний обфускатор для WPF приложения, а в таком случае затруднено добавление функций в исключения в ExclusionUtility.
На сколько мне известно такие опен сорс проекты как Obfuscar в каком то, объеме это делают.
Например если в XAML контрола или окна использовать атрибут x:ClassModifier="internal", то возможно практически полностью удалить наименования классов при обфускации в Dotfuscatore.
Вообще неплохо было-бы BAML файлы шифровать при автозащите, т.к. там много текста.
3.    Дополнить обфускатор.
Добавить возможность настройки удаления информационных атрибутов на подобии [DebuggerDisplay("{Position}; {Normal}")].
Добавить возможность настройки обфускации имен локальных переменных у публичных функций. Например:

4.    Дополнить ExclusionUtility.exe  анализом сборок и автоматическим расставлением галочек на обфускацию.
Например, если в сборке используется атрибут [Obfuscation(Exclude = true)], то галочка не ставиться и появляется возможность просмотреть причину исключения из обфускации. Аналогично не проставлять галочки на обфускацию при наличии ссылок в BAML файлах.
Да и автоматический выбор галочек для обфускации потока управления тоже не помешает, т.к. даст возможность понять какие функции в итоге будут обфусцироваться при заданном проценте защиты.
5.    ExclusionUtility.exe  - нахватает функционала анализа изменений в сборках.
Например, если у меня изменился проект (добавились и удалились классы и/или функции), мне нужно будет расставить все галочки заново?
6.    Исходный код GuardantDotNetApi.dll
В принципе GuardantDotNetApi.dll можно декомпилировать (это законно?). Но лучше бы иметь исходный код для встраивания в собственное приложение. И наборы функций-утилит преобразования данных из массивов байт и обратно.
7.    Экспорт из GrdUtil в C#.
Преобразовать Си код в код C# больших проблем не составляет, но и запрограммировать это преобразование в GrdUtil тоже, зато будет польза для остальных разработчиков.
8.    Еще заметил прикольную подсказку.