Конфигурирование WCF-сервиса для передачи файлов, как и где это сделать?

#c_sharp #wcf #config #configuration

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

Предварительно была изучена теория, и выяснено, что файлы можно передавать:


Как есть, без предварительной настройки, разве что, выставив
maxMessageLengthи executionTimeoutInSeconds в довольно большие
значения.
Включить MTOM в качестве кодировщика.
Включить стриминг (потоковую передачу данных).


Точный размер передаваемых файлов я не знаю, но зато могу сказать, что на текущем
этапе вряд ли будут передаваться большущие файлы типа дампов БД или потокового видео. 
Но всё же, в стандартном подходе меня смущает то, что будет постоянная сериализация-десереализация
файлов в XML, а зачем лишние телодвижения?

Включение стриминга, в принципе, сейчас подходит, но, как говорит MSDN, будет ряд
ограничений (связаны с шифрованим и буферизацией, подробнее — в статье), из-за которых,
цитирую:


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


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

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

Итак, в качестве пути решения был выбран проект WCF Service Library, в котором был
объявлен интерфейс службы, примерно так:

[ServiceContract]
public interface IUpdaterService
{
    [OperationContract]
    bool TestConnection();
    ... 
    [OperationContract]
    FileStream DownloadFile(string filename);
    ...
}


Ага, тут я использую FileStream, значит нужно включить поддержку стриминга, но сложность
в том, что я попросту не знаю, где и как это сделать. То же самое и с включением MTOM.

Ну, например, в попавшихся мне решениях говорят, "измените конфиг так":




    
        
            
        
    
    
        
    





Вроде всё понятно, что менять и на что, но где это делать?

Напоминаю, у меня DLL, в которой есть лишь App.config, и он - следующий:






  


  
  


  
    
      
        
          
        
      
      
      
        
          
        
      
    
  
  
    
      
        
        
      
    
  





Т.е. по сути, в App.config нет, например, раздела bindings, где можно было бы изменить
эти параметры.
При запуске родного WCF Test Client метод DownloadFile не доступен, так как используется
тип FileStram, стало быть, протестировать его никак...

Конфиг клиента, в свою очередь, формируется такой, нужно, т.е. как раз с теми разделами,
которые можно менять:




    
        
            
        
    
    
        
    





Но опять же - возникает вопрос - а где и как менять этот конфиг? Уверен, он генерируется
автоматически, т.е. необходимо задать нужные параметры для моей DLL, но как верно это
сделать? К сожалению, ответа на этот вопрос пока не нашел (может, плохо искал, конечно).

Спасибо.
    

Ответы

Ответ 1

Начну с конфигов.

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

Файлы конфигурации бывают только у исполнимых файлов и у веб-сайтов.

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

Секция bindings используется на обоих сторонах соединения - т.е. и клиентом, и сервером.
Но она опциональна - без нее будут браться настройки по умолчанию. Если вам надо поменять
там настройки, но ее нет - значит, ее надо создать.

На разные привязки (bindings, "биндинги") ссылаются конечные точки (endpoint) через
атрибуты binding и bindingConfiguration. Когда будете создавать свои привязки - не
забудьте про эту связь, чтобы не удивляться потом что ничего не изменилось.



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

По-меньше думайте "как сделать чтобы никогда не надо было переписывать" - а по-больше
"какова моя задача сейчас?"

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

Шифрование на транспортном уровне не является проблемой если только вы не работаете
с интеграционными шинами.

Как лучше работать с конфигурациями в Ruby

#ruby #config #configuration #best_practice

Допустим, у нас есть некая структура конфигурации (взята из YAML, JSON, XML или просто
в виде Hash):  

configuration = {
  gmail: {
    username: 'example@gmail.com',
    password: 'pa$$word',
    host: 'imap.gmail.com',
    ssl: true,
    port: 993
  },
  ftp: {
    username: 'example@gmail.com',
    password: 'pa$$word',
    host: 'imap.gmail.com',
    ssl: true,
    port: 42
  }
}


Далее, на основе этой структуры мы достаём из неё данные:  

mail = Mail.new host: configuration[:gmail][:host], port: configuration[:gmail][:port],
username: configuration[:gmail][:username], password: configuration[:gmail][:password],
ssl: configuration[:gmail][:ssl]
ftp = FTP.new host: configuration[:ftp][:host], port: configuration[:ftp][:port],
username: configuration[:ftp][:username], password: configuration[:ftp][:password],
ssl: configuration[:ftp][:ssl]


Всё работает, но сам код получается «плохочитаемым». 
Т. е. он конечно понятен, но слишком много «сухого» текста, вместо привычного для
языка программирования кода.  

Поделитесь Best Practice, как правильно делать и использовать конфигурации в Ruby.
    

Ответы

Ответ 1

Если имена атрибутов Mail и FTP в вашем примере в точности соответствуют ключам в
структурах в конфигурации - вы можете передавать в конструктор хеш напрямую:

mail = Mail.new configuration[:gmail]
ftp = FTP.new configuration[:ftp]


Здесь важно помнить две вещи:


Ключи и типы значений в конфигурации должны совпадать с атрибутами и типами значений
атрибутов класса;
Доступ к конфигурации должен быть только у вас - иначе злоумышленник может, оперируя
структурой, создавать объекты с любыми атрибутами класса без ограничений.


Ответ 2

Ну, как минимум вы написали выбор поднабора из хэша с захардкоженными ключами. "Колонна"
в вашем коде (которая получается, если код "подровнять"):

mail = Mail.new     host: configuration[:gmail][:host],
                    port: configuration[:gmail][:port],
                username: configuration[:gmail][:username],
                password: configuration[:gmail][:password],
                     ssl: configuration[:gmail][:ssl]
#               ^^^^^^^^^^^^^^^^^^ это ^^^^^^^^^^^^^^^^^^^^


...на самом деле же просто хэшмап. Просто {} вокруг него писать оказалось необязательно,
т. к. это последний аргумент вызова метода, и это особый случай в синтаксисе Ruby.

Если в configuration[:gmail] нет лишних ключей, то можно сделать попросту вот так:

Mail.new configuration[:gmail]


...а если лишние ключи хочется отрезать, и вы вооружены aсtivesupport'ом (гем такой,
из состава Rails), есть Hash#slice:

# Точечная загрузка ActiveSupport
require 'active_support/core_ext/hash/slice'
# В Rails необязательно, там он обычно весь уже загружен

Mail.new configuration[:gmail].slice(:host, :port, :username, :password, :ssl)


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

Это не конвенция, такая ситуация сложилась сама и она всех устраивает.

"Best bractices" конфигураций, которые вы ждёте, этого всего в основном не касаются
и они запакованы, в разных комбинациях, в гемы dotenv, figaro и config. Что в них типично
встречается:


Сокращённый синтаксис получения конфигурации ключей: a[:b][:c] => a.b.c
Фоллбэк (когда конфига нет) к переменным среды в ENV (см. 12-факторные приложения)
Конвенции по размещению конфигурационных файлов и их формату — кто на что горазд

git и конфигурационные файлы

Расскажите, кто и как решает проблему хранения конфигурационных файлов в git?

Полностью исключать их нельзя, так как проект может не собраться и/или не запуститься
В тоже время в таких файлах, как правило, хранится частная информация (данные для авторизации на внешних сервисах и т.д.).

Сейчас я размещаю в git файлы с расширением .sample (например Web.config.sample ил
config.yml.sample) и пишу в документации, что перед тем как запустить проект, необходимо переименовать sample-файл и заполнить его правильными значениями. Сами конфигурационные файлы я добавляю в  .gitignore.

Недостатки такого подхода:


необходимо постоянно синхронизировать sample-файл c оригинальным конфигурационным файлом (добавились/изменились/удалились опции),
другим пользователям нужно сделать дополнительное действие (переименовать файл)
что они могут забывать делать (кто же читает документацию?)


Возможно существуют и более удачные решения. Можно ли c git придумать что-то более удобное?
    

Ответы

Ответ 1

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

Добавление обязательных конфигурационных опций на ходу - плохая идея, по крайне
мере между major-версиями. Они должны иметь свое значение по умолчанию, при которо
приложение продолжает вести себя так же, как и раньше. Все эти -webkit-something-tralal
в CSS появились ровно оттуда же - давайте добавим эту штуку, но не будем ее пихать как готовую опцию, когда будем готовы к внедрению - внедрим, чтобы она точно не переименовывалась и не менялась потом (конкретно в CSS имена задаются стандартом, но общая идея должна быть ясна).  

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

Еще одна штука, которая помогает - это "параллельные" файлы, в которых переопределяютс
значения: configuration.yml содержит в себе некоторую конфигурацию, а configuration.local.yml - всего пару опций, который "берут верх" над аналогичными опциями из configuration.yml.


Ответ 2

На эту тему высказались авторы манифеста 12 factors.

Вот что они пишут о конфигурации:


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


Далее:


  Другим подходом к конфигурации является использование конфигурационных файлов
которые не сохраняются в систему контроля версий, например, config/database.yml в Rails
Это огромное улучшение перед использованием констант, которые сохраняются в коде, н
по-прежнему и у этого метода есть недостатки: легко по ошибке сохранить конфигурационный файл в репозиторий; существует тенденция, когда конфигурационные файлы разбросаны в разных местах и в разных форматах, из за этого становится трудно просматривать и управлять всеми настройками в одном месте.


Это как раз способ, который описан в вопросе. Авторы манифеста предлагают такое решение:


  Приложение двенадцати факторов хранит конфигурацию в переменных окружения (част
сокращается до env vars или env). Переменные окружения легко изменить между развёртываниями
не изменяя код; в отличие от файлов конфигурации, менее вероятно случайно сохранить их в репозиторий кода; и в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и операционной системы стандартом.


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

От себя добавлю, что Azure-приложения ASP.NET и ASP.NET WebAPI сейчас настраиваютс
именно так: в панели приложения на вкладке Application settings можно указать переменные окружения. Тоже самое в Heroku.

Пример

В нашем проекте требуется рассылать электронные письма и СМС. Естественно, на локальны
контурах разработчиков и на общем контуре разработки ничего рассылать не надо, но пр
этом нужен доступ к содержимому уведомлений. То есть разработчики должны видеть, что служба уведомлений сработала, и видеть, что именно будет отправлено клиенту на боевом контуре.

Поскольку мы используем внедрение зависимостей, мы сделали несколько реализаций классов
рассылающих уведомления. Продуктовая реализация осуществляет отправку писем, а реализаци
разработчиков пишет уведомления в файл. В качестве библиотеки IoC мы используем Autofac, который позволяет регистрировать зависимости в конфигурационном файле, так что в нашем Web.config была зарегистрирована служба уведомлений для разработчиков. 

MSBuild умеет трансформировать конфигурационные файлы ASP.NET проектов во время развёртывания
Если в вашей папке находятся файлы Web.config и Web.Release.config, при развёртывани
проекта в конфигурации Release MSBuild применит трансформации из Web.Release.config к Web.config. Можно менять атрибуты разделов, добавлять и удалять подразделы. Мы у себя меняли регистрируемый класс, так что на контуре Release запускалась реальная служба уведомлений вместо отладочной.

Тогда нас такое решение устроило.

Некоторое время всё работало хорошо, но потом вышла 4-я версия Autofac, которая стал
совместима с новой системой конфигурирования .NET. При этом разработчики Autofac выпилили поддержку старого способа, то есть старых добрых Web.config и App.config. При этом MSBuild не умеет автоматически трансформировать новые файлы конфигурации.

Пришлось переделать схему. Теперь для каждого контура мы стали хранить свою верси
конфигурации IoC в файлах IoC.Dev.json, IoC.Stage.json, IoC.Release.json. Загрузка нужного файла конфигурации стала осуществляться так:

Startup.cs

var configName = Environment.GetEnvironmentVariable("APPSETTING_CONFIG_NAME") ?? "Dev";
var config = new ConfigurationBuilder().AddJsonFile($"IoC.{configName}.json", optional: true, reloadOnChange: true);
var module = new ConfigurationModule(config.Build());
builder.RegisterModule(module);


Это было стихийное решение, которое мы обнаружили в Google и смогли применить к нашем
Azure-проекту. Однако это ещё не идеал с точки зрения 12-тифактороного приложения. Часть настройки действительно вынесена в переменную окружения, но часть находится в файлах IoC.*.json.

Что не так? Администратор системы может решить, что файлы IoC.Dev.json, IoC.Stage.json
IoC.Release.json можно спокойно менять, хотя на самом деле мы довольно суровы относительно них. Нам не нужна здесь универсальность и гибкость, мы бы хотели ограничить настройку двумя вариантами: а) шлём уведомления; б) складываем уведомления в секретное место.

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

var notifyStrategy = Environment.GetEnvironmentVariable("APPSETTING_NOTIFY_STRATEGY");
switch (notifyStrategy)
{
case "send":
    builder.RegisterType().As();
    break;

case "save":
    builder.RegisterType().As();
    break;

default:
    throw new ArgumentException("Ну всё теперь.", nameof(notifyStrategy));
}


Теперь администратор приложения может конфигурировать его на своём уровне погружения. Он не сломает ничего важного в дебрях XML/JSON IoC.
В результате нам удалось полностью избавиться от файлов конфигурации на этом уровне и стать ближе к идеалам 12-тифакторных приложений.

Исходя из этого, я бы советовал:


Все секретные настройки, включая строки подключения к базам данных, логины и парол
для отправки писем и прочее, брать из переменных окружения. Развёртывание приложения свести к запуску одной команды (для .NET это MSBuild). Переменные окружения и процесс развёртывания описать в README.md.
Внедрение зависимостей реализовывать непосредственно в коде, предоставляя нескольк
стратегий, которыми будет управлять администратор. Он скажет вам спасибо, если ему не придётся изучать детали приложения, и он сможет одной настройкой внедрить совершенно другой набор из трёх-пяти-десяти типов, не разбираясь в их взаимосвязях.
Некоторые конфигурационные файлы на самом деле представляют из себя декларативну
часть кода и не требуют изменения после развёртывания. Детали зависит от языка, думаю, что чаще это встречается в интерпретируемых языках. Такие файлы мы не должны считать истинно конфигурационными и можем оставить их в проекте как есть.
Конфигурацию, которую может менять администратор и которая может сохраняться межд
развёртываниями, вынести в БД. Можно и в файл, но в этом случае он может быть уничтожен при неаккуратном развёртывании. Значения в базе или в файле, если их нет при первом запуске системы, прописываются стандартные из кода.


Ответ 3

Я стараюсь делать следующим образом. Сначала программа пытается использовать конфигурацию
специализированную для текущего хоста, из файла config-hostname.xml. Вся чувствительна
информация хранится в нём, и в git он не попадает благодаря игнорированию по маске config-*.xml. Если же специализированная конфигурация отсутствует, то используется дефолтная из файла config.xml, который сохраняется в репозитории. По истории изменений этого файла очень удобно отслеживать, когда появились те или иные фичи. Часто удобнее, чем искать по сhangelog'у.

В тех случаях, когда некоему параметру невозможно придумать осмысленное значени
по умолчанию, но в то же время и убирать его совсем из дефолтной конфигурации не хочетс
(должно быть понятно, что он вообще есть), я прописываю ему какое-нибудь заведомо невалидное специальное значение (-1 или строку "must be customized"). Программа при работе с таким параметром понимает это значение, выдаёт соответствующую диагностику и выходит.


Ответ 4

Я именно храню sample-версии конфиг-файлов. Чисто для того, чтобы почитать пример, как это может выглядеть. Настоящие конфиги собираются при помощи ansible. 

Именно он и подставляет критичную информацию типа паролей. 

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

В ряде случаев для упрощения жизни пользуюсь следующим трюком: пароли dev-конфигураций представляют собой md5 от паролей на production.

Как-то так:

[mysql]
host     = "{{ databases_mysql[0].dbhost }}"
dbname   = "{{ databases_mysql[0].dbname }}"
user     = "{{ db_users_mysql[0].name }}"
password = "{{ mask_pwd | ternary(db_users_mysql[0].password|hash("md5"),db_users_mysql[0].password) }}"


, где  mask_pwd - логическая переменная, маскировать или нет пароль (устанавливается в зависимости от вида окружения).


Ответ 5

Все описанное ниже относится к spring приложению, первый пункт можно отнести и 
другим технологиям, если возможно подстановка данных из переменных среды.


Есть множество способов задания конфигурации настроек. Но действительно есть определенны
чувствительные данные(пароли, credentials и т.д.), которые нельзя хранить в открыто
доступе. В этом случае можно использовать вариант хранения скелета настроек в property файлов в git`е, но с подстановками из enviroment переменных. В этом случае чувствительные данные будут прописываться в OC.
У первого пункта есть один существенный недостаток - синхронизация таких данных межд
различными серверами. Данная ситуация может возникнуть при микросервисной и SOA архитектурах(одно или несколько приложений используют одни credentials). На этот случай есть spring cloud vault, который позволяет ограничить доступ к таким данным через авторизацию приложений. 
Официальное описание проекта.


  Spring Cloud Vault Config provides client-side support for externalized configuratio
in a distributed system. With HashiCorp’s Vault you have a central place to manage externa
secret properties for applications across all environments. Vault can manage static and dynamic secrets such as username/password for remote applications/resources and provide credentials for external services such as MySQL, PostgreSQL, Apache Cassandra, MongoDB, Consul, AWS and more.


Ответ 6

Как способ, наверно, решить эту проблему использование систем непрерывной интеграции которые сами будут тебе создавать конфигурацию с переменной среды.
Переменная среды устанавливается в самой системе непрерывной интеграции.
TeamCity так может, в других CI думаю присутствует такая возможность. Так же та
есть возможность добавлять кроме переменных сред еще и параметры, системные свойства что очень удобно.
Ко всему этому удобностью является написание скриптов сборки.
Пример генерации конфигурации на примере js файла 

file=$(cat <
Ответ 7

Я храню дефолтную конфигурацию в файле .env в корне проекта.

ENV_database_host=127.0.0.1


Этот файл - один и тот же для всех разработчиков, он попадает в git-репозиторий
Файл загружается при запуске docker-compose up -d и значения попадают в контейнер через блок environment в описании сервиса docker

services:
    php:
        environment:
            ENV_database_host: "${ENV_database_host}"


Затем это значение загружается в параметры приложения на Symfony в файле parameters.yml

parameters:
    database_host: "%env(ENV_database_host)%"


И уже параметр database_host используется в сервисах DI контейнера Symfony "как обычно"

На удалённом сервере значения из файла .env должны быть перекрыты другими. Для этог
в настройках Pipeline CI\CD в репозитории GitLab создаются переменные для каждого из окружений со своим суффиксом. Например ENV_database_host_MASTER для staging и ENV_database_host_PRODUCTION для production.

Чтобы на удалённый сервер попала правильная конфигурация, значения переменных⁠-⁠с⁠-⁠суффиксо
переносятся в переменные без суффикса, файл docker-compose.yml компилируется с уже перекрытыми значениями и результат копируется на сервер

docker-compose -f docker-compose-deploy.yml config > build/docker-compose.yml

Два сервиса на одном сервере

Добрый день!
Спасибо что зашли. Я столкнулся с такой задачей.
Есть сервер, на нем установлены в IIS 4 WCF-сервиса:
Service1 : 1100 (основной) Service2 : 1101 Service3 : 1102 Service4 : 1103
Первый сервис вызывает второй. В принципе тут не было бы ничего сложного, если бы не сертификаты. Это сделано для того, чтобы софт. могли юзать только авторизованные приложения.
Ошибка при вызове сервиса 2:
System.ServiceModel.Security.SecurityNegotiationException: Could not establish secure channel for SSL/TLS with authority ':1101'. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Я проверил сертификаты - мы заходим на второй сервис с нужным сертификатом. У меня есть подозрения, что ошибка в веб-конфиге.
Подскажите, пожалуйста, как решить эту проблему? Я с сертификатами только начинаю работать.
Ниже находится мой веб-конфиг:

Ответ

Могу дать три рекомендации на сей счет:
Всегда обновляться в Service References ссылку на сервис после его апдейта на сервере проверяйте доступ пользователя, под которым запущен Пул, к физической папке сервиса проверьте сертификаты и ендпоинты
Мне это помогло.

Конфигурирование WCF-сервиса для передачи файлов, как и где это сделать?

Пришлось впервые столкнуться с WCF, ибо есть задача - посредством WCF-службы отдавать клиенту файлы по запросу клиента.
Предварительно была изучена теория, и выяснено, что файлы можно передавать:
Как есть, без предварительной настройки, разве что, выставив maxMessageLengthи executionTimeoutInSeconds в довольно большие значения. Включить MTOM в качестве кодировщика. Включить стриминг (потоковую передачу данных).
Точный размер передаваемых файлов я не знаю, но зато могу сказать, что на текущем этапе вряд ли будут передаваться большущие файлы типа дампов БД или потокового видео. Но всё же, в стандартном подходе меня смущает то, что будет постоянная сериализация-десереализация файлов в XML, а зачем лишние телодвижения?
Включение стриминга, в принципе, сейчас подходит, но, как говорит MSDN, будет ряд ограничений (связаны с шифрованим и буферизацией, подробнее — в статье), из-за которых, цитирую:
Из-за этих функциональных ограничений параметры безопасности для потоковой передачи можно использовать только на транспортном уровне, и невозможно реализовать надежные сеансы.
Если сейчас этим можно пренебречь, так как никакого шифрования нет и в помине, но в разрезе дальнейшего развития сервиса это смущает.
Пока в качестве наиболее подходящих путей пытался как включать поддержку MTOM, так и стриминг.
Итак, в качестве пути решения был выбран проект WCF Service Library, в котором был объявлен интерфейс службы, примерно так:
[ServiceContract] public interface IUpdaterService { [OperationContract] bool TestConnection(); ... [OperationContract] FileStream DownloadFile(string filename); ... }
Ага, тут я использую FileStream, значит нужно включить поддержку стриминга, но сложность в том, что я попросту не знаю, где и как это сделать. То же самое и с включением MTOM.
Ну, например, в попавшихся мне решениях говорят, "измените конфиг так":


Вроде всё понятно, что менять и на что, но где это делать?
Напоминаю, у меня DLL, в которой есть лишь App.config, и он - следующий:


Т.е. по сути, в App.config нет, например, раздела bindings, где можно было бы изменить эти параметры. При запуске родного WCF Test Client метод DownloadFile не доступен, так как используется тип FileStram, стало быть, протестировать его никак...
Конфиг клиента, в свою очередь, формируется такой, нужно, т.е. как раз с теми разделами, которые можно менять:


Но опять же - возникает вопрос - а где и как менять этот конфиг? Уверен, он генерируется автоматически, т.е. необходимо задать нужные параметры для моей DLL, но как верно это сделать? К сожалению, ответа на этот вопрос пока не нашел (может, плохо искал, конечно).
Спасибо.

Ответ

Начну с конфигов.
Во-первых, у DLL не бывает файла конфигурации. Тот, что у вас в проекте лежит - это мусор. Ну, некоторые настройки используются самой студией - на остальные же можно смотреть только как на пример.
Файлы конфигурации бывают только у исполнимых файлов и у веб-сайтов.
Далее - файл конфигурации не является автогенерируемым. Студия может в нем что-то менять - но как правило, это лишь пример. По-хорошему, вам надо пойти в msdn - и прочитать описание каждого тэга, используемого в вашем файле конфигурации.
Секция bindings используется на обоих сторонах соединения - т.е. и клиентом, и сервером. Но она опциональна - без нее будут браться настройки по умолчанию. Если вам надо поменять там настройки, но ее нет - значит, ее надо создать.
На разные привязки (bindings, "биндинги") ссылаются конечные точки (endpoint) через атрибуты binding и bindingConfiguration. Когда будете создавать свои привязки - не забудьте про эту связь, чтобы не удивляться потом что ничего не изменилось.

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