Comments
с упором на максимальную автоматизацию процесса установки защиты

Максимальная автоматизация — это когда сборки автоматически защищаются на билд-сервере. Вы такое настраивали?
Да, это стандартная функциональность, в пункте 7 как раз про это.
В пункте 7 показано, как это сделать в VS (с учетом того, что LDK установлен на компьютере разработчика). А вот вещи типа «как сделать, так, чтобы это выполнялось на билд-машине» — нет (равно как и вещи вроде «как сделать так, чтобы при разных конфигурациях проекта он собирался либо с защитой, либо без).
Ну тогда до максимальной автоматизации вам еще весьма далеко. Потому что с одной стороны, holy Grail автоматизации в разработке — это сборка всего на билд-машине, а с другой стороны, именно в этом месте огребается максимум проблем с подключением любых утилит.
Автоматизация в данном случае касается именно частного примера с .NET, где описывается возможность разметить код, чтобы больше к вопросу настройки параметров защиты не возвращаться.
описывается возможность разметить код, чтобы больше к вопросу настройки параметров защиты не возвращаться.

… и явно завязать исходники на используемую технологию защиты? Нет уж, спасибо.

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

Нет, не говорится. Защита чего-то с помощью еще не означает, что защищаемое знает о том, с помощью чего его защищают. При правильной реализации можно выкинуть одну защиту, заменить на другую, не трогать исходники (кроме, например, конкретного участка, считающего пользователей).

Ну и утверждать, что использование билд-сервера — это единственные метод автоматизации защиты Вы же всё-таки не будете?

Я буду утверждать, что в рамках практики continuous integration часть процесса превращения исходников в финальный продукт, которая не вынесена на билд-сервер, не является достаточно автоматизированной.
Так Вас никто не заставляет размечать код в принудительном порядке, не хотите — не надо, просто в этом случае Вам нужно будет полагаться на то, как Envelope автоматом разберёт ваш код или при изменении кода приложения менять настройки проекта.
Ну и собственно то что Envelope можно использовать на билд-сервере — я уже сказал, просто лично я этого не делал.
Ну и собственно то что Envelope можно использовать на билд-сервере — я уже сказал, просто лично я этого не делал.

Ну вот поэтому ваша статья и неполна. Самого интересного в ней нет.
Да собственно, если код не размечать — это будет обычный подход к работе с Envelope, а разметка кода — это работает только под .NET и я описал как это использовать.
разметка кода — это работает только под .NET и я описал как это использовать.

Вот только для автоматической защиты это не нужно.
Никому и никак. Эти атрибуты одинаково работают как в ручном, так и в автоматическом режиме; и автоматический режим одинаково хорошо работает как с ними, так и без них. То, что вам удобнее настраивать Envelope с помощью атрибутов — прекрасно, но именно к автоматизации отношения не имеет.
Атрибуты позволяют не менять проект, не запускать Envelope и управлять защитой из кода, чем не автоматизация?
Расставить атрибуты — это мощный инструмент, который позволяет избежать проблем с тормозами автоматической обфускации и шифрования, и выбрать либо особа значимые участки кода, либо наименее ресурсоёмкие. Да и собственно ни одной сточки защитного кода писать не требуется, всего лишь расставить флажки — разве это не автоматизм?
Когда вы настраиваете защиту в проекте, вы тоже не пишете ни одной строчки кода.

Проще говоря, разница между настройкой атрибутами и настройкой в проекте только в месте настройки; степень автоматизации процесса одна и та же.
Так если поменять код, добавить новый класс — придётся снова лесть в проект и всё настраивать, а здесь всего лишь подставить атрибут.
Подставить атрибут — не автоматическое действие, поэтому автоматизация здесь не при чем.

Если вы хотите поговорить за «настройка атрибутами vs настройка в проекте», то все плюсы/минусы уже озвучены — «настройка близко к коду vs привязка к конкретной системе защиты».
Насколько я помню наш опыт, там все любопытно: сам разработческий комплект (софт+разработческий ключ) стоит смешных денег, но он рассчитан на работу с ключами, а болванки ключей вы покупаете у поставщика. И вот тут, собственно, и начинается сам профит…
Т.е. бесплатно попробовать на губки не раскатывать? И льгот для стартапа тоже нихт?
Когда мы этим занимались, бесплатно попробовать было вполне реально. Про льготы ничего не знаю.
А с какими типами токенов это может работать?
Только с Алладином, или ещё, например с гуардантом или с китайскими токенами?..

Only those users with full accounts are able to leave comments. Log in, please.