Развертывание настроек по умолчанию для разных клиентов

Мой вопрос как бы связан с этим существующим вопросом

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

Тем не менее, я понимаю идею использования настроек приложения, но не могу найти информацию о том, как мне развернуть настройки приложения для разных клиентов?

У нас есть система пользовательских настроек, которая отлично работает, однако при первом запуске приложения необходимо знать несколько вещей, таких как название компании и сервер приложений. Они, очевидно, будут отличаться в зависимости от клиента.

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

В настоящее время я думаю о том, чтобы иметь какой-то файл настроек в отдельной сборке для каждого клиента. Так ли это, или я пропустил какую-то встроенную поддержку этой идеи «профилей клиентов»?

РЕДАКТИРОВАТЬ:

Дополнительная информация, которая может помочь людям понять мой вопрос.

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


person MrEdmundo    schedule 13.01.2010    source источник
comment
Я не понимаю, почему бы не попросить пользователя ввести эти настройки при первом запуске. Это был бы мой путь. РЕДАКТИРОВАТЬ: Задайте эту информацию в настройках.   -  person jonaspp    schedule 13.01.2010
comment
Потому что пользователь этого приложения не будет иметь представления о пути к серверу приложений и не должен им IMO.   -  person MrEdmundo    schedule 13.01.2010
comment
Невозможно запросить эти параметры при настройке, поскольку приложение будет развернуто с помощью групповой политики.   -  person MrEdmundo    schedule 13.01.2010
comment
Наконец, вы пришли с какими-либо решениями для этого? Если да, пожалуйста, поделитесь. Многие из нас сталкиваются с этой ситуацией, это действительно поможет нам. Спасибо   -  person Marshal    schedule 12.04.2011


Ответы (3)


Многие приложения при первом запуске задают некоторые начальные настройки (Microsoft Office, Visual Studio и т.д.). Таким образом, это поведение обычно известно пользователю.

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

Также было бы полезно предварительно заполнить эти диалоги при первом запуске, получив эту информацию где-то вне машины (например, название компании можно получить из реестра [HKLM\Software\Microsoft\WindowsNT\CurrentVersion\RegisteredOrganization] или как сервер приложений адрес шлюза, сервер AD, что чаще всего совпадает).

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


Обновлять:

Поэтому, если пользователь не знает путь к серверу приложений. Кто это делает? Где находится эта информация? Может быть, вы можете заставить своих клиентов предоставлять эту информацию таким же образом. Возможно, они установили какую-то переменную среды в сценарии входа или поместили файл с необходимой информацией в глобально доступное место (например, туда, где находится сценарий входа).

person Oliver    schedule 13.01.2010
comment
В принципе администратор системы знает эту информацию, но клиентскому приложению она нужна в первую очередь. Существует ли путь, хранящийся на локальных ПК, который доступен и является центральным для всех компьютеров в домене, и к которому можно получить общий доступ для всех клиентов. Тогда необходимая информация может быть сохранена в этом месте, и приложение получит необходимые настройки при первом запуске. - person MrEdmundo; 13.01.2010

Если я правильно понимаю, вы хотите развернуть предварительно настроенное программное обеспечение для каждого пользователя. Вы можете использовать WIX для создания MSI-пакета для каждого клиента. Вы можете предоставить несколько пользовательских настроек в своем ориентированном на клиента msi. Вы можете динамически генерировать WIX-XML-документ на основе источника данных, в котором вы храните своих клиентов. Это немного работы, но позже экономит много работы. Создание MSI через WIX можно легко интегрировать в процесс сборки.

person martin    schedule 13.01.2010
comment
Спасибо, я посмотрю на это, чтобы увидеть, поможет ли это. - person MrEdmundo; 13.01.2010

Учитывая, что это корпоративная среда, рассматривали ли вы возможность использования ClickOnce? Мы добились успеха в основном с аргументами запуска, например. http://servername/OurApp.application?environment=uat

Он не всегда масштабируется, но вы можете передавать аргументы, используя переменные GET и анализируя результирующий QueryString при доставке через HTTP — http://msdn.microsoft.com/en-us/library/ms172242.aspx

Вы можете передать настройки в QueryString или создать их в базе данных, сгенерировать (хешированный?) ключ и построить QueryString, уникальную для этой ссылки (с дополнительным преимуществом, что любознательный пользователь не сможет манипулировать URI и подделать другой набор параметров).

person Unsliced    schedule 01.06.2010
comment
Привет, я недавно просматривал ClickOnce, что привело к следующему вопросу: serverfault.com/questions/143055/ Если я не могу решить эту проблему, это будет сложно использовать. Спасибо, Эд. - person MrEdmundo; 03.06.2010