C# файл конфигурации DLL

Как Marc говорит, это не возможно (хотя Visual Studio позволяет Вам добавлять файл конфигурации приложения в проекте библиотеки классов).

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

ConfigurationManager. AppSettings возвращает настройки, определенные для приложения, не для определенного DLL, можно получить доступ к ним, но это - параметры настройки приложения, которые будут возвращены.

при использовании Вас dll из другого приложения тогда, ConnectionString должен быть в app.settings приложения.

При использовании ConfigurationManager я вполне уверен, он загружает процесс / AppDomain конфигурационный файл (app.config / web.config). Если Вы хотите загрузить определенный файл конфигурации, необходимо будет конкретно попросить тот файл по имени...

Вы могли попробовать:

var config = ConfigurationManager.OpenExeConfiguration("foo.dll");
config.ConnectionStrings. [etc]

Создать файл конфигурации .NET для .DLL нетривиально, и на то есть веские причины. Механизм конфигурации .NET имеет множество встроенных функций, которые упрощают обновление / обновление приложения и защищают установленные приложения от перехвата файлов конфигурации друг друга.

Существует большая разница между тем, как используется DLL, и тем, как используется приложение. Маловероятно, что на одном компьютере будет установлено несколько копий приложения для одного и того же пользователя. Но у вас вполне может быть 100 различных приложений или библиотек, использующих некоторую .NET DLL.

Хотя редко возникает необходимость отслеживать настройки отдельно для разных копий приложения в одном профиле пользователя, это очень маловероятно, что вы захотите, чтобы все различные варианты использования DLL разделяли конфигурацию друг с другом. По этой причине, когда вы получаете объект Configuration с помощью «обычного» метода, возвращаемый вами объект привязан к конфигурации домена приложения, в котором вы выполняете, а не к конкретной сборке.

Домен приложения привязан к корневой сборке, которая загрузила сборку, в которой фактически находится ваш код. В большинстве случаев это будет сборка вашего основного .EXE, который загружает .DLL. В приложении можно развернуть другие домены приложений, но вы должны явно предоставить информацию о том, что является корневой сборкой этого домена приложения.

Из-за всего этого процедура создания файла конфигурации для конкретной библиотеки не выполняется. так удобно. Это тот же процесс, который вы использовали бы для создания произвольного переносимого файла конфигурации, не привязанного к какой-либо конкретной сборке, но для которого вы хотите использовать схему XML .NET, раздел конфигурации и механизмы элементов конфигурации и т. Д. Это влечет за собой создание объект ExeConfigurationFileMap , загружающий данные, чтобы определить, где будет храниться файл конфигурации, а затем вызов ConfigurationManager . OpenMappedExeConfiguration , чтобы открыть его в новом экземпляре Configuration . Это отключит вас от защиты версий, предлагаемой механизмом автоматического создания пути.

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

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

Если вы определенно , вы хотите иметь глобальные настройки для своей DLL независимо от того, где на нее ссылаются , вам нужно будет определить ваше местоположение для него, а не .NET, который автоматически найдет подходящий. Вам также необходимо агрессивно управлять доступом к файлу. Вам нужно будет кэшировать как можно больше, сохранение экземпляра конфигурации ТОЛЬКО на время загрузки или сохранения, открытие непосредственно перед и удаление сразу после. И, наконец, вам понадобится механизм блокировки для защиты файла во время его редактирования одним из приложений, использующих библиотеку.

Похоже, что эти файлы конфигурации действительно сбивают с толку, так как их поведение меняется от среды разработки к развертыванию. Очевидно, у DLL может быть свой собственный файл конфигурации, но как только вы скопируете и вставите dll (вместе с их файлом конфигурации) в другое место, все это перестанет работать. Единственное решение - вручную объединить файлы app.config в один файл, который будет использоваться только exec. Например, myapp.exe будет иметь файл myapp.exe.config, содержащий все настройки для всех dll, используемых myapp.exe. Я использую VS 2008.

Необходимо выполнить отложенное настраиваемое действие для изменения разрешений. Пример настраиваемого действия c #:

[CustomAction]
public static ActionResult SetFolderPermission(Session session)
{
     string folder = session.CustomActionData["Folder"].Trim('\"');
     string sid = session.CustomActionData["SID"].Trim('\"');
     System.Security.Principal.SecurityIdentifier sidID =  new System.Security.Principal.SecurityIdentifier(sid);

     System.Security.AccessControl.DirectorySecurity ds = System.IO.Directory.GetAccessControl(folder);
     ds.AddAccessRule(new System.Security.AccessControl.FileSystemAccessRule(sidID 
                , System.Security.AccessControl.FileSystemRights.Write
                , System.Security.AccessControl.InheritanceFlags.ObjectInherit
                , System.Security.AccessControl.PropagationFlags.NoPropagateInherit
                , System.Security.AccessControl.AccessControlType.Allow));
     System.IO.Directory.SetAccessControl(folder , ds);

     return ActionResult.Success;
}

вы можете перенести это действие на C++, которое должно быть отложено - чем вы должны получить доступ к свойствам сеанса с помощью CustomActionData

Я часто нахожу рекурсивные алгоритмы более простыми для понимания, поскольку они включают менее изменяемое состояние. Рассмотрим алгоритм определения наибольшего общего делителя двух чисел.

unsigned greatest_common_divisor_iter(unsigned x, unsigned y)
{
    while (y != 0)
    {
        unsigned temp = x % y;
        x = y;
        y = temp;
    }
    return x;
}

unsigned greatest_common_divisor(unsigned x, unsigned y)
{
    return y == 0 ? x : greatest_common_divisor(y, x % y);
}

В итеративной версии происходит слишком много переименований на мой вкус. В рекурсивной версии всё незыблемо, так что можно было даже сделать x и y const , если вам понравилось.

если вы хотите прочитать настройки из конфигурационного файла DLL, но не из корневого приложения web.config или app.config используйте следующий код для чтения конфигурации в dll.

var appConfig = ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location);
string dllConfigData = appConfig.AppSettings.Settings["dllConfigData"].Value;

Я знаю, что это поздно, но я решил поделиться решением, которое я использую для DLL.

Я больше придерживаюсь школы K.I.S.S., поэтому, когда у меня есть .NET DLL, которая хочет хранить внешние данные, управляющие ее работой или тем, куда она идет и т.д., я просто создаю класс "config". Я просто создаю класс "config", который имеет только публичные свойства, хранящие все необходимые точки данных, которые я хотел бы иметь возможность контролировать извне DLL, чтобы избежать перекомпиляции для внесения изменений. Затем я использую XML Serializing в .Net для сохранения и загрузки объектного представления класса в файл.

Затем существует множество способов обработки чтения и доступа к нему, от Singleton, статического класса утилиты, до методов расширения и т.д. Это зависит от того, как структурирована ваша DLL и какой метод лучше всего подойдет для вашей DLL.

Поскольку сборка находится во временном кэше, для получения конфига dll следует объединить пути:

var appConfig = ConfigurationManager.OpenExeConfiguration(
    Path.Combine(Environment.CurrentDirectory, Assembly.GetExecutingAssembly().ManifestModule.Name));