My service implementation is present in Calc.dll.
WCF Service is present in Svc.dll
I have added contract inside endpoint tag in the WCF app.config file of Svc.dll.
<service behaviorConfiguration="Default" name="MySvc">
<endpoint contract="Company.ICalc" .... />
How does WCF know that the service is implemented in Calc.dll? We have just specified the contract name.
In order for this to work, your svc.dll project must somehow reference calc.dll - and thus, the .NET / WCF runtime can find the specified namespace and class.
Related
When attempting to add a service reference to a WCF service to my .NET project I am getting an error:
Failed to add a service. Service metadata may not be accessible. Make sure your service is running and exposing metadata.
After doing some research I decided to add a metadate exchange endpoint to my service:
<endpoint
address="mex"
binding="mexHttpsBinding"
contract="IMetadataExchange"/>
Now, after adding the enedpoint I am getting a different type of error:
Could not find a base address that matches scheme http for the endpoint with binding BasicHttpBinding. Registered base address schemes are [https].
What am I doing wrong here?
If I open service in the browser, it works just fine:
https://alias.domain.com/ProjectName/MyService.svc?wsdl
mexHttpBinding is only for http:// but as your service is exposed over https:// you need to change it to mexHttpsBinding.
See here: https://msdn.microsoft.com/en-us/library/aa395212(v=vs.110).aspx
Solved!
The issue was that some XSD references in WSDL, schemaLocation in particular. For some reason schemaLocation used machine name instead of the domain name. After I fixed that I was able to add a reference to the service
I think my question is rather simple, so I'll stick to the point:
Is it by any means possible to expose a service without specifying the services element and only the serviceHostingEnvironment element? I.e. would the below configuration be enough to host a WCF service? I'm asking because i've seen applications that - as far as I can tell - lack the services element, and I thought that was mandatory.
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<serviceActivations>
<add relativeAddress="Service.svc" service="Namespace.To.My.Service" />
</serviceActivations>
</serviceHostingEnvironment>
With WCF 4.0 you don't need explicit service configuration as opposed to prior versions. It automatically adds default endpoints if no endpoints are defined explicitly.
Whatever configuration you mentioned in question is called File-less activation and you can activate service without even having physical .svc file. In WCF 4 you can define virtual service activation endpoints like one you have defined.
WCF detects what contracts are implemented by service and then method AddDefaultEndpoints adds one default endpoint per base address for each service contract implemented by the service. Note that this behavior is only when no explicit endpoints are added (either programmatically or through configuration). Should you add one explicit endpoint WCF stops adding default endpoints and it gives control to developer to customize it further.
What is the difference between the Service node/section and the Client node/section in the configuration section? Why configure endpoints in one section over the other? Which is best for interoperability?
I'm currently building a service that talks to another service. I have endpoints for my clients and endpoints for the other service. Visual Studio seems to lump all the endpoints into the Client section.
I thought that client node was for your consumption and service node was for producing. But when you create a new wcf service visual studio puts your new service endpoint settings under the client node. I have moved my endpoint between both sections trying to figure out what the difference is.
When should I use service over client?
<system.serviceModel>
<services>
<service> <!--I noticed some tutorials and using wcf config edit tool
puts producer endpoint settings here -->
<endpoint blah settings/>
<endpoint blah settings/>
</service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint
settings here -->
<endpoint blah settings />
<endpoint blah settings />
<endpoint blah settings />
</client>
<bindings>.....
</system.serviceModel>
Many settings in the WCF web.config (or app.config for that matter) can be shared for both consumers of a service as well as publishers of a service including:
Bindings
Endpoint Behaviors
Diagnostics
However as you have discovered, some config is specific to a service. A well-written service usually specifies:
It's base address. This is a convenience when defining a service as it allows your to define endpoints using relative addresses. Clients however don't use this particular setting as they need an absolute path. For this reason it makes no sense to specify in the section
Services can also be clients. If the client and server endpoints were all plonked together, WCF would not be able to know which should utilise the base address for one thing
Service behavior
By dividing up config between client and server, WCF is better able to know where to look for endpoints.
Which is best for interoperability?
I don't think that has anything to do with it. WCF is a means to achieve interopability but just by using WCF does not imply you will achieve it. Interopability is established when both parties agree on say a particular service contract; canonical data model; data transformation; message version or many of the other patterns as defined by SOA Patterns.org So there are various patterns you must follow. e.g. If you change a method on service contract but have not updated the clients then you have broken interopability by breaking the schema of the service.
Visual Studio seems to lump all the endpoints into the Client section
If your WCF process is both a consumer and producer of WCF services then it should not be putting all the endpoints under
I developed a WCF service in C#. Our customer already has a client software written in Java. They say when they try to add our wcf service reference, they get an error. They think that the problem about namespaces.
I don't know much about namespaces or any other tag details in WCF.
They say wcf service's wsdl output has to be like the following:
<xsd:import id="base" namespace="http://helios.theircompanyName.com/im schemaLocation="http://wwwdev1.theirCompanyName.com:8000/HeliosIM/im?xsd=1"/>
But our service gives:
<xsd:import schemaLocation="http://myComputerName/MyWcfProjectFolder/MyWcfService.svc?xsd=xsd0" namespace="http://tempuri.org/"/>
As it can be seen, my service has no attribute like id="base" and namespace, schemaLocation attributes are different.
How can I change WCF to generate wsdl xml like they want?
If you want to change the namespace of your service from tempuri.org (which is the WCF default) you need to change it in 4 places:
Service contract
Data contracts
Service implementation
BindingNamespace in endpoint config element
For example:
// Service Contract
[ServiceContract(Namespace="http://myNamespace")]
public interface IMyService
{}
// Data Contract
[DataContract(Namespace="http://myNamespace")]
public class MyType
{}
// Service implementation
[ServiceBehavior(Namespace="http://myNamespace")]
public class Service : IMyService
{}
<!-- In config -->
<endpoint address="http://whatever"
bindingNamespace="http://myNamespace"
binding="basicHttpBinding"
contract="Something.IMyService" />
HOWEVER, I don't really understand why they are telling you this is necessary. As the provider of the service, it's up to you rather than them what namespace you provide. Whatever this value is set to they will likely have the same problems consuming the wsdl.
The same goes with the schemaLocation, again, it's not up to them where this location points to. Schemalocation is actually completely optiona when you're doing an import in xml schema, so if they're dependent on some value being in there then they're not xsd compliant.
I would guess they're having difficulties consuming your WSDL and do not quite understand what is wrong, so have chosen to blame your service. The service metadata exposed over the basicHttpBinding is the most interoperable of the entire WCF stack, and should be 100% consumable from java.
How are they trying to build their client? Is your service running somewhere they can see it?
Is there a way to do this globally, automatically for all my WCF services via configuration in WCF 4.0?
That is, I know WCF 4.0 exposes new configuration techniques that applies certain behaviors by default to all hosted endpoints, and that you don't need to explicitly specify individual endpoints by config anymore...but can I do something in the config that says to automatically host all services with both a BasicHttpBinding and a WebHttpBinding (using a /web relative address for the WebHttpBinding)? Or do I still need to use a custom ServiceHostFactory for this?
Thanks.
See the Developer's Introduction to WCF 4 for lots of interesting stuff in WCF 4.
One of the new features is called default protocol mapping, and this combined with the default endpoints provided by WCF 4 might solve your problem.
Default endpoints means that WCF 4 will provide one endpoint for each contract your service class implements (typically only 1), and for each base address defined in your config (or code for the ServiceHost).
In order to make sure a http:// endpoint gets exposed automagically with the webHttpBinding, you also need to override the system default (which is basicHttpBinding) - which you can do thanks to the protocol mappings.
<configuration>
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="webHttpBinding"/>
</protocolMapping>
</system.serviceModel>
</configuration>