Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

Я добавил шаг после сборки в проект потребления (Proj1 в примере), чтобы скопировать файл конфигурации из выходной папки Proj2. Это гарантирует, что в конфигурации будут применены преобразования. (В моем случае Proj1 является dll, поэтому, если ваш exe, измените DestinationFiles с ".dll.config" на ".exe.config".) Snippet из 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).

Затем я мог бы ссылаться на настройки в Proj1, похожие на: Proj2.Properties.Settings.Default.MySetting.

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

Ответ 5

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

От: С# "внутренний" модификатор доступа при выполнении модульного тестирования

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

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("Proj1")]

Ответ 6

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

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

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

Исходный текст ниже:

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

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

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

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

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

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

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

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

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

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

пространство имен WinApp {   открытый частичный класс Form1: Форма   {       public Form1()       {           InitializeComponent();       }

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

}