Если app.config для DLL должен находиться в "главной конфигурации"... что мы будем делать с ссылками WCF в DLL? - программирование
Подтвердить что ты не робот

Если app.config для DLL должен находиться в "главной конфигурации"... что мы будем делать с ссылками WCF в DLL?

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

Здесь сделка:

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

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

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

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

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

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

4b9b3361

Ответ 1

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

Ответ 2

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

Ответ 3

Нет, ты прав.

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

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