В некоторых случаях службы и клиенты удобно реализовывать в виде отдельных DLL, которые затем могут быть использованы различными приложениями. Например: MyService.dll и MyClient.dll. Предполагается, что они будут находиться в подкаталогах ./Extensions/MyExtensionName/ хостовых приложений, дабы при необходимости оный контент всегда можно было бы просто удалить даже вручную, не зацепив при этом случайно ресурсы основного приложения.
Однако, будучи подгруженными в хостовое приложение они, как и любые другие DLL, по умолчанию будут искать свои настройки в составе конфигурационного файла этого приложения. Всё же мне бы не хотелось в чужой config-файл вносить правки, необходимые для работы моих сервисов или клиентов, ну или хотелось бы, по крайней мере, минимизировать объём таких корректировок настолько, насколько это возможно... На мой взгляд, предпочтительным способом была бы возможность сохранения нужных мне настроек в отдельных конфигурационных файлах, находящихся рядом с соответствующей DLL моего сервиса или клиента, т.е. в файлах MyService.dll.config и MyClient.dll.config.
Экспорт конфигурационных настроек на стороне сервиса
Начиная с .NET 4.5 в классе реализации сервиса можно определить метод Configure со следующей сигнатурой:
public static void Configure(ServiceConfiguration config)
Этот метод будет вызван WCF перед началом использования нашей службы. В нём можно выполнить загрузку конфигурационных настроек из внешнего файла, например так:
public static void Configure(ServiceConfiguration config) {
ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
configMap.ExeConfigFilename = typeof(MyService).Assembly.Location + ".config";
Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
ConfigurationUserLevel.None);
config.LoadFromConfiguration(dll_config);
}
Однако в бочке мёда имеется и ложка дёгтя: в процессе импорта настроек WCF будет игнорировать все базовые адреса, обозначенные в импортируемом файле. Соответственно, либо эти базовые адреса нужно будет предварительно указать в конфигурационном файле самого хостового приложения (чего делать не очень хотелось бы, хотя это и не смертельно), либо в составе импортируемого файла настроек для конечных точек подключения и для метаданных использовать только полные адреса. Какой из вариантов выбрать - это уже нужно будет смотреть по ситуации.
Например, если расширение хранится в каталоге %AppData%/CompanyName/ApplicationName/Extensions/MyExtensionName/ с тем, чтобы предоставлять пользователю возможность править конфигурационные настройки или вовсе удалять расширение, то нужным вариантом будет второй.
А если пользователь не имеет административных прав и расширение хранится в каталоге %ProgramFiles%/CompanyName/ApplicationName/Extensions/MyExtensionName/, то в данном случае вариант использования - это дело вкуса администратора.
Экспорт конфигурационных настроек на стороне клиента
На стороне клиента использовать метод Configure в коде наших прокси не получится, но начиная с WCF 4.0 нам в помощь появился класс ConfigurationChannelFactory. Его можно создать в конструкторе создаваемого нами прокси и использовать в процессе работы например так:
[ServiceBehavior(IncludeExceptionDetailInFaults
= true)]
public class Drawing : IDisposable, IDrawing {
IDrawing Channel;
ConfigurationChannelFactory<IDrawing>
channelFactory;
public void Open() {
if (channelFactory.State != CommunicationState.Opened &&
channelFactory.State
!= CommunicationState.Opening)
channelFactory.Open();
}
public void Close() {
if (channelFactory.State == CommunicationState.Opened)
channelFactory.Close();
}
public CommunicationState State
{
get { return channelFactory.State; }
}
public Drawing(string endpointName) {
ExeConfigurationFileMap configMap = new ExeConfigurationFileMap();
configMap.ExeConfigFilename = typeof(Drawing).Assembly.Location
+ ".config";
Configuration dll_config = ConfigurationManager.OpenMappedExeConfiguration(configMap,
ConfigurationUserLevel.None);
channelFactory =
new ConfigurationChannelFactory<IDrawing>(endpointName,
dll_config, null);
Channel =
channelFactory.CreateChannel();
}
public void Dispose() {
if (channelFactory != null
&& channelFactory.State == CommunicationState.Opened)
channelFactory.Close();
}
//
here is other members...
}
Обратите внимание на то, что в процессе реализации нужного нам прокси мы обошлись без наследования от класса ClientBase.
Ссылки:
Комментариев нет:
Отправить комментарий