AnTeвообще, изучив бегло и совсем немного эту тему, я понял, что костыльные решения без всяких msi - вполне нормальный вариант даже для крупных корпораций. Тот же гугл хром пишет целую гору бинарников в Application data - т.е. в блоке для данных (если я ничего не перепутал) и т.д. и т.п. на политику майкрософта многие тупо забивают
Я бы сказал, что не нормальный вариант, а распространённый. У хрома есть Chrome for work именно в виде msi.
Майкрософт сам тупит безбожно и плевать ему на свои же политики.
Расскажу свою историю: поймали в организации во второй раз за год шифровальщик. Из почты вместо акта сверки бухгалтер запустил скрипт, который зашифровал все файлы, до которых успел дотянулся (в том числе и на примонтированных сетевых дисках). Всё конечно восстановилось, но было потрачено время и больше такого не хотелось. Первым делом заблокированы были вызовы пользователями виндовых скриптов и захотелось казалось бы обычного: разрешить выполнять программы только из тех папок, в которые пользователи не смогут ничего сами поставить (для портативной мелочёвки была создана специальная шара, в которую мог писать только админ, а остальные только запускать). А то мало ли какую гадость еще запустят. Собственно, решено - сделано. Пробовалось всё на голой машине, чтобы не парализовать работу организации. Первым делом отвалился встроенный в десятку OneDrive. Вот прям принципиально ему распаковываться в папке пользователя с припиской версии, так что даже путь никак в политиках не пропишешь. Было бы что-то типа: Application Data\OneDrive\OneDrive.exe - было бы пол беды, но там в имени папки версия программы еще дописывалась или вроде того. Оставлять дыру и разрешать всему подряд запускаться из папки, куда может писать пользователь? Тогда нет никакого смысла во всех телодвижениях, ибо вирус туда легко и непринуждённо запишется и запустится. Добавлялись программы и добавлялись исключения для них, росли дыры. Многим программам принципиально ставиться скопировав себя рядом в папку scoped_dir<какой-то номер>, тоже непонятно куда и на что давать разрешения. Дальше пошли вопросы с обновлениями. Например, 7zip - засунул msi в LUP, прописал пару банальных проверок и он спокойно обновляется и ставится вместе с накатыванием виндовых обновлений. Для всяких флешей и адоб ридеров благо готовые конфиги есть (msi у них по-моему тоже есть, но за деньги), а то ищи по реестрам и файлам и ищи как узнать какая версия сейчас установлена на компе и как потом запустить инсталлятор в тихом режиме, чтобы ничего у пользователя не запрашивалось. Все эти вопросы конечно решаемы, но это лишние, никому ненужные заморочки.
Считаю, что если софт пишется для корпоративного рынка, то как минимум должен быть вариант с msi без всяких там постоянно висящих в трее обновляторов и без самообновлений, какие-то хотя бы доки и ключи, чтобы можно было изменить путь установки/распаковки временных файлов. Я блин хочу закрыть temp для запуска программ, но им там мёдом намазано и хочется именно туда что-то распаковать и запустить. В некоторых случаях было бы неплохо и шаблоны делать для накатывания групповых политик. Я не понимаю в чём проблема повернуться к админам лицом и сделать так, чтобы было удобно у функционально. Не сделали административных шаблонов для развёртывания, не написали доку - какой-то админ у себя пропишет неправильные скрипты (не так поймёт ключ в реестре, не к тому значению привяжется или просто в новой версии всё изменится) и тупить будет программа, а не админ, ругать будут программу, а где-то тупо откажутся от ПО, т.к. она не впишется в инфраструктуру и создаст дыры в безопасности. Или придётся выслушивать подобные тирады:
http://forum.sbis.ru/viewtopic.php?f=17&t=43725
А вот для домашних пользователей и всякой мелочёвки лучше автообновляторы лепить, т.к. там запрещать некому, а обновлять будут забывать или просто испугаются что что-то нужно отдельно запускать. На всех не угодишь, серебряной пули опять нет :)
