Въпроси Настройки на клиента

Въпреки факта, че новата функция е достатъчно прозрачен, за да използвате, ние често получаваме въпроси от потребители за предоставяне на потребителски скриптове да го използвате - защо <это> работи и как да се направи <то> Тя работи малко по-различно.

Забелязал съм, че има два вида настройки - настройките на приложението (Application с обхват) и предпочитанията на потребителя (User с обхват). Освен това, настройките на приложението, изглежда, само за четене, и не мога да ги променя по време на изпълнение. Защо така?

Има два основни вида опции, които се използват от приложения:

1. Някои данни, като струни връзка на базата данни или интернет връзки, които не се променят често, но все пак трябва да бъде на разположение за редактиране от администратора и поради това не могат да бъдат "зашити" в кода на приложението.
2. настройки и предпочитания на потребителя, които могат да се променят по всяко време.

Приложение с обхват настройки са предназначени за използване в първия сценарий потребителят с обхват - във втория. Тези съображения се дължат и поведение SettingsProvider подразбиране - конфигурация заявление файл, съхраняван в app.exe.config до изпълнимия файл, както и потребителските настройки - в user.config файл в папката на данните на потребителя. Чрез app.exe.config файлове не може да има права за запис по време на работа, например, ако приложението е инсталирано в C: \ Program Files \. където само привилегировани потребители имат достъп до записа. Дори ако такъв достъп е - това обикновено не е добра идея, за да промените настройките, които засягат всички други потребители на приложението.

Ти каза, че user.config файлове са в папка с данни на потребителя. Как мога да намеря този файл? Той е 12:59 приложение или няколко?

Както вече споменахме, SettingsProvider подразбиране за клиентски приложения (LocalFileSettingsProvider) спестява настройките на приложението в конфигурационните файлове. В .NET 1.0 и 1.1, имаше две нива на конфигурационни файлове - machine.config и app.exe.config (където "App.exe" - името на приложението файл). В .NET 2.0, ние добавихме още две нива, за да съхраните настройките специфични за потребителя - в роуминг профила на потребителя папка в папка на локалния потребителския профил. За XP, че ще бъде нещо като "C: \ Documents и Settings \\ Data Application "и" C: \ Documents и Settings \\ Local Settings \ Application Data ", съответно. Тези директории - препоръчани (и за Windows Logo - задължително) пространство за съхранение на потребителски данни и повечето приложения (като Outlook и Visual Studio) постави потребителски данни тук.

Точният пътя към user.config на файла ще бъде като този:

• - каталог роуминг или местен потребителски профил. Настройките по подразбиране се съхраняват в user.config в местната профил. За да съхраните настройките в профила на роуминга е необходимо да го маркирате с SettingsManageability SettingsManageabilityAttribute атрибут към стойността на роуминга.
• - обикновено низ е посочено в AssemblyCompanyAttribute (възможност по-кратък и замяната на някои от героите. Ако AssemblyCompanyAttribute никога не е използвал, използва линията от друг атрибут.)
• - обикновено низ е посочено в AssemblyProductAttribute (със същите бележки като за име на компанията)
• и - информация за доказателства (произход) на областта на приложение.
• - Обикновено това е версията, посочена в AssemblyVersionAttribute. Използва се за работата на различните версии на работната страна до друга.

Всъщност името на файла е винаги само "user.config".

Защо това е начинът да се user.config zamorochenny?

Алгоритъм за изграждане на пътища трябва да предоставят някои строги изисквания по отношение на защита, изолация и надеждност. Въпреки, че сме се опитали да направят този път, доколкото е възможно, лесни за възприемане, като се използва приятелски определената граница на по заявлението, не е било възможно да се остави толкова елементарно, не е изправен пред конфликт с други приложения, фишинг и т.н.

Може ли по някакъв начин се е променило?

LocalFileSettingsProvider не предвижда метод за промяна на пътя до конфигурационния файл. Моля, имайте предвид, че реалният доставчик и не укажете пътя до конфигурационния файл в първия случай - това е конфигурацията на системата. Ако имате нужда да запишете настройките по някакви причини, на друго място, по препоръчителния начин е да напишете своя SettingsProvider. Нейната доста лесно за изпълнение, примери могат да бъдат намерени в SDK за .NET 2.0. Имайте обаче предвид, че може да се сблъскат с посочените по-горе проблеми на изолация.

Отворих приложението си с помощта Clickonce, и запазва някои настройки, но не мога да намеря user.config на файла.

алгоритъм за съставяне на пътя по-горе не се използва в случай на Clickonce. Вместо това, user.config локални файлове в директорията с данни Clickonce (частта също са включени в пътя). Роуминг user.config ако Clickonce-приложение не се прилага.

Както ми силно въвели свойства са серийно във вид настройка? Не можах да намеря <вставьте ваш тип здесь> поредица правилно.

За настройки сериализация ApplicationSettingsBase да използвате два основни механизма:

1. Ако има TypeConverter, която може да извършва преобразуването на струнни инструменти и низ, тя се използва.
2. В противен случай, XmlSerializer.

Обикновено работи един от тези механизми, но има и видове, за които тези методи не работят. В този случай, имате следните възможности:

• Прилагане за вашия тип TypeConverter, който може да конвертирате от един низ и низ. Изпълнението може да използва всеки подходящ механизъм за сериализиране FW, или свой собствен начин. След това можете да определите това TypeConverter в свойствата на настройките ви клас.
• Въведете необходимата стойност от SettingsSerializeAs, използвайки SettingsSerializeAsAttribute. Например, ако искате да издавам настройката в двоичен формат, посочете SettingsSerializeAs.Binary.

Молбата ми има няколко по поръчка (потребител с обхват) настройки, но Visual Studio ги поставя в app.config. Мислех, че те трябва да бъдат user.config файл?

Системата за конфигурация е йерархична и има следния ред: на машина (машина) -> заявление (молба) -> потребител роуминг (роуминг потребител) -> локален потребител (локален потребител). Когато заявите раздел конфигурация на всяко ниво, можете да получите общ вид на този раздел с това ниво и всички нива долу (на нивото на машина - най-ниската, а местната потребителя - най-високата). раздел процесор определя как сливането, и определянето на приоритети, например конфигурация на локален потребител довереник е по-висок приоритет от този на довереник на кандидатстване.

По този начин, потребителските настройки, по подразбиране се използва, може да бъдат объркани с ценностите на app.config. Когато параметрите се записват в user.config, как нови ценности подменят параметрите по подразбиране. Имайте предвид, че стойностите по подразбиране може да се определи чрез DefaultSettingValueAttribute. Доставчикът ще използва тези стойности, ако няма други ценности не са определени на всяко ниво конфигурация.

Защо имаме нужда от номера на версията на пътя към user.config на файл? Поради това по време на инсталацията на новата версия, потребителите губят всички настройки се съхраняват по-стара версия на приложението.

Има няколко причини, поради които се извършват по пътя към user.config Чувствителен към номера на версията:

1. За да може да разгърне страна до друга няколко версии на едно и също приложение (например, ако използвате Clickonce). Различни версии на приложения могат да използват различни настройки.
2. При подобряването класа на настройките на приложението може да се промени и ще бъде съвместима с настройките записаните по-рано, което може да доведе до проблеми.

Въпреки това, ние сме предвидили възможността лесно прехвърляне на настройките от предишна версия на приложението. Просто се обадете ApplicationSettingsBase.Upgrade () и настройките на предишната версия, които съответстват на настоящата версия на настройките на класа ще бъде записан в текущата версия user.config. Налице е също така възможност за претоварване на тази функционалност в настройките си в класната стая или в изпълнение с вашия доставчик.

ОК, така че как мога да се определи кога да се обадя Подобрете ()?

Добър въпрос. В Clickonce, когато се инсталира новата версия на приложението, ApplicationSettingsBase го открива и се актуализира автоматично настройките. Ако Clickonce не се използва, трябва да се обадите Надстройката () себе си. Това е една възможност, тъй като е възможно да се определи кога да се обадя Подобрете ():

Вземи в настройките CallUpgrade Булева и да го настроите стойността по подразбиране, за да е истина. Когато стартирате приложението, направи нещо като това:

Такъв вариант гарантира, че Upgrade () се нарича само когато първият началото на новата версия.

Има ли начин за достъп до настройките от конфигурационния файл, ако няма съответните настройки класа?

Това е доста мощна функция. Дали е дупка в сигурността? Всеки има достъп до настройките ми без мое знание или разрешение!

Това не е дупка в сигурността по две причини:

1. С по отношение на защита, изолация е снабдена в областта на ниво приложение. Препоръчителна в CLR начин е да използвате ненадежден (ненадежден) код в отделна област на приложение. Когато създавате домейн дадено приложение, можете да определите уникален приятелски и посочете конфигурация заявление файл, за нея. Уникален приятелски гарантира, че областта на приложение ще получи отделен файл потребителските настройки. По този начин, от различен код домейн няма да бъде в състояние да получите достъп до настройките си, тъй като няма достъп до конфигурационния файл. От друга страна, всеки код, който има достъп до файловете за настройка може да се прилага за настройките, дори и без SettingsGroupNameAttribute. например, чрез който и да е API на ниско ниво (макар и тя изисква ConfigurationPermission задачи за четене и малко по-висока за протокола).
2. Ако сте абсолютно параноик и не искат да се даде достъп до настройките без да минава през вашата класа, дори и за код работи в същия домейн, можете да криптирате настройките си, преди да ги прехвърлят на вашия интернет доставчик и декриптиране при четене. Настройки API не предвижда тази специални методи, но можете да използвате Crypto API на рамката за .NET. API за конфигуриране също дава възможност за криптиране на конфигурационни секции - вижте тази статия за повече информация ..

Всичко това означава, че не мога да получите достъп до режим на настройки с частично доверие?

Ни най-малко. извършена от нас работа гарантира, че можете спокойно достъп до настройките си в режим на частично доверие. В действителност, тя ще изглежда, както и четене и писане на вашата кандидатура. Единствената разлика - не можете да пишете неограничено количество данни, по очевидни причини. Броят на байтовете, които можете да запишете чрез API за настройки (LocalFileSettingsProvider) при частично доверие ограничен административен използване IsolatedStoragePermission клас. Т.е. в действителност, както и за изолирани съхранение (изолиран съхранение) като цяло.

Споменахте няколко пъти Configuration API. Какво е това и как да се различава от API за настройки?

Има огромна разлика между API за настройки и API за конфигуриране. Първият осигурява обектен модел за управление на настройките на приложението. Този модел използва схема за опазване от страна на доставчиците, така че действителната икономия е доста абстрактно. Къде се съхраняват настройките, въпросът за прилагането на доставчик - той може да ги съхранявате на суровини, файлове, SQL Server, на системния регистър, или да причинят на отдалечен уеб-услуга. Доставчик на предоставена от употреба подразбиране довереник-файлове, защото това е най-очевидният хранилището за клиентски приложения настройки. По този начин, API Configuration - е по-ниско ниво API, което позволява раздел актуализация конфигурация в конфигурационния файл. В някои отношения Настройки API седи на върха на API за конфигуриране.

Така че, ако имате нужда да се работи с настройките на приложението и потребителски предпочитания, трябва Настройки API. Ако е необходимо да се приложи раздел конфигурация или вижте раздела за конфигурация директно - използвайте API за конфигуриране.

Настройки API е достъпно само в Windows Forms приложения?

Всъщност Настройки API има никакви ограничения - можете да го използвате във всички видове приложения - klientstkih, уеб, VSTO (Visual Studio Tools за Office Developer), конзола, WPF (Windows Presentation Foundation), и т.н. Доставчикът на подразбиране LocalFileSettingsProvider. Той използва конфигурационни файлове в настройките на магазините, което налага някои ограничения. Например, ASP.NET приложения не са user.config файлове, така че не може да спаси потребителски настройки с помощта на този доставчик. Разбира се, можете да използвате Profiles ASP.NET 2.0 за съхраняване на предпочитанията на потребителите. User.config файлове не се поддържат за VSTO-приложения (т.е. там, където ядрото е роден-приложение, като например Outlook, Word или IE). В този случай, ще трябва да напишете своето собствено настройки-доставчик (което, между другото, е съвсем проста, а има и добри примери и документация за MSDN по тази тема) към четене / запис на потребителските настройки. За основните видове управляват клиентски приложения - конзола, Windows Forms и WPF, LocalFileSettingsProvider поддържа напълно.