1

I have a service I wrote and deployed in the service.msc list of services. I then wrote a test client to test some of the features. The basic 'first' attempt worked perfect. The issue is when I went back and added new operations I keep getting the following Error:

System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:8080. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at System.ServiceModel.Channels.SocketConnectionListener.Listen() --- End of inner exception stack trace --- at System.ServiceModel.Channels.SocketConnectionListener.Listen() at System.ServiceModel.Channels.ConnectionAcceptor.StartAccepting() at System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen()

The process I have followed is listed below:

  1. I stopped the service to free up the .exe file.
  2. I used 'installutil /u ...' to uninstall my service.
  3. I added the features needed to the service library.
  4. I rebuilt the library, then the Windows Service.
  5. I used 'installutil ...' to install service.
  6. I used service.msc to start the service (which is Autostart).
  7. I try to update the service reference to the TestClient and Boom - Error.
  8. I did steps 1-7 again, but this time changing the /mex and default service addresses to use different ports (per: http://msdn.microsoft.com/en-us/library/aa702636.aspx
  9. Did step 7 again and Boom - Error Again

I tweaked and piddled with the service several times over again, rewrote the client, etc. Nothing seems to work. Funny thing is it worked fine the first try, now there are issues. I have already ensured that my service is the only one on it's port using 'netstat -aon' and 'tasgmgr.exe'. These all look fine. The host runs, everything up to the test client is fine. Now the end points use different ports so the TCP Mex issue should be solved according to online documentation. Am I missing something here? I was able to generate a proxy using 'svcutil' and I ensured the App.Config data does not conflict.

Below is the App.Config data (as I am using configuration files):

HOST App.Config (service):

      <service name="SomeServiceLib.SomeService">
        <endpoint address="net.tcp://localhost:8080/SomeService" binding="netTcpBinding" contract="SomeServiceLib.ISomeService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="net.tcp://localhost:8081/SomeService/mex" binding="mexTcpBinding" contract="IMetadataExchange" />
      </service>
    </services>

    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- NOTE: If net.tcp, must set each to false to avoid exception -->
          <serviceMetadata httpGetEnabled="False" httpsGetEnabled="False"/>
          <!-- To receive exception details in faults for debugging purposes, 
          set the value below to true.  Set to false before deployment 
          to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

CLIENT App.Config:

        <client>
          <endpoint address="net.tcp://localhost:8080/SomeService" 
                    binding="netTcpBinding" bindingConfiguration="NetTcpBinding_SomeService" 
                    contract="SomeService" 
                    name="Svc_DefaultEndpoint">
            <identity>
              <dns value="localhost" />
            </identity>
          </endpoint>
          <endpoint address="net.tcp://localhost:8081/SomeService/mex" 
                    binding="mexTcpBinding" 
                    contract="IMetadataExchange" 
                    name="Svc_MexEndpoint">
            <identity>
              <dns value="localhost" />
            </identity>
          </endpoint>
        </client>
        <bindings>
          <netTcpBinding>
            <binding name="NetTcpBinding_SomeService" />
          </netTcpBinding>
        </bindings>

...

Zack Jannsen
  • 622
  • 7
  • 17
  • You shouldn't need to specify a mex endpoint on the client. Can you remove the mex endpoint from the client app.config and try again ? – Kiran Mothe Oct 02 '13 at 19:27
  • Will do. Stay tuned. – Zack Jannsen Oct 02 '13 at 19:54
  • Still having the issue. Getting an error in rebuild of client 'unable to copy file...'. Should I rip out the original proxy classes? I can not add a reference to the service as it keep telling me that it is busy (and the SomeServiceLib.dll is being used by something else). – Zack Jannsen Oct 02 '13 at 20:12
  • Are you running the client while trying to re-build ? you'll need to close the client. Also it looks like the windows service is running off of the bin/debug folder, so you may need to stop the windows service before building the WCF service project. – Kiran Mothe Oct 02 '13 at 20:26
  • Client will not build, and only on occasion do I get it to run. I can check the system tray to ensure it is stopped. As for the "Build", yes, I do stop the service. At times the service will not re-start so I end up uninstalling it, and re-installing it. Then I go to step 6 above and manually start the Host. Host starts fine ... the conflict is that the client reference to the host is hit with the error. – Zack Jannsen Oct 02 '13 at 20:30
  • Holy cow ... I stop debugging and the little test client is still in the active processes. Let's see if killing it works. – Zack Jannsen Oct 02 '13 at 20:31
  • Looks like Test Client keeps restarting over and over. Going to try restarting VS 2012. – Zack Jannsen Oct 02 '13 at 20:34
  • So every time I start VS 2012 the Test Client starts up. Is this normal behavior (even when not debugging). – Zack Jannsen Oct 02 '13 at 20:37
  • That's not normal behavior. Does it startup as soon as you start VS or when you open the solution ? – Kiran Mothe Oct 02 '13 at 20:50
  • When I open the solution. I stopped it manually: Stopped VS, deleted the contents of ..bin\Debug\ and then deleted the solutions .suo file (just in case something strange was cached there). Oddly, I now get a URI prefix error when trying to add the service reference. – Zack Jannsen Oct 02 '13 at 20:52
  • PS - not restarting anymore (obviously). – Zack Jannsen Oct 02 '13 at 20:52
  • You may want to set httpGetEnabled="true" in the section and use the http prefix instead of net.tcp when adding the service reference. Or, you can generate the proxy from svcutil and add it to your client project. – Kiran Mothe Oct 02 '13 at 21:04
  • actually, it's just easier to generate proxy through svcutil and add the generated proxy to your client project. – Kiran Mothe Oct 02 '13 at 21:06
  • Yeah. I did that before. I am thinking of going back to the foundation. Might just dump everything but the Library and rebuild it all from the ground up. That way I know there is no buried code from prior tools (e.g. svcutil) that I might be missing... I will still need a Service Reference, right? And I am not able to create one as it stands. – Zack Jannsen Oct 02 '13 at 21:09
  • 1
    No, you do not need to add service reference through VS if you just add the generated proxy (and config) to your project. – Kiran Mothe Oct 02 '13 at 21:11
  • Okay ... well palm to face on that one. – Zack Jannsen Oct 02 '13 at 21:14

0 Answers0