0

I have two WCF services I am adding reference to in my application. Both these services have an object called X, which is the same object.

The problem is after adding the references in my application, I am getting two different objects, with the same exact structure, but with different namespace. This prevents me from casting between them and forces me to create two different objects, one for each service.

Please notice I don’t want to use dll’s.

SuperFrog
  • 7,631
  • 9
  • 51
  • 81

1 Answers1

1

Please notice I don’t want to use dll’s.

You'll have to. When you generate a WCF proxy, you have the option to reuse types from referenced assemblies. This have to be assemblies containing the types also used by the service. See also How to: Configure a Service to Reuse Existing Types.

Of course as @Franck pointed out in a comment, it's possible to intervene in the serialization process. You can also use a tool like AutoMapper.

More interesting is your actual problem: why don't you want to use a DLL reference? Did you try that but do you for example wish to deploy a single-file application, then merge the assembly in your executable.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • 1
    He dont have to do that. When you deserialise you simply have to remove the namespace from the format. I did that with a bunch of custom object at my last job and it's only 1 to 5 line of code. SerializationBinder : http://msdn.microsoft.com/en-us/library/system.runtime.serialization.serializationbinder.aspx – Franck Oct 24 '13 at 11:50
  • 1
    Yeah but adding custom (de)serialization is a silly thing to do when adding a DLL reference is two clicks' worth and will solve the problem more elegantly. OP better explain **why** he doesn't want to do that. – CodeCaster Oct 24 '13 at 11:52
  • I only want to consume the service and update it when needed. I don't want dll's so I won't need to get a new file with every change the 3rd party does. – SuperFrog Oct 24 '13 at 12:16
  • If the third party does an update, you either have to put their new DLLs in your project or update your references and fix your serializer and republish your entire client. I really don't see how not adding DLLs is going to circumvent that. If their changes are backwards compatible, you can keep running on the old DLLs. – CodeCaster Oct 24 '13 at 12:18
  • In this scenario you are right. The purpose of the question was to check if a solution without dll's is possible. – SuperFrog Oct 24 '13 at 12:20
  • Well like I pointed out in my answer, you can implement custom serialization to ignore namespaces or use automatic mapping between the types. – CodeCaster Oct 24 '13 at 12:21
  • When dealing with Third Party service i prefer creating my own service that consume theirs and i connect my app on my own like that the fail safe structure is in my service and the communication stay the same for my app. if they change their things my service prevent my app from crashing and i know i only need to modify my service internally. Like that no need to update my app – Franck Oct 24 '13 at 12:49
  • I understand, but that doesn't mean you can't stick the DTO's you use between your app and your service in a DLL. – CodeCaster Oct 24 '13 at 12:53