We Keep Coding

difference between adding service reference and proxy class in WCF

I am new to WCF and wondering if there any difference between Proxy class and adding a service reference in client application?
Thanks

Adding service reference or generating proxy classes through svcutil.exe are basically the same. The first one actually calls svcutil like API to generated proxy classes in the References folder.
Using svcutil.exe you will get more fine grained control, which is good for big projects and long term maintenance, because command line options give you more flexibility than GUI of adding service reference.
And if you want to automate the generation of proxy classes and you develop both service and client, you may refer to this link at
is there a way to automatically update proxy object when updating service on WCF?

is not any difference in the level of use, they are two proxies.
Service reference: the advantage that gives you is, when you want to upgrade the service you can do directly from VS ("Update Service Reference), otherwise you'll have to do it manually.
you can find all infos in http://msdn.microsoft.com/en-us/library/bb628652.aspx

Local and WCF design for a class

I have a class which does stuffs with database, I want it to be used in these two ways:
1: a dll which can be referenced and used locally with direct call.
2: can be hosted as a WCF service.
when it is hosted as a WCF service many clients can connect to it but when it is used as a dll it just has one client.
how should I design my class?
For example I want to use it like this in dll form:
var a = new A();
and then call a.DoSomething()
or host it in WCF service and call server.DoSomething() from my client.

put your class into an assembly of it's own along with any support classes it needs and just reference that assembly from your WCF service.
Put your "api" in an interface, implement it fully in your "work" assembly, then implement it in your WCF service, but just haave that act as a proxy. Using an interface will mean you don't miss anything in your proxy.

Consuming the same WCF service from different addresses

I have a single WCF service but, until runtime, I don't know the correct address of the service. It may be :
http://example1.com/MyService.svc
// or
http://example2.com/MyService.svc
The service is used by a class library (DAL). I have two options:
Add a service reference to the
service (Visula Studio 2010) and
change the address at run-time. This
way VS-2010 will create WSDL and
other stuff for me (I'm not sure if this is even possible).
Create the proxy on the fly and set
the base service address. This needs
more work and if I make any change
to service, I need to generate WSDL
myself. Maintenance of this code is
not as easy as option one.
Which option to use? Also if option two is recommended by you, then should I my client wrapper class be singleton or I can create all the connection stuff on each call?

you can point to localhost or any other address in development then in production if the url changes you simply modify the web.config or the app.config where you have configured the WCF end point.

Option 1 - you get all the advantages and none of the pain. Just use something factory-oriented (i.e. Don't do new MyProxy(), but instead stick that code somewhere central like a static CreateMyProxy() method, or consider an IoC/DI container).
How to consume WCF web service through URL at run time?

Creating web service and client with shared types

I have created two wsdl files with shared types imported from xsd schema file.
After that I have created web services using interface generated by wsdl.exe tool with parameter /serverInterface.
Frist web service, have web method “RegisterData” with put into queue some complex object to be processed, by system “A”. As result of this method is returned Boolean (with tell us that object was registered successful).
Second web service, have web method “UpdateData” to update some data in system “B” based on this same object , with was changed in process on system “A”.
So in system “A” I have to create client for second web service, where I will call method “UpdateData” with this modified complex object us argument.
But when I’m creating this client in Visual Studio (by add web reference or add service reference) I have to create some namespace for client. And then when I’m trying to call “UpdateData” agument have different namespace for this same object received from first web service “RegisterData” method.
I would like to create first web service and second web service client , where I can use this same type object between them.
Thank you very much for help.

I don't believe this is possible with ASMX web services.
WCF does support this, however.
WCF Links:
WCF Developer Center
Beginner's Guide to Windows Communication Foundation
How to: Configure a Service to Reuse Existing Types
Actually, I think I may have misread your question. I though you were trying to share the same types between the client and the server. ASMX cannot do that. However, it appears you are trying to share the same types between two client proxies. You can do that easily using the WSDL.EXE tool.
Consider a schema, DataTypes.xsd, and two WSDL files that import it, ServiceA.wsdl and ServiceB.wsdl. To create the server interfaces, use:
wsdl /serverInterface /n:SharedTypes.Servers /out:Services.cs ServiceA.wsdl ServiceB.wsdl DataTypes.xsd
This will create interfaces which you can implement in order to create your services. These interfaces will both use one set of classes created from DataTypes.xsd. To create the proxy classes, simply use:
wsdl /n:SharedTypes.Proxies /out:Proxies.cs ServiceA.wsdl ServiceB.wsdl DataTypes.xsd
Notice that you do not need the /sharedTypes switch. That has a different purpose. It is for combining types of external services when you need to download the WSDL and any XSD from the service.
I have tried this using an example like yours, ServiceA posting a message into a queue, and a client picking up that message and sending it to ServiceB. It works quite well.

I agree that it is not possible to do this via the VS Web Reference functionality. To meet your requirements you can use the wsdl.exe utility with the /sharetypes switch.
For more information see Web Services Description Language Tool (Wsdl.exe)

wsdl.exe/svcutil.exe - is there a way not to generate the classes for types in the xsds during a Web service or client generation

We have a centrally managed object model for types in the schema in C#.
We want every one across the enterprise use that object model instead of using the one generated each time from wsdl/svcutil during a webservice client or service implementation.
is there a parameter(any other way) to wsdl/svcutil not to generate classes for the schema types during theie execution?

I believe what you are looking for is: svcutil.exe /r your-dtos.dll
/reference: -
Reference types in the specified
assembly. When generating clients, use
this option to specify assemblies that
might contain types representing the
metadata being imported. (Short:
/r)
In my opinion the tight coupling of the WCF proxy, endpoint channel, service operations and dto payloads into the same generated client proxy is a major design flaw.
This is what spurred me to solve in my open web services framework where I decouple the end point and payload which allows:
The same web service client (i.e. Soap11, Soap12, XML, JSON) to be able to call any web service.
It lets me also use the same DataContract dto instance in any of the web service clients
This has many benefits including being able to expose the same web service on a number of different end points without any extra configuration. Thus providing optimized web service endpoints for each consumer of my service. E.g.
XML for interoperability and strongly-type clients,
JSON for Ajax clients,
WSDL's for environments that prefer generated code (i.e. Flex Builder, VS.NET 'Add Service Reference' etc)
At my company we have developed hundreds of web services called by a number of different clients i.e. Ajax, Flash/ActionScript, C++, Silverlight, ASP.NET and being able to call the same web service through different endpoints has saved us countless hours.

I don't know of any specific setting or command line switch to enforce this - what you can do, but that's mostly a matter of training and enforcing by checking, is to share the class library (the assembly, in a DLL) with the developers, and make sure that everyone references that common class library and leaves the default settings in the "Add Service Reference" dialog (on the "Advanced" page) alone:
Here, you define that WCF will reuse any types it can find in any of the referenced assemblies - so if your developers add a regular reference to the common data contracts library, then WCF will use those types instead of re-creating them over and over again.
But again - that's only a "management by example and checking" kind of approach - I don't know of any technical way to enforce this.

If you remove the mex endpoint from the service config file, the client app will not be able to discover and generate the proxy objects.
A way to handle this situation if I understand your question correctly is to do the following:
Create a common set of DLLs that has the service, and datacontracts / shared object model.
Create a service using the contracts in the common dll instead of the contracts visual studio creates when you create a new service.
Remove the MEX endpoint from the server config file (this will essentially break proxy generation).
Have your client use the the common dll and manually create the channels on the client side (via channel factory etc...).
In this approach you do not use wsdl.exe/svcutil.exe at all since you are essentially bypassing the wsdl. You do not add service references either since you are manually managing the connections.
EDIT: Following this approach, the client can still try to generate proxy objects via wsdl.exe/svcutil.exe, but they won't get the correct information from the wsdl. They'll essentially generate a non-functioning / incomplete proxy.