![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
|
Welcome to Vista Forums we are your forum to discuss Windows Vista x64 and x86 systems. Whether you need help or just want to post an idea you have on Vista, this is the forum for you.
br> br> |
| |||||||
| | Thread Tools | Display Modes |
| | #1 (permalink) |
| Guest | 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? |
| | #2 (permalink) |
| Guest | Re: How to generate proxy class for client? 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> |
| | #3 (permalink) |
| Guest | Re: How to generate proxy class for client? 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> > > > |
| | #4 (permalink) |
| Guest | Re: How to generate proxy class for client? 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 |
| | #5 (permalink) |
| Guest | Re: How to generate proxy class for client? 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. |
| |
| |