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

Question

В проекте VB.Net вы можете использовать вкладку «Настройки» на странице свойств для определения настроек приложения. Для ссылки на настройки в коде вы используете синтаксис My.Settings.SettingName в VB.

На вкладке «Настройки» вы можете выбрать модификатор доступа. Это может быть «Друг» или «Публичный». Предположительно, когда вы выбираете «Public», вы делаете настройки доступными для других сборок. Однако после выбора «Public» я не могу понять синтаксис для ссылки на настройки одного проекта из другого. На самом деле, я не вижу никакой разницы между использованием «Internal» и «Public» в качестве модификатора доступа.

Мой вопрос: выбор «Public» в качестве модификатора доступа делает настройки доступными для других сборок? Если да, то каков синтаксис для ссылки на настройки из других сборок? Если нет, то что делает «Public»?

Answer 1

Вы плохо все путаете.У настройки нет модификатора доступности, они всегда общедоступны.Однако в приложении Winforms у вас действительно есть свойство «Настройки приложения» в окне «Свойства» для элемента управления.Прямо наверху.И свойство Модификатор.Последний является Friend по умолчанию в проекте VB.NET, Private в приложении C #.Это определяет доступность переменной control , а не настройки.

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

Настройки с областью действия пользователя хранятся в файле, который трудно найти.Типичный путь к такому файлу: C: \ Users \ hpassant \ AppData \ Local \ WindowsFormsApplication1 \ WindowsFormsApplication1._Url_2acx4ldi2zmg42elj3eyqq0snhqco4qe \ 1.0.0.0

Первая часть - это я, нынешний пользователь моего ноутбука.Необычной частью имени пути является хеш , значение, уникальное для имени и версии приложения.И, возможно, что-то еще, например, фаза луны, когда я компилировал приложение.Алгоритм вычисления этого хэша не документирован.Только то, что оно будет уникальным для моего приложения и не может быть запущено другим приложением.

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

Answer 2

Я искал то же самое, вот оно:
В C #:
[Пространство имен] .Properties.Settings.Default. [SettingName]
В VB:
[Пространство имен] .My.MySettings.Default. [SettingName]

Answer 3

Это немного сложнее в VB.NET, чем в C #. Это происходит главным образом потому, что в VB.NET пространство имен не так уж сильно сфокусировано. Поэтому в рамках решения VB.NET весьма распространено - хотя, возможно, и не очень хорошая практика - иметь одно и то же корневое пространство имен (по умолчанию) для всех проектов / узлов в решении, например:

MyNamespace.Main, MyNamespace.ClassLib1, MyNamespace.ClassLib2, MyNamespace.Common, etc.

Из-за этого метод доступа к межпроектным настройкам, описанный в другом месте в этом вопросе, падает.

Предлагаемый способ доступа к настройкам в ссылочном проекте в VB.NET:

1. Сделать модификатор доступа Settings Public,
2. Доступ к настройке (только для чтения) с помощью {MyNamespace}.My.MySettings.Default.{MySetting}.

Обратите внимание, что My.MySettings является свойством MyNamespace напрямую, , а не имени сборки.

Только , если пространство имен подсборки отличается от пространства имен ссылающегося проекта, у вас будет доступ к MySetting. Если пространства имен одинаковы, его просто не видно, и я не могу найти способ добраться до него. (Я мог бы покопаться в ILM и, возможно, выяснить, что делает компилятор, чтобы избежать конфликта - что, вероятно, могло бы иметь место, - но это спорный вопрос.)

Я проверял это в C # .NET и VB.NET. Разграничите свои корневые пространства имен - если это возможно - и вы получите радость.

Answer 4

Вот пример кода для получения значения параметра с именем DataBaseName любого .exe, расположенного рядом с нашим исполняемым приложением, и сохранения его в переменной "dbName":

string currentDirectory = System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string exeName = System.IO.Path.GetFileName(Assembly.GetExecutingAssembly().Location);
FileInfo[] fileInfos = new DirectoryInfo(currentDirectory).GetFiles("*.exe");
foreach (FileInfo fi in fileInfos)
{
    if (fi.FullName == System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)) continue;

    Assembly asm = Assembly.LoadFrom(fi.FullName);
    Type[] allTypes = asm.GetTypes();
    foreach (Type type in allTypes)
    {
        if (type.Name != "Settings") continue;
        Type settingsType = type;

        PropertyInfo propDefault = type.GetProperty("Default");
        object defaultSettings = propDefault.GetValue(null, null);
        PropertyInfo piDBName = settingsType.GetProperty("DataBaseName");
        string dbName = (string)piDBName.GetValue(defaultSettings, null);

        break;
    }

    break;
}

Answer 5

Я думаю, что вы можете передать экземпляр объекта настроек из одной DLL в другую DLL (скажем, при запуске приложения), а затем получить доступ к настройке, используя свойство Item этого класса (Классы настроек являются классом, унаследованным от ApplicationSettingsBase)

'В DLL1: настройки общего свойства Class1FromAnotherDLL As ApplicationSettingsBase ...

' В DLL2: (сделано при запуске) Class1.SettingsFromAnotherDLL = My.Settings.Default

'В DLL2, когдадоступ к настройкам Dim Setting As STring = Class1.SettingsFromAnotherDLL.Item ("SettingKey")