Конфигурирование 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 недостатком не является пока эти файлы не очень большие. Просто помните, что файлы от этого распухают на треть.
Шифрование на транспортном уровне не является проблемой если только вы не работаете с интеграционными шинами.