Если app.config для DLL должен быть в «основном конфиге»… что нам делать с ссылками WCF в DLL?

Question

Хорошо, это довольно просто, но из того, что я видел ... вы можете использовать какой-то вид рабочего процесса Windows только для включения другой конфигурации в другую (что я отказываюсь делать).

Вот сделка:

MAINAPP.EXE Ссылки на гипотетическую LIBRARY.DLL.

MAINAPP.EXE имеет свой собственный MAINAPP.EXE.config.

Если вы добавите «значения конфигурации» в LIBRARY.DLL (тем самым создавая app.config в проекте LIBRARY.DLL), эти значения не доступны во время выполнения , даже если вы копируете приложение. Конфигурация в LIBRARY.DLL.config по правильному пути после сборки .

Причина вышеизложенного заключается в том, что даже библиотеки, на которые есть ссылки, будут считывать данные из конфигурации "mainapp.exe".

Пока "так хорошо". Теперь, когда вы добавляете ссылку на службу WCF, Visual Studio создает или заполняет ваш app.config привязками / конечными точками / и т. Д .; но это добавлено в проект, где вы добавили конфиг ссылки; следовательно, ваш Library.DLL.prj заканчивается красивым app.config, который не работает , потому что он никогда не читается и даже не копируется в выходной каталог. Теперь вы можете подумать, что вы можете щелкнуть правой кнопкой мыши по этому app.config и установить для параметра «всегда копировать» значение true. Забудь это. Это ничего не делает. (Вы можете Google для этого).

Итак, учитывая вышеприведенный странный сценарий, как обычный разработчик VS2008, работающий с проектом .NET 3.5, собирается управлять ссылками на службы WCF, которые он добавляет в свою DLL бизнес-уровня? Предполагается ли, что разработчик копирует и вставляет весь раздел от бесполезного app.config в своей DLL в файл Mainapp.exe.config каждый раз, когда происходит изменение в службах или каждый раз, когда он добавляет / удаляет один ?

Answer 1

Да. Скопируйте и вставьте ответ. Это не очень хороший ответ, но это ответ, и он был с первого дня в .NET 1.0 с AppSettings.

Answer 2

У вас может быть проект библиотеки, включающий настраиваемые файлы конфигурации, и эти файлы можно скопировать в исполняемый каталог другого приложения (это немного сложно, но не слишком сложно). Вам просто нужно использовать OpenMappedExeConfiguration, чтобы получить любую информацию в этих файлах. Затем вам нужно будет выполнить какое-то пользовательское кодирование при создании экземпляров прокси-серверов WCF (создание экземпляра Binding и передача его прокси-серверу). Я опаздываю на вечеринку, но могу сообщить больше подробностей, если вам интересно.

Answer 3

Нет, ты прав.

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

Или, конечно, вы пишете хосты пользовательских сервисов и помещаете минимальный объем информации в файл конфигурации (имя хоста, отпечаток сертификата) и делаете все остальное в коде.