Develop Reference

How to add/remove ports from WSDL service tag?

I have created a web service using C# WCF, which is hosted via IIS. Are there any settings to hide/remove the ports and make the service tag look like this? Are the settings on the IIS server, or in the web service web.config file?
Basically, how can I choose to make it (or not make it) looks like this?
<wsdl:service name="GameService" />
Clarification: I would like to know is if there is a setting, in IIS or web.config, that would allow to either hide completely, or show all of, the configured ports.
Additional Questions: Does the WSDL not read the Web.Config file? Does IIS generate the WSDL, or does the service?
Further Clarification: This is an attempt to solve this question, which has gone unanswered. This question is an attempt to simplify and rephrase so that I actually receive possible solutions.

Answer: SOAP-based endpoint bindings are listed in the WSDL, REST-based are not.
Endpoint bindings come in two different types: SOAP and REST. You're service can include both in the web.config file as long as they have different addresses, but only SOAP endpoints will be listed in the WSDL. There are no additional settings or configurations needed, the service will pick up this information automatically as long as it's of the supported type.
webHttpBinding is a REST-based endpoint binding. It will work fine for JSON/JavaScript clients consuming the service, but will not be listed in the WSDL.
basicHttpBinding is a SOAP-based endpoint binding. It will work well for C# clients. If you use Visual Studio to add the Service Reference, it will automatically add these endpoints to your app.config file, something it can do because that information is listed in the WSDL.
Thanks to #nodots for getting me pointed in the right direction.

According to the MSDN:
A ServiceDescription instance maps to a wsdl:service element. A ServiceDescription instance contains a collection of ServiceEndpoint instances that each map to individual wsdl:port elements.
So, you should be adding/removing ServiceEndpoint in order to affect the ports section in the generated WSDL.
Here is the description of ServiceEndpoints and there is also an example so you can see how to add/remove them. I'm not sure that you can have a functional service without at least one port.
Hope this helps.

Regarding Mex & WSDL issue in WCF

What is the importance of this setting httpGetEnabled="false" or httpGetEnabled="true" what will happen if we set httpGetEnabled="false"
suppose if I want any .Net 2.0 client can consume my wcf service which has been developed by .Net 4.0 then how should i develop the wcf service. once i read that if any client need to consume my wcf service then we need to set httpGetEnabled="true" as a result they can consume ny wcf service through wsdl. things was not ver clear so if possible please in more details how wcf service expose through wsdl.
In wcf mex is also there to expose meta data. So I like to know what is the difference between mex & wsdl?
What mex offer more than wsdl? people said mex is configurable but wsdl is not...What does it mean? need details.
If we search Google to see how wsdl envelope looks like then we get ample of link but I found none for how mex envelope look like searching Google. so please help me to visualize how mex meta data structure look like.
If we remove mex endpoint from service config then how other client can consume my service?
other client can consume my service then through wsdl if yes then how ?
what url I need to enter to have the wsdl of any wcf service ? if `httpGetEnabled="false then wsdl will be possible or not.
Here I asked couple of quetion on mex & wsdl. I am new so bit confused about mex & wsdl usage in wcf.
another question is that what is the usage of soap in wcf & relation.

Invoking the service is totally different than exposing metadata. Basically, a service doesn't have to expose metadata (mex or wsdl) to be called by clients.
Metadata are just exposed to allow easier proxy class generation. This allow developpers to 'Add a service referencee' in VS. WCF provides another way to generate a proxy class : using wsdl.exe with a physical wsdl file.
You can also redistribute your service contract through assemblies and use ChannelFactory.
Exposing metadata is useful on dev, because it allows developpers to re-generate proxy class easily after each modification on the contract (Update Service Reference). On Stage/Prod, it depends on your context : it is generally disabled to "hide" service contract.
About wsdl versus mex, there is another recent answer for this.
If we remove mex endpoint from service config then how other client can consume my service? other client can consume my service then through wsdl if yes then how ?
Your clients can invoke your service only if the have a generated proxy class or your service definition. As I said, they can generate this class using metadata when they want or use a physical wsdl file that you have previously sent.
what url I need to enter to have the wsdl of any wcf service ? if `httpGetEnabled="false then wsdl will be possible or not.
HttpGetEnable allow you to expose metadata through HTTP GET method, usually the service’s address with the suffix of ‘?wsdl'. Simply browse the service url and wcf will generate an help page for you.

what is the advantage of using ChannelFactory to call wcf service

if i know the service url then i can click on add reference and add the service url to create proxy at client side to consume it but without creating proxy at client side we can consume and call service with the help of ChannelFactory.
so i like to know when people will go to use ChannelFactory to create proxy at runtime and what is the advantage?
if i want that if other people know my service url then also they will not be able to add my service as add service reference....how to enable this feature? i want other people will not be able to create proxy at their end if they know my service url....is it possible. i want that people always has to call ny service using ChannelFactory. please discuss this issue in details. thanks

If you have any clients who are not .NET (like Java or PHP, for example), ChannelFactory won't work for them as that is specific to .NET and WCF. In that case, you'll either have to publish the metadata or send the client a WSDL so they can create the proxy via whatever means their language of choice uses (I don't know much about Java, PHP, etc so I can't say much more than that definitively).
As for using ChannelFactory, I assume you're talking about ChannelFactory<T>, as ChannelFactory itself is an abstract class and can't be instantiated. Using the channel factory gives a greater degree of control (as others have indicated) - for ChannelFactory<T> the client will need the service contract (interface, not the implementation), so either using a common assembly shared by everyone or providing the interface to the clients are the two easiest ways to achieve this.
You can disable publishing metadata (the WSDL) by turning httpGetEnabled to "false" in your config file in the <serviceMetadata> tag:
<system.serviceModel>
<behaviors>
<serviceBehavior>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="false" />
</behavior>
</serviceBehavior>
</behaviors>
</system.serviceModel>
You would then reference this behavior by setting the endpoint element's behaviorConfiguration attribute to "MyServiceBehavior".
You should also remove any mex endpoints as (based on my understanding) that's a newer way for web services to expose their metadata. If the metadata is not exposed, then clients cannot construct the proxy via the WSDL and will have to do so by some other method. .NET clients specifically will not be able to use Add Service Reference.
Finally, if you're concerned about access to your service, you should really implement some sort of authentication scheme. If you just simply want to disable publishing (exposing) metadata then setting httpGetEnabled to false and removing any mex endpoints should do the trick.

I've used the ChannelFactory instead of the autogenerated proxies to use the same object model on the server side and on the client.
Also here Sharing Interfaces Between a WCF Service and Client (marked w/ ServiceContract) some problems with autogenerated proxies are discussed.
As for the hiding metadata, the answer is probably here How to hide wsdl information on WCF?

I usually create two assemblies, one with the service metadata (Interfaces [service contracts] and data objects [datacontracts]) and one with the actual service implementation.
Usually i self-host wcf services and skips the DataExchange endpoint-service needed for clients that dont have the meta data (to create proxy's). Clients receive my meta data dll and write their own proxies or uses a custom library together with the metadata dll to create a proxy. Both approaches uses the channelfactory to create the proxy.
If a service is used in a LAN environment I typically setup a discovery service so that clients can find the service url(s) for a specific service interface (custom library code).
Maybe Im just old-school but I like to have control over the process. Versioning concerns etcetera. Another reason, when there is more than one way to use a technology, I focus on the one that can learn me the most about it.
Maybe you should use IIS and service pages (SVC) and auto-proxy creation in Visual Studio if you want to quickly test a service or isn't comfortable with the WCF programming model. Use Channelfactory if you write your own service libraries and need more fine-grained communication control (common service discovery strategy, common configurations/common binding settings, common security settings, hooking into events in the communication stack to run custom code, etcetera).

WCF Application EndPoint

I quote from the MSDN:
application endpoint
An endpoint exposed by the application and that corresponds to a service contract implemented by the application.
Can somebody please explain this definition for me? Is the application endpoint the same as the service reference created by the Visual Studio?

All communication WCF service occurs through the endpoints. It provide clients access to the functionality offered by a WCF service.
Each endpoint consists of three properties:
Address (Where)
Binding (How)
Contract (What)
Endpoints can also have a set of behaviors that specify local implementation details.
endpoints concept exists both on clients and services :
A WCF services can expose multiple endpoints and a client may communicate with services with multiple endpoints.
Can somebody please explain this definition for me? Is the application
endpoint the same as the service reference created by the Visual
Studio?
When you add a service reference, Visual Studio will add a new client endpoint in your application (check updated config file). However, Visual Studio will try first to download metadata in order to list all available endpoints for an address.

Basic Explanation:
The application endpoint is the address that your clients will connect to to get to an instance of a service that implements the listed "service contract".
Further Explination:
WCF works through Interfaces, not classes. Each one of those Interfaces is known as a "Service Contract". A single class could implement more than one Interface so two service contracts could be hosted by a single class. You did not ask about this, but I thought I should get that out there too.
To answer your question, a single Interface can be connected to in multiple ways. Each of those ways you create are called Application Endpoints. Here is a practical example: You may want people to be able to connect using either HTTP for external connections or named pipes for requests generated on the same machine for higher performace. By setting up two endpoints up for a single "Service Contract" that lets you have that flexibility.

wsdl to empty server implementation?

I have a WSDL from a webservice for which I don't have the implementation.
In order to create a client app, I'd like to build a dummy implementation of this WSDL.
Is there any way to create either a WCF service from this WSDL or a oldschool web service ?
I only want the skeleton of the service (throw new NotImplementedException() is ok). Then I will implement a custom test behavior.
ths

For WCF, you can actually do this for the most part. Just use svcutil.exe (or the VS Add Service Reference wizard) to add a reference to the service.
This will generate all data and service contracts, and then all you need to do is add a new class to your project that implements the service contract interface that svcutil generated (which is just a few clicks in VS).