It has taken me weeks to get WAS (Windows Activation Service) working. Finally, tonight, my long hours of research has paid off. After everything I tried, it turned out to be a general IIS7 issue caused by a stray http reservation that I probably entered months ago during some testing. As I primarily use the built-in development server for web development, I rarely crank up an IIS site on my development machine.
This post by Phil Haack helped me fix my IIS install:
I have been cursing IIS7, Vista, and WAS for weeks. I should have been cursing my own lack of IIS7 knowledge all along. Now that it’s working, I am a big fan of WAS. From the tone of recent forum responses and blog posts, very few people are using WAS. Maybe it is due to Windows Server 2008 being so new. Not many people have Vista workstations for development and all Windows Server 2008 servers to deploy to. Knowing how many problems I had, I can only assume others are experiencing the same thing. The only real info available right now is pre-release articles and MVP posts about the new features with a sneak peak example on how to get it to work. Even MSDN doesn’t show how to use an existing WCF Service Library with WAS. They just walk through a WsHttpBinding example as a new WCF web site served up by WAS.
I’m posting the details so others will maybe see that it’s really not that hard. For this example I want to expose this service with the NetTcpBinding to prove that it is not IIS hosting the service. I used the WCF Service Library project template for my WCF service, and named the project WasServices. So the lame Service1 service is all I have in the library. I made no changes to the project and built it in release mode to get the DLL. Some posts and articles out there say that the only way to get WAS to work is to have an HTTP-based WCF web site. This is simply not true. You just need to have an application set up in IIS.
Here is the steps to success:
1. Enable the required Windows Features to wake up IIS7 and WAS. You will find these in the helpful links below.
2. Configuration file C:WindowsSystem32inetsrvconfigapplicationHost.config must be modified to enable the required protocols on your web site and application. You can modify the file yourself, or use command-line utilities.
To enable net.tcp on the web site, if it is not already:
%windir%system32inetsrvappcmd.exe set site “Default Web Site” -+bindings.[protocol=’net.tcp’,bindingInformation=’808:*’]
To enable net.tcp on your application (my app is named WasServices) within that web site, if it is not already:
%windir%system32inetsrvappcmd.exe set app “Default Web Site/WasServices” /enabledProtocols:http,net.tcp
Here is an exerpt from the applicationHost.config file showing the site and application settings:
151 <site name=”Default Web Site” id=”1” serverAutoStart=”true“>
152 <application path=”/“>
153 <virtualDirectory path=”/” physicalPath=”%SystemDrive%inetpubwwwroot” />
155 <application path=”/WasServices” applicationPool=”WasHosting” enabledProtocols=”http,net.tcp“>
156 <virtualDirectory path=”/” physicalPath=”C:inetpubwwwrootWasServices” />
159 <binding protocol=”net.tcp” bindingInformation=”808:*” />
160 <binding protocol=”net.pipe” bindingInformation=”*” />
161 <binding protocol=”net.msmq” bindingInformation=”localhost” />
162 <binding protocol=”msmq.formatname” bindingInformation=”localhost” />
163 <binding protocol=”http” bindingInformation=”*:80:” />
3. Prepare the application in your application folder (C:inetpubwwwrootWasServices)
Create a service file (WasServices.svc) that points to your existing WCF service library:
1 <%@ ServiceHost Service=“WasServices.Service1” %>
Create a web.config file that specifies the service’s endpoints:
1 <?xml version=”1.0” encoding=”utf-8“?>
5 <service name=”WasServices.Service1“
7 <endpoint address=”wsHttp“
10 <endpoint address=”netTcp“
14 <endpoint address=”mex“
16 contract=”IMetadataExchange” />
21 <behavior name=”MEX“>
22 <serviceMetadata httpGetEnabled=”true“/>
28 <binding name=”NetTcpBinding_Common“>
29 <reliableSession enabled=”true“/>
30 <security mode=”None“/>
Place the release-compiled DLL created from the WCF Service Library in a new folder named Bin.
4. At this point, you can browse and see the familiar “You have created a service.” page for Service1.
5. Write your proxy file and config file.
WAS and IIS7 decide the address for your service, and it is not intuitive.
1 <?xml version=”1.0” encoding=”utf-8” ?>
5 <endpoint address=”net.tcp://localhost/WasServices/WasServices.svc/netTcp“
9 name=”NetTcpBinding_Common” />
13 <binding name=”NetTcpBinding_Common“>
14 <reliableSession enabled=”true” />
15 <security mode=”None” />
The /netTcp at the end of the address is due to the address specified in the service’s web.config file. The address was given there as simply netTcp. This is because IIS7 and WAS decide your address based on the available bindings and ports you specified in the applicationHost.config file using appcmd.exe. Since my enabled protocols are http and net.tcp and the only open tcp port is 808, you will not see a port number in the address. The same would go for my wsHttpBinding since the only allowable port is 80.
I’m proud to be the fourth, and maybe final, member of the “Got WAS to work” club. If anyone wants to join, and needs help to get in… please let me know.
Here are some helpful links for those of you having problems: