Нет, прямой привязки таблицы маршрутизации ASP.NET для привязок net.tcp не существует.И пользовательский модуль HttpModule не поможет, поскольку он предназначен только для HTTP;)
Однако, есть некоторые вещи, которые вы можете сделать.Прежде всего, если вы не хотите иметь файл .SVC для каждой из ваших служб, вы можете использовать активацию новой службы (WCF 4) на основе конфигурации, которая позволяет объявлять все службы WCF в приложении Web.config.(внутри system.serviceModel), например:
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress="Service1.svc" service="MyNamespace.MyService1"/>
<add relativeAddress="Foo/Service2.svc" service="MyNamespace.MyService2"/>
<add relativeAddress="Bar/a/Service3.svc" service="MyNamespace.MyService3" factory="System.ServiceModel.Activation.ServiceHostFactory"/>
</serviceActivations>
</serviceHostingEnvironment>
Примечания:
- Атрибут @factory по умолчанию равен
ServiceHostFactory
, т. е. его нужно указывать только в том случае, если выВы используете другой тип фабрики (например, WebServiceHostFactory или пользовательский) - Основной недостаток: @relativeAddress ДОЛЖЕН содержать расширение !!
- Расширение должно быть объявлено в system.web/ compilation / buildProviders, и указанный там тип должен иметь атрибут [ServiceActivationBuildProvider] (System.ServiceModel.Activation)
- Что означает, что в действительности вы в конечном итоге будете использовать расширение
.svc
, поскольку этоуже объявлен по умолчанию в корне. Web.config -
Но этот подход, по крайней мере, позволяет вам определять все ваши сервисы в одном месте.(в отличие от нескольких .svc файлов ) - и в этом отношении он сопоставим с RouteTable
.
Теперь, если вас беспокоят расширения .svc, вы можете даже пойтина шаг впереди.Другим новым элементом в WCF4 является Служба маршрутизации (см. http://msdn.microsoft.com/en-us/library/ee517423.aspx), которая является универсальной службой WCF, которая принимает сообщения для пересылки их другим службам WCF на основе различных критериев (таких как заголовки SOAP,содержимое сообщения, адрес конечной точки и т. д.).
Используя службу маршрутизации, вы можете определить различные фильтры EndpointAddress (например, net.tcp: // {routing-service-base} / service1, net.tcp:// {routing-service-base} / service2 и т. д.), что еще больше приближает вас к маршрутизации ASP.NET.
Однако, если вы сами размещаете службу маршрутизации в IIS, очевидно, этабудет по-прежнему иметь .SVC
базовый адрес!
Единственный способ обойти это последнее ограничение (т. е. как разместить саму службу маршрутизации на симпатичном URI, таком как net.tcp: // имя_сервера / XYZServices ) будет состоять в том, чтобы самостоятельно размещать только службу маршрутизации, например, в службе Windows, что дает вам полный контроль над ее базовым адресом. Затем вы можете продолжать размещать фактическую цельслужбы в IIS - с расширениями .svc - и ваша служба маршрутизации преобразует «хорошие» публичные URI в IIS .svc.
Однако трудно отказаться от хостинга IIS / AppFabric только дляполучить хорошие URI.Я, вероятно, не стал бы это делать.
Надеюсь, вы сможете использовать хотя бы часть этого:)