Click here to Skip to main content
14,828,871 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I've been having the following problem:
I have a WCF project, MyService, which references another project, MyProject. This other project has a Class called MyClass and I am passing it as a parameter to a WCF Method.
Now when I test my WCF service in a simple Console app I need to pass an Object of the type MyService.MyClass, but this Class is non-existant! It should be MyProject.MyClass.
I have checked that everything in MyClass is Serializable, so that should not be the problem.
So far the only thing I do is pass MyClass to a Method and nothing else. It does not call other Methods in MyClass whatsoever.
And actually, in my Console app I can instantiate all kinds of stuff from MyService that are actually defined in MyProject.
Why does my WCF service/Console app think that all those Classes belong to MyService instead of MyProject?

I have the MyProject referenced in both service and client side.
What's more, this worked a few days ago. I made some changes to MyProject (not MyClass or any Class it uses though) and now it doesn't work anymore.
My ServiceContract looks as follows:
Public Interface IMyService
   Function DoSomething(mc As MyProject.MyClass) As Integer
End Interface

Here is the Service.
Public Class MyService
   Implements IMyService

   Public Function DoSomething(mc As MyProject.MyClass) As Integer Implements IMyService.DoSomething
      ' DoMoreStuff returns an Integer.
      Return SomethingCompletelyDifferent.DoMoreStuff(mc.DoStuff)
   End Function
End Class

MyClass is defined as follows:
Public Class MyClass
   ' Lots of Properties, all of which are serializable and
   ' contain nothing more than Strings and Integers and some Enums.
   Public Function DoStuff As AnotherClass
      ' Do stuff with non-serializable Classes and return a non-serializable Class
   End Function
End Class

SomethingCompletelyDifferent and AnotherClass stay within the Service and do not communicate to the client app. So I do not expect those to be the problem. My client app has a reference to MyProject and simply does the following.
Dim service As ServiceReference.MyService
Dim mc As New MyProject.MyClass
service.DoSomething(mc) ' Error here. Cannot convert MyProject.MyClass to MyService.MyClass.

Now where did it get MyService.MyClass from?
Updated 30-Oct-11 6:06am

1 solution

Hi Nearling,

I usually place data classes in a separate assembly, and then reference that assembly in both the client and service implementation project. Without this approach WCF will attempt to generate client side data classes for you, which usually works quite well. Anything apart from DataMembers will not be available to the client though.

I often use svcutil[^] directly on the assembly implementing the service for client service reference generation, this way I don't have to actually have the service up and running, and I don't need to configure mex for metadata exchange.

WCF will try to use the referenced assemblies if at all possible. Unless I need something really efficient I use Data Contracts[^] - You have more control over how WCF serializes your data.

Naerling wrote:
Now where did it get MyService.MyClass from?

It was most likely generated for you by Visual Studio when you added the service reference.

  1. CommonTypes.dll - common data types goes here
  2. ServiceImplmentation.dll - references CommonTypes.dll
  3. serviceClientImplmentation.dll - references CommonTypes.dll, remember to add the assembly before referencing the service
  4. serviceRunner.exe - references CommonTypes.dll and ServiceImplmentation.dll
  5. clientApplication.exe - references CommonTypes.dll and serviceClientImplmentation.dll

I usually implement the service reference in it's own assembly, as I usually also add an error handling wrapper around the service reference.

Best regards
Espen Harlinn
[no name] 30-Oct-11 11:51am
My 5! Comprehensive Answer. OP should take advantage of WCF by using wonderful concepts like "Data Contracts".
Espen Harlinn 30-Oct-11 11:53am
Thank you RaisKazi!
Sander Rossel 30-Oct-11 12:09pm
Hi Espen, thanks for the answer. And by the way, It's nAErling. Don't worry SA made this mistake too ;)
Not sure I understand what you are saying. I have updated my answer.
Are you saying MyClass should have the DataContract Attribute and all Properties DataMember?
Because those are not actually being communicated between service and client. They need to be set at client side and DoStuff uses them internally.
Espen Harlinn 30-Oct-11 12:24pm
Are you saying MyClass should have the DataContract Attribute and all Properties DataMember?
It's not required - [Serializable] usually does well enough, but as I mentioned, you have a bit more control.
Sander Rossel 30-Oct-11 12:44pm
Well, it was already Serializable, and that didn't work. So I tried defining everything as DataContract and DataMember, but it has the same effect. MyProject.MyClass is not accepted in the Service, only MyService.MyClass. MyService.MyClass was indeed generated by VS2010.
I tried deleting the ServiceReference and re-add it, but that didn't work either.
I checked out Reference.svcmap and Reference.vb. That was where the MyService.MyClass was defined. I could fix the problem by editing this. But why isn't it correctly generated in the first place? I have the MyProject referenced, so it should recognize it.
Espen Harlinn 30-Oct-11 12:48pm
I'm not sure if you have declared MyClass in a separate assembly (CommonTypes.Dll) - WCF can only reuse the type if it knows about it at service reference generation time, so you have to add the assembly (CommonTypes.Dll) to the assembly before adding the service reference.

BTW: All [Serializable] elements needs a default constructor ( one that takes no arguments )
Sander Rossel 30-Oct-11 12:58pm
GAAAAHHH!!! I just found out I was referencing to x86 folder, but building in AnyCPU... Fixed my building configuration and my references. Everything suddenly worked. It sucks to not work on my own computer... :sigh:
Thanks for the time and trouble though. My 5, it was certainly educational :)
Espen Harlinn 30-Oct-11 13:00pm
Excellent :)
Well, correct approach, good explanation and the discussion effort. Certainly my 5. The-one-who-should-not-be-named-because-no-one-can-spell-it should be satisfied. :-)
Espen Harlinn 31-Oct-11 5:10am
Thanks, Sergey :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900