WCF Contract Name 'IMyService' could not be found?

.NetWcfException Handling

.Net Problem Overview


>The contract name 'IMyService' could not be found in the list of contracts implemented by the service 'MyService'.. ---> System.InvalidOperationException: The contract name 'IMyService' could not be found in the list of contracts implemented by the service 'MyService'.

This is driving me crazy. I have a WCF web service that works on my dev machine, but when I copy it to a Virtual Machine that I am using for testing, I get the error that seems to indicate that I am not implementing the interface, but it does not make sense because the service does work on my windows xp IIS. the Virtual machine uses Windows Server 2003 IIS. Any ideas?

One thing to note here is that I get this error on my VM even while just trying to access the service in a web browser as the client.

Note: I am using principalPermissionMode="UseWindowsGroups", but that is not a problem on my local machine. I just add myself to the appropriate windows group. But no luck on my VM.

Config:

<configuration>
	<system.serviceModel>
		<diagnostics>
			<messageLogging logEntireMessage="false" maxSizeOfMessageToLog="2147483647" />
		</diagnostics>
		<services>
			<service behaviorConfiguration="MyServiceBehaviors" name="MyService">
				<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding"
				  name="MyService" bindingName="basicHttpBinding" bindingNamespace="http://my.test.com"
				  contract="IMyService">
				</endpoint>
			</service>
		</services>
		<bindings>
			<basicHttpBinding>
				<binding name="basicHttpBinding" maxReceivedMessageSize="2147483647">
					<readerQuotas maxStringContentLength="2147483647" />
					<security mode="TransportCredentialOnly">
						<transport clientCredentialType="Windows" proxyCredentialType="None" />
					</security>
				</binding>
			</basicHttpBinding>
			<netTcpBinding>
				<binding name="WindowsClientOverTcp" maxReceivedMessageSize="2147483647">
					<readerQuotas maxStringContentLength="2147483647" />
				</binding>
			</netTcpBinding>
			<wsHttpBinding>
				<binding name="wsHttpBinding" maxReceivedMessageSize="2147483647">
					<readerQuotas maxDepth="32" maxStringContentLength="2147483647"
					  maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
				</binding>
			</wsHttpBinding>
		</bindings>
		<behaviors>
			<serviceBehaviors>
				<behavior name="MyServiceBehaviors">
					<serviceMetadata httpGetEnabled="true" />
					<serviceAuthorization principalPermissionMode="UseWindowsGroups"
					  impersonateCallerForAllOperations="false" />
					<serviceCredentials />
				</behavior>
			</serviceBehaviors>
		</behaviors>
	</system.serviceModel>
</configuration>

.Net Solutions


Solution 1 - .Net

[ServiceContract] was missing in my case.

Solution 2 - .Net

@Garry (a bit late, I know)

If your ServiceContract attribute defines a ConfigurationName, this should be the value in the endpoint, not the fully qualified name. I just had this problem now as described by the OP, and this was the solution for me. Hope this helps someone else who stumbles across this.

Solution 3 - .Net

This is a slightly more uncommon solution, that applied to my situation with the same error:

It's possible that the contract namespace can be overridden, with the following attribute:

[System.ServiceModel.ServiceContractAttribute([...], ConfigurationName = "IServiceSoap")]
public interface ISomeOtherServiceName

Which would require:

<endpoint address="" binding="basicHttpBinding" contract="IServiceSoap" />

Rather than the usual (namespace).ISomeOtherServiceName.

This can be a result of code generation, in my case WSCFBlue

Solution 4 - .Net

Your name attribute in the service element and the contract attribute in endpoint element are not correct. They need to be fully qualified names:

<service name="namespace.MyService">
      <endpoint contract="namespace.IMyService" >

Once you change the values to be fully qualified names that should resolve your error.

Solution 5 - .Net

Doesn't the contract attribute on the endpoint need to be the fully qualified namespace?

Solution 6 - .Net

yes @Garry you are right. contract in endpoint should be fully qualified name

<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttpBinding"      name="MyService" bindingName="basicHttpBinding" bindingNamespace="http://my.test.com"  contract="Namespace.IMyService">

Solution 7 - .Net

I have a habit of doing this ...

<system.serviceModel>
    <services>
      <service name="Service" behaviorConfiguration="wsHttpBehaviour">
        <endpoint 
            binding="wsHttpBinding" 
            contract="IService" 
            bindingConfiguration="wsHttpBinding" 
            />
        <endpoint contract="IService" binding="mexHttpBinding" address="mex" />
      </service>

when i should do this ...

<system.serviceModel>
    <services>
      <service name="namespace.Service" behaviorConfiguration="wsHttpBehaviour">
        <endpoint 
            binding="wsHttpBinding" 
            contract="namespace.IService" 
            bindingConfiguration="wsHttpBinding" 
            />
        <endpoint contract="namespace.IService" binding="mexHttpBinding" address="mex" />
      </service>

See what i mean ... It's the dumbest thing ever (especially when the app only has 1 or 2 items in it) but a "fully qualified" classname seems to make all the difference.

Solution 8 - .Net

can you post code of your interface...? as normally this occurs if you haven't specified ServiceContract attribute in your Interface...

Solution 9 - .Net

I had the same error but the source of the problem was different. I was learning as I going and I first created a service using the Silverlight-enabled WCF service from the Silverlight templates in Visual Studio. I called this TerritoryService. When you create a service in this way the web.config is altered as below:

 <services>
      <service name="Services.TerritoryService">
        <endpoint address="" binding="customBinding" bindingConfiguration="Services.TerritoryService.customBinding0"
          contract="Services.TerritoryService" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>

The examples that Im working off however use DomainServices.i.e. when using these you inherit from DomainService. So i deleted the TerritoryService I had created and then created a DomainService Class from the template off the Web templates menu in Visual Studio. I carried on working and everything compiled just fine. But when i ran it i got an error as per the title of this question.

The problem it turns out is that when you inherit from a domain service no such entry is created in the web.config file. It doesn't need it. But when you delete a service created via the Silverlight-enabled web service it does NOT delete the entry in the web.config file.

So because I had named both services the TerritoryService when the service was being called the entry in the web.config was pulled into play and the server went looking for a service defined in that manner which it could not find because i had deleted it.

So the solution was to simply delete the entry stubs as above that had been auto created by Visual Studio in the config file but not auto deleted by Visual Studio when i deleted the service. Once i did that the problem was resolved.

It took me a half hour to work this out though because of the naming "conflict". It "looked" very much right and was in line with many examples. So if you're inheriting from a domain service class you do not need/should not have an entry in the config file as you do when you've created a wcf service.

Solution 10 - .Net

In my case, the problem was a misnamed namespace. HTH

Solution 11 - .Net

Using the visual studio 2013 "Add"->"Service" menu option created the web config sections for me but with the "endpoint" "contract" set to the name of the concrete class not the interface.

As soon as I corrected that all started working.

Solution 12 - .Net

Ok, this doesn't really satisfy my question, but one way that I found to resolve it was to install .NET 3.5. because both of my other environments had 3.0.

So I really haven't determined why it would work in one environment and not the other, especially with that interface error.

Go figure?

Solution 13 - .Net

There's 2 mistakes in my case:

  1. The config sections are copied from another proxy project, and I forgot to change the namespace to full path.

  2. As a client, I copied the endpoint section into services node - the client is also a wcf service.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionM3NTA7View Question on Stackoverflow
Solution 1 - .NetLeblanc MenesesView Answer on Stackoverflow
Solution 2 - .NetmastyView Answer on Stackoverflow
Solution 3 - .NetOverflewView Answer on Stackoverflow
Solution 4 - .NetRajeshView Answer on Stackoverflow
Solution 5 - .NetGarryView Answer on Stackoverflow
Solution 6 - .NetUsman MasoodView Answer on Stackoverflow
Solution 7 - .NetWarView Answer on Stackoverflow
Solution 8 - .NetUsman MasoodView Answer on Stackoverflow
Solution 9 - .NetrismView Answer on Stackoverflow
Solution 10 - .NetjoseluisrodView Answer on Stackoverflow
Solution 11 - .NetrobView Answer on Stackoverflow
Solution 12 - .NetM3NTA7View Answer on Stackoverflow
Solution 13 - .NetflaughView Answer on Stackoverflow