I have a WCF service, called A which implements IA. This server uses some classes that are defined in a common class (in a common dll referenced by the A service dll). I have another WCF service, called B which implements IB.
Now, A and B have service reference to each other. This worked fine. But now, when I try to update IB I have a problem. I get a custom tool error failing to generate the code for the service reference. Unchecking the “Reuse types in referenced assemblies” solves this issue, but then I have to cast each type to itself (actually).
I created a separate project, in A solution, that has reference to B service. Now, I am able to add service reference, but I get ambiguous error for all types that are defined in the common dll. Any idea how to solve this issue?
Related
I have an issue with the generation of a WCF Client. The main project is called TestX. In that project, I'd like to include a WCF Service named MgmtService. I can include that service in another project just fine.
I add the connected service reference and (on purpose) I name it ServiceReference1 (I have tried other arbitrary names as well to rule out a namespace clash - no change).
Immediately when I try to to compile, I will get the error message
The type name 'ServiceReference1' does not exist in the type 'TestX'
What really gets me is, that I can add an additional project (a simple DLL) and then add the reference there and it will compile just fine and work like a charm.
How can I debug this issue? It looks like there is an underlying issue and it's not the creation of the client itself.
Well, of course it was a namespace clash, although at some completely different place than expected.
I had the namespace TestX used and since this was a windows service type application it also contained a class called TestX. This in itself was not an issue until I added the WCF Client.
Adding the WCF Client created the type TestX.ServiceReference1 BUT the compiler now didn't know if to use the namespace TestX or the class TestX.
Renaming the class which previously existed fixed the issue.
I have a WCF service that I'd like clients to be able to reference using Visual Studio's "Add Service Reference" feature. They've been able to recognize the metadata endpoint, the interfaces, methods and data types appear in the Add Service Reference dialog, and it appears to successfully generate the proxy without a hitch - but when viewing the generated code file or viewing the classes in the object browser, there is no service interface generated from the ServiceContract - only the DataContracts are represented. When I point svcutil at the same endpoint URL from the command line, the generated file does contain the interfaces.
The service itself has been used in production for a while and seems to work fine
It uses a custom binding, but the exact same binding configuration (and other config settings) are used by another service that seems to work fine with Add Service Reference
One thing that is different is that this service uses a custom behavior (an attribute derived from IServiceBehavior). The interface is also in a different assembly from the concrete service type, although so are the data contracts.
Update:
What seems to be causing the problem, which I'd somehow overlooked, is that there are FaultContracts for some of the methods on this interface, and these FaultContracts are referencing an exception type that is [Serializable], not [DataContract] (as I think anything that derives from Exception must be). The exception type itself is represented in the generated code, but its public properties aren't (in either svcutil or ASR-generated code)
What seemed to be causing the problem, which I'd somehow overlooked, is that there are FaultContracts for some of the methods on this interface, and these FaultContracts are referencing an exception type that is [Serializable], not [DataContract] (as I think anything that derives from Exception must be). The exception type itself is represented in the generated code, but its public properties aren't (in either svcutil or ASR-generated code)
I have a WCF Service which returns some custom objects to a desktop client application. Both projects share the same ObjectLibrary.dll, however when the WCF server return these objects it is returning
ClientApplication.ServerReference.ObjectType
instead of
ObjectLibrary.ObjectType
Is there a way to get the WCF server to return the ObjectLibrary's class type?
When you configure the service reference, set the "Reuse types in referenced assemblies" checkbox, and ensure that either the "Reuse types in all referenced assemblies" radio button is checked, or else "Reuse types in specified referenced assemblies" is checked instead, and that all the shared assemblies have check marks next to them in the list below.
My mistake was that I was trying to reference the Service from the ObjectLibrary, and the Service contained a reference to the ObjectLibrary so it was creating a circular reference. I changed my solution so I had one project for object base classes, one for the service which referenced the base classes, and then defined the object methods in a third project which referenced the server and the base class dlls.
I am invoking a service through WCF and has encountered a problem with non-matching namespaces.
The object that is beeing sent though the service is in the namespace MyProject.Commons.BuisnessObjects, and I have verified this through WcfTestClient.
When I invoke a method clientside on the service (after initiated this with new MyServiceClient()), the method give me the correct objects, but with different namespaces.
The object is now of Web.MyService.Object. I have tried casting, but that didn't help.
Anyone who has seen this before?
Thanks, Tine
This is the expected behavior. It's how Web Services work. They are meant to be different types.
If you have added a service reference (i.e. WCF) rather than an old fashioned web reference, then you can match these up. Add a reference to the shared library defining your object type to the client before you add the service reference, then there is an option when you add the reference to re-use types.
This is because your types are not shared across service and client. Therefore the client does recreate for you your datastructures, in the Web.MyService namespace.
To avoid this you should share your data structure types between client and service by referencing your assembly containing your type BEFORE adding the service reference
You can find the detailed scenario and sample project there:
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html
Is it an acceptable programming practice to add a Service Reference to a Project where the Service being referenced is defined within the same VS Project? (Service and Service Reference are in the same Project)
example:
MyWebAppProj
-Services
--MyService
-Service References
--MyServiceServiceReference.MyServiceClient
-Default.aspx.cs uses MyServiceServiceReference.MyServiceClient
The rational behind this is that a Silverlight App may be added to the Project. If it is, we would have to expose all the Business Logic methods through a service layer, so why not just do that first and use them everywhere to stay standardized between web pages and Silverlight pages.
I can't see why you would want to do that at all.
If you're already inside the same project as the service, at the very least you've already got access to all the service/data contracts, so really, calling the service is already very, very easy. You can either use a ChannelFactory directly, or write your own custom ClientBase<T>-derived client proxy class (which is trivial), there's no reason why you'd want to add service reference in this case.
Furthermore, if you added a service reference, you'd then be stuck with a bunch of duplicate definitions in the same project, which makes little sense (yes, you can isolate the generated code into a separate namespace, but still).