trh пишет:gnclient.ini существует
API без автозащиты: ОК.
Автозащита без API: ОК.
API c автозащитой: автозащита ОК (т.е. автозащита находит ключ и занимает лицензию); API - UnableToCreateIniFile.
Upd:
Дал пользователям права на изменение файлов в каталоге - все заработало.
Тогда не понимаю почему работает GrdStartupEx без автозащиты?
Такое поведение нам воспроизвести у себя так и не удалось:
Если у пользователя есть права на запись в каталог (или, хотя бы, права на изменение предварительно созданного *.ini-файла), то корректно отрабатывает и автозащита, и Guardant API (как по отдельности, так и совместно);
Если у пользователя нет нужных прав на доступ к каталогу (*.ini-файлу), то *.ini-файл не может создать\изменить ни автозащита, ни Guardant API.
trh пишет:И еще один вопрос.
Если я указываю что искать файл надо по значению переменной окружения, то зачем автозащита создает gnclient.ini во всех папках, где приложения других разработчиков загружают наши dll?
Тут выявилось некорректное поведение утилит автоматической защиты .Net-приложений.
Так, если автозащита выполнялась при помощи GUI-мастера (LicenseWizard.exe), а кроме защиты кода выполнялась еще и обфускация, то валидной директорией для поиска *.ini-файла будет считаться та, которая была указанна в опциях обфускатора - GUI-мастер же применяет опцию /RCS_ только для утилиты защиты кода, что отражено в соответствующих *.bat-файлах параметров вызова утилит автозащиты (файл с расширением *.obf содержит набор опций для обфускатора, а файл с расширением *.prt содержит набор опций для утилиты защиты кода).
В результате реальный путь создания\поиска *.ini-файла остается тот, который применяется при автозащите "по умолчанию" (текущий каталог для исполняемого файла), как будто опция /RCS_ не применялась. Это поведение будет исправлено.
Если выполнять автозащиту .Net-приложения при помощи консольных утилит обфускации и защиты кода, и задать нужный параметр /RCS_ и для обфускатора и для утилиты защиты кода, то *.ini-файл будет создаваться\искаться в заданной директории.
