У нас было редкое исключение, происходят при чтении стандартных пользовательских настроек .NET (это - те найденные в "свойствах проекта" в VS 2008):
System.Configuration.ConfigurationErrorsException was caught
Message="Configuration system failed to initialize"
Source="System.Configuration"
BareMessage="Configuration system failed to initialize"
Line=0
StackTrace:
at System.Configuration.ConfigurationManager.PrepareConfigSystem()
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
at System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()
at System.Diagnostics.DiagnosticsConfiguration.Initialize()
at System.Diagnostics.DiagnosticsConfiguration.get_IndentSize()
at System.Diagnostics.TraceInternal.InitializeSettings()
at System.Diagnostics.TraceInternal.get_Listeners()
InnerException: System.Configuration.ConfigurationErrorsException
Message="Unexpected end of file has occurred. The following elements are not closed: setting, SettingsTest.Properties.Settings, userSettings, configuration. Line 7, position 1. (C:\\Documents and Settings\\USER\\Local Settings\\Application Data\\Hitcents\\SettingsTest.vshost.exe_Url_ghwhc20utv4toanuinmj0pfsljthcugo\\1.0.0.0\\user.config line 7)"
Source="System.Configuration"
BareMessage="Unexpected end of file has occurred. The following elements are not closed: setting, SettingsTest.Properties.Settings, userSettings, configuration. Line 7, position 1."
Filename="C:\\Documents and Settings\\USER\\Local Settings\\Application Data\\Hitcents\\SettingsTest.vshost.exe_Url_ghwhc20utv4toanuinmj0pfsljthcugo\\1.0.0.0\\user.config"
Line=7
StackTrace:
at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
at System.Configuration.ClientConfigurationSystem.OnConfigRemoved(Object sender, InternalConfigEventArgs e)
InnerException: System.Xml.XmlException
Message="Unexpected end of file has occurred. The following elements are not closed: setting, SettingsTest.Properties.Settings, userSettings, configuration. Line 7, position 1."
Source="System.Xml"
LineNumber=7
LinePosition=1
SourceUri=""
StackTrace:
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String arg)
at System.Xml.XmlTextReaderImpl.ThrowUnclosedElements()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlTextReader.Read()
at System.Xml.XmlTextReaderImpl.Skip()
at System.Xml.XmlTextReader.Skip()
at System.Configuration.XmlUtil.StrictSkipToNextElement(ExceptionAction action)
at System.Configuration.BaseConfigurationRecord.ScanSectionsRecursive(XmlUtil xmlUtil, String parentConfigKey, Boolean inLocation, String locationSubPath, OverrideModeSetting overrideMode, Boolean skipInChildApps)
at System.Configuration.BaseConfigurationRecord.ScanSectionsRecursive(XmlUtil xmlUtil, String parentConfigKey, Boolean inLocation, String locationSubPath, OverrideModeSetting overrideMode, Boolean skipInChildApps)
at System.Configuration.BaseConfigurationRecord.ScanSections(XmlUtil xmlUtil)
at System.Configuration.BaseConfigurationRecord.InitConfigFromFile()
InnerException:
*ПРИМЕЧАНИЕ: это воссоздается из тестового приложения.
Я потянул user.config файл, и половина из него отсутствовала.
Я ожидаю, что наше приложение было завершено резко по некоторым причинам или другой.
Это кажется очень редким, вот то, как мы взаимодействуем с настройками:
//How we read
Settings settings = Settings.Default;
_ourStaticMemberVariable = settings.OurValue;
//How we save
Settings settings = Settings.Default;
settings.OurValue = "Our Value";
settings.Save();
Есть ли что-то не так с тем, как мы используем его? Оба вызова имеют выгоду попытки, которые помещают некоторые значения по умолчанию, но значения должны смочь сбросить из нашего приложения.
Когда в этом состоянии, наше приложение не может сохранить новые настройки - и я не могу выяснить хороший способ программно восстановиться. Я должен был вручную найти user.config и удалить его.
Я также пытался назвать Настройки. Сброс (), и т.д. но получают то же исключение.
Какие-либо идеи о том, как зафиксировать это? Или действительно ли мы - более обеспеченная запись нашей собственной системы настроек или сохранение персистентных настроек в другом отношении?
Править: Обходное решение должно удалить файл из кода, если Вы получаете ConfigurationErrorsException.
Кто-либо знает, как получить полный путь user.config файла?
Спрашивается здесь: C #: Загрузка URL-адреса с тайм-аутом
Простейшее решение:
public string GetRequest(Uri uri, int timeoutMilliseconds)
{
var request = System.Net.WebRequest.Create(uri);
request.Timeout = timeoutMilliseconds;
using (var response = request.GetResponse())
using (var stream = response.GetResponseStream())
using (var reader = new System.IO.StreamReader(stream))
{
return reader.ReadToEnd();
}
}
Лучшее (более гибкое) решение - этот ответ на тот же вопрос, в виде класса помощника WebCleyWityTimeout
.
Способ программного восстановления состоит в том, чтобы сделать то, что вы сделали вручную - удалить файл пользовательских настроек. Затем вызовите Settings.Reset
. (Вы также можете написать новый файл пользовательских настроек со значениями по умолчанию вместо удаления, но если вы используете диспетчер конфигурации правильно, это по существу то же самое.)
Это довольно редкое явление, но это не совсем неслыханно. При записи файла пользовательских настроек может произойти сбой не только программы, но и самого файла, который может быть записан пользователем, поэтому другие программы, которые пользователь запускает, могут испортить его.
Чтобы избежать этой конкретной уязвимости, сохраняйте пользовательские настройки в долговременном хранилище с транзакционной целостностью, т.е. в базе данных. (У вас все еще будут уязвимости, только не эта.) Это большая работа для того, что в большинстве случаев будет незначительным повышением надежности. Но «в большинстве случаев» не означает «во всех случаях;» ваши могут это оправдать.