Можно ли добавить ссылку веб-службы WCF на приложение.NET в производственной среде IIS

Question

У нас есть приложение ERP, разработанное в.NET 3.5.

Недавно я разработал службу WCF для предоставления данных, полученных с сервера БД нашего бизнес-клиента.

Теперь я добавил сервисную ссылку в свой локальный потребительский проект и протестировал.

Чтобы перевести это приложение в производственную среду, нам нужно каждый раз компилировать DLL, а затем публиковать в живом.

Мне нравится избегать всего процесса компиляции DLL, где я должен зависеть от моей команды разработчиков для получения кода и компиляции. (Эта проблема связана с тем, что TFS или VSS не используются для работы с одним файлом решения)

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

Answer 1

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

Тем не менее, сервисные ссылки являются кодом. Поэтому их необходимо скомпилировать вместе с потребляющим кодом в одну или несколько сборок. Это характер потребления веб-сервисов с использованием сервисных ссылок.

Вы можете использовать рефлексию для загрузки кода во время выполнения, что позволит выполнить горячую замену старого с новым dll, но новую ссылку на службу все равно нужно будет скомпилировать в новую DLL.

Лучшим способом решения этой проблемы было бы вообще не использовать ссылки на службы, а вызывать службу напрямую с помощью ChannelFactory. Это позволяет вам вызывать службу без использования метаданных службы для создания ссылки на службу.

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

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

Однако это не снимает требования о том, что все это нужно будет скомпилировать в какой-то момент. Что он делает, так это устраняет связь между потребителем и обслуживанием.

Можете ли вы прояснить, в каких ситуациях выгодно использовать горячую замену / ChannelFactory?

Хотя это не будет напрямую отвечать вашим требованиям,

Горячая замена полезна для изменения поведения приложений во время выполнения. Это важно, если:

1. ваше приложение - черный ящик,
2. вам нужна 100% доступность, или
3. Ваш процесс развертывания настолько труден, что стоимость развертывания новых версий непомерно высока.

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

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