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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

затем я создал ссылку на Настройки.настройки из Proj2 с помощью ctrl+shift + перетаскивание файла в Proj1 (как в статье блога, на которую ссылается Kildareflare).

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

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

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

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

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

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("Proj1")]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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