这里需要考虑两件事:
因此,如果您在 localhost 机器上的一个名为 MyApp 的虚拟目录中拥有您的 MyService.svc,然后使用此配置:
<service name="MyService" behaviorConfiguration="Default">
<endpoint
address="wsHttp"
binding="wsHttpBinding"
contract="IMyService" />
<endpoint
address="basic"
binding="basicHttpBinding"
contract="IMyService" />
</service>
那么您的“旧式”basicHttp 服务将可以在以下位置访问:
http://localhost/MyApp/MyService.svc/basic
您的新 wsHttp 驱动服务将可在以下位置访问:
http://localhost/MyApp/MyService.svc/wsHttp
您可以为这些相对地址(.../MyApp/MyService.svc 之后的任何名称)命名任何您喜欢的名称 - 只需确保它们彼此不同即可。
在 IIS 中托管 --> *.svc 文件的位置(虚拟目录)成为您的基地址。
如果您在控制台应用程序或 Windows NT 服务中自行托管您的服务,您可以自己设置您的基地址:
<services>
<service name="MyService" behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8185/Services/" />
</baseAddresses>
</host>
</service>
</services>
现在,在这种情况下,您的“旧式”basicHttp 服务可以在以下位置访问:
http://localhost:8185/Services/basic
您的新 wsHttp 驱动服务将可在以下位置访问:
http://localhost:8185/Services/wsHttp
您可以为每个传输定义一个基地址,例如一个用于 http://,一个用于 net.tcp://,以此类推。
当然,如果您确实需要,您还可以在 <endpoint> 元素中为每个服务端点定义完整地址 - 这为您提供了完全的灵活性(但仅适用于自托管场景)。
马克