Доступ к файлу настроек другого проекта - PullRequest
39 голосов
/ 31 марта 2010

Есть ли способ получить доступ к файлу настроек из другого проекта? Например, у меня есть решение, которое содержит 2 проекта (назовем их Proj1 и Proj2). Я хочу получить доступ к настройкам приложения Proj2 из Program.cs в Proj1. Возможно ли это?

Ответы [ 6 ]

49 голосов
/ 13 марта 2011

Ответ, если вы используете C #:
Очень простой ответ - щелкните правой кнопкой мыши на proj2, выберите вкладку настроек. Вверху вы найдете модификатор доступа класса настроек: internal, измените его на public. Добавьте ссылку на proj2 в proj1, чтобы увидеть класс настроек proj2. Вот и все.

32 голосов
/ 31 марта 2010

Вариант A: проанализировать значения из файла конфигурации другой сборки (где хранятся настройки)

Опция B: создать открытый класс в Proj2, который предоставляет необходимые значения из своих настроек в качестве статических свойств, затем ссылается на сборку в Proj1 и использует значения из этого класса.

Вариант C: если вы хотите выставить ВСЕ настройки, вы можете изменить доступ к классу настроек с internal до public.

Я уверен, что есть и другие способы.

4 голосов
/ 09 декабря 2015

Я опубликую содержание ссылки @ Kildareflare для дальнейшего использования. Все еще работает в VS2015, но для себя, я думаю, я предпочитаю «Вариант B» выше.

Получение доступа к настройкам в другом проекте

Одной из новых интересных функций Visual Studio 2005 является новый редактор свойств. С помощью этого редактора свойств вы можете легко добавить настройки в ваше приложение. Но есть проблема в том, как это реализовано. Позвольте мне объяснить вам, почему.

Обычно настройки относятся к конкретному проекту. Когда вы добавляете параметр в проект, специальный пользовательский инструмент, связанный с файлом настроек, генерирует новый класс, который вы можете использовать для доступа к нему. Что хорошо в этом классе, так это его строгий тип. Но за кулисами это просто получение ключа из XML-файла. Этот сгенерированный класс установлен как «внутренне запечатанный». Это предотвращает доступ из любой другой сборки. Что делать, если вы хотите централизовать, где вы редактируете эти настройки.

После многих попыток разоблачить его я нашел быстрый и легкий способ сделать это. Допустим, у нас есть 2 проекта в нашем решении: Engine и WinApp. У каждого есть настройки, но мы хотим, чтобы они были редактируемыми из WinApp. Вот как это выглядит.

Settings Before

Если вы хотите получить доступ к настройкам движка, вот хитрость: добавьте файл ссылки.

Add Link

Файл ссылки будет скомпилирован как часть вашего проекта WinApp. Класс настройки будет по-прежнему внутренним и закрытым, но для проекта WinApp вместо Engine.

Вот окончательный результат:

Settings After

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

Имея это, вы можете получить доступ к своему движку, определяя путь от вашего класса движка как от вашего класса WinApp. Вы можете опустить часть «Engine» в вашем классе двигателя, потому что вы должны находиться в том же пространстве имен. Вот как это должно выглядеть:

namespace WinApp
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        public void AccessConfig()
        {
            Engine.Properties.Settings.Default.EngineSetting = "test";
        }
    }
}
0 голосов
/ 31 октября 2017

Поскольку Settings.Designer.cs является классом internal, и вы не хотите связываться с сгенерированным файлом кода, я бы порекомендовал добавить вторичное устройство в качестве "друга" проекта.

From: C # «внутренний» модификатор доступа при выполнении юнит-тестирования

Добавьте следующий код к Proj2 's AssemblyInfo.cs

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("Proj1")]
0 голосов
/ 09 апреля 2014

Мне пришлось придумать другое решение, помимо уже приведенного здесь, потому что я использовал XML Tranforms (через SlowCheetah) в App.config моего проекта, содержащего настройки.Если вы этого не делаете, я рекомендую одно из других решений.

Я добавил шаг после сборки в потребляющем проекте (в примере Proj1), чтобы скопировать файл конфигурации из выходной папки Proj2.Это гарантирует, что в конфигурации будут применены преобразования.(В моем случае Proj1 - это dll, поэтому, если у вас exe, измените DestinationFiles с ".dll.config" на ".exe.config".) Фрагмент из Proj1.csproj:

<Target Name="AfterBuild">
  <Copy SourceFiles="..\Proj2\bin\$(Configuration)\Proj2.exe.config" DestinationFiles="$(TargetDir)\$(AssemblyName).dll.config" />
</Target>

Затем я создал ссылку на файл Settings.settings из Proj2, нажав Ctrl + Shift +, перетащив файл в Proj1 (как в статье блога, на которую ссылается Kildareflare).

Тогда я мог бы ссылаться на настройки в Proj1to: Proj2.Properties.Settings.Default.MySetting.

Примечание: если вы делаете это для модульных тестов, как я (Proj1 - это тестовая DLL), и вы используете тестовый прогон ReSharper, обязательно сконфигурируйте егозапускать тесты в отдельных доменах приложений .

0 голосов
/ 11 мая 2011

Я сам не тестировал этот метод, но вам может пригодиться маленький трюк Эрика де Каруфеля:

http://blog.decarufel.net/2007/10/getting-access-to-settings-in-another.html

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

Оригинальный контент ниже:

Получение доступа к настройкам в другом проекте

Четверг, 25 октября 2007 г.

Одной из новых интересных функций Visual Studio 2005 является новый редактор свойств. С помощью этого редактора свойств вы можете легко добавить настройки в ваше приложение. Но проблема заключается в том, как это происходит. Позвольте мне объяснить вам, почему.

Обычно настройки относятся к конкретному проекту. Когда вы добавляете параметр в проект, специальный пользовательский инструмент, связанный с файлом настроек, генерирует новый класс, который вы можете использовать для доступа к нему. Что хорошего в этом классе, так это его строгая типизация. Но за кулисами он просто получает ключ из XML-файла. Этот сгенерированный класс установлен как «внутренне запечатанный». Это предотвращает доступ к любой другой сборке. Что делать, если вы хотите централизовать, где вы редактируете эти настройки.

После многих попыток разоблачить его я нашел быстрый и легкий способ сделать это. Допустим, у нас есть 2 проекта в нашем решении: Engine и WinApp. У каждого есть настройки, но мы хотим, чтобы они были редактируемыми из WinApp. Вот как это выглядит.

Если вы хотите получить доступ к настройкам движка, вот вам хитрость: Добавьте файл ссылки.

Файл ссылки будет скомпилирован как часть вашего проекта WinApp. Класс настройки будет по-прежнему внутренним и закрытым, но для проекта WinApp вместо Engine.

Вот окончательный результат:

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

Имея это, вы можете получить доступ к своему движку, устанавливая путь от вашего класса движка как от вашего класса WinApp. Вы можете опустить часть «Engine» в вашем классе двигателя, потому что вы должны находиться в том же пространстве имен. Вот как это должно выглядеть:

namespace WinApp
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        public void AccessConfig()
        {
            Engine.Properties.Settings.Default.EngineSetting = "test";
        }
    }
}
...