How to generate proxy class for client?

I written WCF service hosted by windows service using the netNamed binding.
But I discovered the svcutil cannot generate proxy code. I don't know why.

My program is a windows service which have WCF service, the client program
is a win-form application. The environment is not allow any http proxy.
How should I do?

Well... what *does* happen?

Have you enabled metadata exchange (mex) for this service? mex is
needed to generate a proxy, as is visibility of the service.
Boilerplate IIS-based WCF services tell you how to do this if you
browse to the svc file, but I'll quote it (bottom).

Finally - note that if you use a shared service assembly then you
don't need mex at all - you can just use ClientBase<T> for T = your
contract (or a trivial subclass, since ClientBase<T> is abstract and
doesn't expose the Channel; I use a subclass that simply exposes the
base.Chanel). A shared assembly is viable in this type of closed
scenario, but is not suited to cases where external entities need to
call your service (i.e. B2B etc).

Marc

--- mex ---

If you have access to the service, you can enable metadata publishing
by completing the following steps to modify your web or application
configuration file:

1. Create the following service behavior configuration, or add the
<serviceMetadata> element to an existing service behavior
configuration:

<behaviors>
<serviceBehaviors>
<behavior name="MyServiceTypeBehaviors" >
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>

2. Add the behavior configuration to the service:

<service name="MyNamespace.MyServiceType"
behaviorConfiguration="MyServiceTypeBehaviors" >

Note: the service name must match the configuration name for the
service implementation.

3. Add the following endpoint to your service configuration:

<endpoint contract="IMetadataExchange" binding="mexHttpBinding"
address="mex" />

Note: your service must have an http base address to add this
endpoint.

The following is an example service configuration file with metadata
publishing enabled:

<configuration>
<system.serviceModel>

<services>
<!-- Note: the service name must match the configuration
name for the service implementation. -->
<service name="MyNamespace.MyServiceType"
behaviorConfiguration="MyServiceTypeBehaviors" >
<!-- Add the following endpoint. -->
<!-- Note: your service must have an http base address
to add this endpoint. -->
<endpoint contract="IMetadataExchange"
binding="mexHttpBinding" address="mex" />
</service>
</services>

<behaviors>
<serviceBehaviors>
<behavior name="MyServiceTypeBehaviors" >
<!-- Add the following element to your service
behavior configuration. -->
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>

</system.serviceModel>
</configuration>

I have interest more about a shared service assembly method, how to do that?


"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:Om7rdZRnHHA.568@TK2MSFTNGP02.phx.gbl...
> Well... what *does* happen?
>
> Have you enabled metadata exchange (mex) for this service? mex is needed
> to generate a proxy, as is visibility of the service. Boilerplate
> IIS-based WCF services tell you how to do this if you browse to the svc
> file, but I'll quote it (bottom).
>
> Finally - note that if you use a shared service assembly then you don't
> need mex at all - you can just use ClientBase<T> for T = your contract (or
> a trivial subclass, since ClientBase<T> is abstract and doesn't expose the
> Channel; I use a subclass that simply exposes the base.Chanel). A shared
> assembly is viable in this type of closed scenario, but is not suited to
> cases where external entities need to call your service (i.e. B2B etc).
>
> Marc
>
> --- mex ---
>
> If you have access to the service, you can enable metadata publishing by
> completing the following steps to modify your web or application
> configuration file:
>
> 1. Create the following service behavior configuration, or add the
> <serviceMetadata> element to an existing service behavior configuration:
>
> <behaviors>
> <serviceBehaviors>
> <behavior name="MyServiceTypeBehaviors" >
> <serviceMetadata httpGetEnabled="true" />
> </behavior>
> </serviceBehaviors>
> </behaviors>
>
> 2. Add the behavior configuration to the service:
>
> <service name="MyNamespace.MyServiceType"
> behaviorConfiguration="MyServiceTypeBehaviors" >
>
> Note: the service name must match the configuration name for the service
> implementation.
>
> 3. Add the following endpoint to your service configuration:
>
> <endpoint contract="IMetadataExchange" binding="mexHttpBinding"
> address="mex" />
>
> Note: your service must have an http base address to add this endpoint.
>
> The following is an example service configuration file with metadata
> publishing enabled:
>
> <configuration>
> <system.serviceModel>
>
> <services>
> <!-- Note: the service name must match the configuration name
> for the service implementation. -->
> <service name="MyNamespace.MyServiceType"
> behaviorConfiguration="MyServiceTypeBehaviors" >
> <!-- Add the following endpoint. -->
> <!-- Note: your service must have an http base address to
> add this endpoint. -->
> <endpoint contract="IMetadataExchange"
> binding="mexHttpBinding" address="mex" />
> </service>
> </services>
>
> <behaviors>
> <serviceBehaviors>
> <behavior name="MyServiceTypeBehaviors" >
> <!-- Add the following element to your service behavior
> configuration. -->
> <serviceMetadata httpGetEnabled="true" />
> </behavior>
> </serviceBehaviors>
> </behaviors>
>
> </system.serviceModel>
> </configuration>
>
>
>

Create a library dll with your data-entities and service-contracts;
compile it. Reference that dll from both the client and server. At the
server create a service implementing your service-contract. At the
client, use the normal config stuff to specify the end-point, but
instead of using a proxy you can use something like (to define a
concrete wrapper):

public sealed class SimpleClient<T> : ClientBase<T>
public new T Channel { get { return base.Channel; } }
}

You should now be able to do things like:

using(SimpleClient<IMyContract> client = new
SimpleClient<IMyContract>) {
client.Open();
MyEntity entity = client.Channel.MyOperation(args);
client.Close();
}

Does that make sense? The other advantage of shared libraries is that
you get the methods and implementation (not just the data) at the
client. But as before: only suited to a subset of situations where you
control both client and server.

Marc

On May 23, 5:53 am, "Marc Gravell" <marc.grav...@gmail.com> wrote:
> Create a library dll with your data-entities and service-contracts;
> compile it. Reference that dll from both the client and server. At the
> server create a service implementing your service-contract. At the
> client, use the normal config stuff to specify the end-point, but
> instead of using a proxy you can use something like (to define a
> concrete wrapper):
>
> public sealed class SimpleClient<T> : ClientBase<T>
> public new T Channel { get { return base.Channel; } }
>
> }
>
> You should now be able to do things like:
>
> using(SimpleClient<IMyContract> client = new
> SimpleClient<IMyContract>) {
> client.Open();
> MyEntity entity = client.Channel.MyOperation(args);
> client.Close();
>
> }
>
> Does that make sense? The other advantage of shared libraries is that
> you get the methods and implementation (not just the data) at the
> client. But as before: only suited to a subset of situations where you
> control both client and server.
>
> Marc

I'm doing this as well, though slightly different. (I'll look at it
tomorrow.) I like it because if the proxy isn't kept up to date,
you'll end up with runtime errors. By doing it direct, you'll get
compiletime errors.