не бывает

даю установщик с WiX для установки программы, для каждой машины (не для пользователя), и это дает им возможность зарегистрировать программу. Регистрация включает в себя ввод имени пользователя и организации (или принятие некоторых значений по умолчанию из настроек Windows) и ввод действительного регистрационного ключа. Когда регистрационный ключ проверен, я записываю настройки реестра в область HKEY_LOCAL_MACHINE с этой информацией. В Windows при запуске MSI автоматически запрашивается пароль администратора, чтобы можно было установить значения реестра в HKEY_LOCAL_MACHINE. Пока жизнь хороша ...

Я включаю опцию в MSI, чтобы дать пользователю возможность отложить регистрацию до более позднего момента времени. Однако, если пользователь является обычным пользователем, и он запускает приложение, если у меня есть диалоговое окно в приложении, которое запрашивает имя / org / product-key, Windows не позволяет приложению записать информацию в HKEY_LOCAL_MACHINE. Таким образом, пользователь не может использовать само приложение, работающее как обычный пользователь, чтобы выполнить регистрацию для каждого компьютера, как это делает MSI после запроса учетных данных администратора.

Тогда я подумал, что для регистрации после установки либо (а) найти способ изнутри приложения повысить привилегии, предложив ввести учетные данные администратора, что позволит ему написать HEKY_LOCAL_MACHINE (это возможно?), (Б) включить опция в установщике, которая при запуске, когда приложение уже установлено и не зарегистрировано, проходит регистрацию, как при обычной установке. Затем он запросит учетные данные администратора, и жизнь снова станет хорошей. В качестве альтернативы (c) создайте отдельный MSI, который просто выполняет регистрацию, установите его вместе с программой и вызовите этот MSI из программы, когда пользователь выберет команду «Register ...» в программе.

Я не видел ни одного из этих подходов ни в одном приложении, поэтому не уверен, что это хороший подход. Однако, кроме этого, я не уверен, как после установки я могу удобно разрешить пользователю регистрировать приложение для каждой машины. В идеале я хотел бы иметь возможность делать это из команды в приложении, но повторный запуск установочного MSI был бы минимально приемлемым.

Как это обычно делается? Или установки для отдельных машин обычно сопровождаются регистрациями для отдельных машин?

 PhilDW27 окт. 2017 г., 19:58
Обычный способ состоит в том, чтобы перенести это требование повышенного кода в один отдельный исполняемый файл с манифестом повышения прав.
 lurker27 окт. 2017 г., 19:55
@PhilDW да, действительно, я знаю об этом. Я попытался прояснить в своем вопросе, что на самом деле это дилемма, когда нужно разрешить пользователю регистрироваться из приложения. MSI при запуске для каждой машины будет автоматически вызывать у пользователя учетные данные администратора. Если бы я мог сделать это из моего приложения, это было бы здорово, но я не знаю, как это сделать. Я не хочу двух разных регистрационных записей. Или нецелесообразна ли регистрация для каждой машины? Таким образом, вы предлагаете лучший подход, даже с установкой на компьютер, на регистрацию пользователя?
 PhilDW27 окт. 2017 г., 19:51
Я почти уверен, что вы понимаете, что ограниченный пользователь не может писать в HKLM, поэтому повышение требуется где-то. В настройках MSI нет ничего особенного, что позволяет ограниченному пользователю нарушать правила безопасности, за исключением предоставления учетных данных или повышения групповой политики. HKCU может быть лучшим решением - по крайней мере допустимо (в смысле Windows) для двух пользователей устанавливать на одного пользователя в одной системе, так что для этого потребуется две записи.
 lurker27 окт. 2017 г., 19:58
@PhilDW, возможно, регистрация для каждой машины обычно не выполняется, что было бы для меня очень хорошим ответом. Основная сущность моего вопроса - понять, что обычно делается (лучшие практики) для установок на отдельные машины. Как я упоминал в своих настройках, я мог добиться повышения прав после установки, если бы пользователь снова запустил установщик MSI или запустил отдельный MSI, который запрашивал учетные данные администратора. Но я не знал, с точки зрения лучшей практики, что это неестественный акт.

Ответы на вопрос(2)

свойств установщика Windows, поэтому он просто работает.

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

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370826(v=vs.85).aspx

Аналогично, имя пользователя и название компании связаны в диалоговом окне со свойствами USERNAME и COMPANYNAME.

После этого они доступны через (Win32) MsiGetProductInfo (), запрашивая RegOwner и т. Д .:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370130(v=vs.85).aspx

или аналогичные API (WMI делает некоторые из этого).

Итак, вообще говоря, вы просто устанавливаете свойства из диалоговых окон, и все это просто работает без необходимости записывать их в реестр.

 lurker27 окт. 2017 г., 22:03
С другой стороны,просто работает часть, кажется, только произойдет, если я используюVerifyProductId функция, которая проверяет идентификатор продукта на основе шаблона. Идентификатор продукта, который я использую, основан не только на шаблонах, поэтому мне пришлось провести собственную проверку. В этом случаепросто работает не бывает
 lurker27 окт. 2017 г., 22:00
Так что, вообще говоря, вы просто устанавливаете свойства из диалогов, и все это просто работает, Разве это не с точки зрения установщика (MSI)? Я знаком с этим. Ваши комментарии оMsiGetProductInfo на самом деле, вероятно, ответить на мойвопрос до, Но это не отвечает на мой текущий вопрос о том, как выполнить регистрацию приложения после установки.
Решение Вопроса

еальных решений, но есть несколько вариантов (как вы уже обнаружили).

Прежде чем ответить, я хочу отметить, что у меня есть сильное отвращение к чрезмерной регистрации и настройке в самой настройке. Это подвержено ошибкам, и гораздо лучше сделано в самом приложении по множеству причин:Установщик с онлайн-регистрацией для приложения Windows (рекомендуется быстрое чтение - реальный опыт).

Запись в HKCU

Как вы уже знаете, одним из вариантов является сохранение лицензионного ключа и регистрация только в HKCU. Это часто приемлемо, если вы не хотите делить лицензионный ключ между многими пользователями на коробке. Лицензионный ключ, если он добавлен в HKCU, также обычно перемещается с пользователем на другие компьютеры, что может быть полезным или желательным.

Лично я предпочитаю эту опцию: не регистрировать что-либо в настройке, а записывать в HKCU или в профиль пользователя из приложения (как также объяснено в приведенной выше ссылке). Как уже говорилось, единственным недостатком является то, что вы не можете написать общий лицензионный ключ в HKLM, поэтому он применяется ко всем пользователям, а не только к одному.Это приложение, уши, чтобы быть ядром проблемы, которую вы описываете.

Запись в HKLMПрограмма установки пишет HKLM: Запишите лицензионный ключ HKLM (и регистрацию) во время установки в HKLM, как Фил описал выше, используя свойства установщика Windows по умолчанию (просто перечислите это как опцию - о которой вы уже знаете). По моему мнению, это должно работать нормально, но, похоже, ваша проблема заключалась в том, чтобы разрешить «отложенную регистрацию».Пользовательское разрешение HKLM ACL: Для того, чтобынапишите в HKLM из вашего приложения без повышенных правОдин из способов сделать это состоит в том, чтобы использоватьприменять обычайРазрешения ACL в папку в HKLM, где вы хотите записать раздел реестра из вашего приложения, Затем ваше приложение может свободно обновлять это конкретное местоположение в HKLM в любое время без повышенных прав. Вы просто добавляетеACL доступ на запись для "пользователей".WiX поддерживает это, но у меня нет образца для вас,пожалуйста, проверьте документацию WiX для разрешения.Использование пользовательских разрешений обычно не одобряется (и я согласен, что это не идеальный дизайн), но оно позволяет любому пользователю добавлять лицензионный ключ в HKLM без каких-либо повышений прав после установки (а также позволяет любым пользователям удалять его - что может быть проблема).См. Раздел 14 здесь для быстрого описания того, почему пользовательские разрешения обычно не рекомендуется:Как избежать типичных ошибок проектирования в моем решении по развертыванию WiX / MSI?Подводя итог, я обычно не предлагаю устанавливать пользовательские разрешения, но это определенно будет работать. Я сделал это сам, когда требования клиентов таковы, что это единственное, что они примут. Это нарушит требования к логотипу для приложений Windows, но оно должно быть менее серьезным, чем проблемы безопасности, возникающие в результате варианта 3 ниже.Запустите приложение от имени администратора: Если вы не хотите применять разрешения ACL,Я полагаю, что вы можете запросить у пользователя права администратора для вашего приложения, как описано здесь (Я полагаю, что это то, на что Фил ссылался в своем комментарии, если я правильно понял):Как заставить мое приложение .NET запускаться от имени администратора? (легендарныйГанс Пассант - еще один ответ).Это определенно не рекомендуется (но мы хотим показать людям, что тоже возможно). Все ваше приложение будет работать с правами администратора все время, что не очень хорошая идея.Это нарушит основную часть требований к логотипу для приложений Windows, и вы также откроете свое приложение для атаки от вредоносных программ.Обязательно постарайтесь, чтобы ваши пользователи поняли последствия этого «легкого исправления». Я бы позаботился о том, чтобы возложить всю ответственность на клиента, если он выберет этот вариант - он должен понимать, что он делает.Обратите внимание, что вы должны иметь возможность использовать этот манифестный подход для запуска отдельного EXE-файла с повышенными правами на выполнение только регистрации. Смотрите следующую точку пули.Поднять приложение по запросуЯ не знаком с техническими деталями повышения уровня вашего приложения по требованию во время его работы - когда вы вызываете диалоговое окно или функцию, которая требует доступа к HKLM.Возможно, Фил знает способ достичь этого? Я нашел несколько ссылок, хотя:Подъем во время выполнения (из кода проекта)Как повысить привилегии только при необходимости? (хорошо читать)Скользя по вышеупомянутому связанному контенту, кажется, что вы можете запустить отдельный EXE-файл с повышенными правами для вашей регистрации - я полагаю, это известная вам опция.Буду рад получить ответ, если вы решите попробовать это. Может быть полезным для всех нас.Проверка в интернете: Просто добавив опцию: я часто хочу, чтобы вся проверка лицензионного ключа регистрации выполнялась онлайн из приложения (никогда, никогда не пытайтесь сделать это из настройки, просто так, как упоминалось), установка, которая пытается получить доступ Интернет может быть самым большим анти-паттерном развертывания - по крайней мере, на данный момент).Я пишу лицензионный ключ из установки, и проверка его происходит при запуске приложения на сервере в Интернете. Тогда в вашем приложении нет кода проверки или вашей настройки для взлома.Вам необходимо интернет-рукопожатие, и вы можете повторить этот процесс для каждого пользователя, что позволит вам жестко контролировать, кто использует ваш лицензионный ключ.Нет ничего проще, и проблемы с прокси-сервером могут вызвать проблемы. Корпоративное развертывание также будет означать, что такая «онлайн-активация» осуждается. Они хотят, чтобы приложения были полностью установлены после развертывания.Отдельная регистрация MSIЯ бы предпочел не создавать отдельный MSI только для процесса регистрации, как вы упоминаете в своем вопросе. Это просто кажется ненужной сложностью, которая может легко сломаться. Во-первых, вы получаете проблему с двумя источниками, которую нужно постоянно поддерживать. Я предполагаю, что это может стать классической проблемой поддержки.Перезапустите оригинальный MSIЧестно говоря, я не уверен, что при повторном запуске вашей первоначальной настройки для регистрации она будет повышена или нет. Я думаю, что он будет повышен (должно быть, я не вижу причин, по которым этого не следует делать - база данных MSI хранит флаг, чтобы определить, требуется ли повышение)Количество слов"), и тогда вы сможете добавить свои регистрационные данные, если вы откроете диалог регистрации из настроек"модифицировать" или же "ремонтрежимы.
 lurker28 окт. 2017 г., 03:51
Я еще не сделал, но планирую прочитать ссылки, которые вы предоставили, чтобы быть более информированным в моем выборе.
 lurker28 окт. 2017 г., 03:50
Это отличный, исчерпывающий ответ. Я на самом деле не рассматривал понятие регистрации «следуя за пользователем» через HKCU, но это полезное понятие по сравнению с лицензированием для каждой машины. То, что привело меня к пути для каждой машины, это то, что я читал в документации WiX, чтоустановка на машину это путь ииндивидуальная установка как правило, следует избегать из-за сложности сценариев удаления. Я, естественно, думал, что это подразумевает лицензирование для каждой машины, и в этом случае мне показалось «странным» рассматривать лицензирование для каждого пользователя. Ваши комментарии заставляют меня думать, что, возможно, это не такая плохая идея.

Ваш ответ на вопрос