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

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

Все верно, данная опция только выводит сообщение об отсутствии нужного электронного ключа заданное количество раз, без использования данной опции это сообщение будет выводится по умолчанию 50 раз.

Действительно можно использовать Guardant API для реализации собственного механизма опроса ключа, в том числе и периодического, но нужно понимать, что в таком случае для .net-приложения есть возможность отследить вызовы API-функций.

В ноябре.

Непонятно почему, ведь при расшифровке строк, к ключу обращаемся постоянно, почему бы не проверить его без расшифроки строк?

Читаю руководство - опции CodeProtect.exe
Опции привязки .NET-сборки к электронному ключу
/RC[=xx] - Если ключ не найден, проверять его наличие и выводить сообщение об отсутствии ключа заданное число раз
Ключ не найден когда? Он же не ищется при работе приложения или все-таки ищется?

Приблизительная дата выхода релиза?

Пробовал. В моем случае на быстродействие влияет только шифрование строк.

Если новый релиз не поможет, выход из положения - использование для проверки ключа в процессе работы функций API, а сверху навесить автозащиту?

Спасибо.

Данный параметр является неактивным, поскольку его использование не предусмотрено для .net приложений.

Тут нужно понимать, что в силу особенностей самой технологии .net, реализовать периодическую проверку на наличие ключа не представляется возможным.

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

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

Также хочу, обратит внимание на то, что в следующем релизе нашего SDK для данной опции ("шифровать строки файлов данной группы ") будет реализовано кэширование строк, что позволит избежать существенного замедления при работе защищенного приложения.

Еще, как вариант (если после защиты при работе приложения наблюдается значительное падение скорости его работы), стоит попробовать выбирать защищаемые функции на основе профилирования.

Подробнее все особенности и опции автозащиты для как для Native, так и для .net приложений описаны в руководстве пользователя (документация находится в одной директории с установленным комплектом разработчика, по умолчанию - C:\Program Files (x86)\Guardant\Guardant 5\XXXXXXX\Doc).