This question has been asked many times but I can't find a solution.
I have a WCF service with a function that takes in a customer object. This customer object is in a separate project that both the client and server code reference. When I add the service reference to the client project, I choose the option to reuse data types. However, when I try to call the function on the client side and pass the customer object in, I get this error:
Error 39 Value of type 'Real.Namespace.Customer' cannot be converted to 'Service.Namespace.Customer'.
The "Real.Namespace" is the class it should be using. "Service.Namespace" is the auto generated class created by the service reference. I know this is supposed to work, so there must be some reason why it is unable to find the real class and reuse it.
I've tried this with very simple objects and it still won't work. Any ideas on why the auto generated code can't find the real class and use it?
Edit: I've tried using a very simple object just to see if I could get it to work. So right now I'm just using a test class that looks like this:
Namespace DTO
<DataContract>
Public Class Test
<DataMember>
Public Property Name As String
End Class
End Namespace
Related
i have added a service ref in my VB.NET application.
i can see the objects in the object browser. i need to log in first to obtain a session ID.
when I try
dim client as new serviceReference1.IGPSBulkData
I get an error
'New cannot be used on an interface'.
IGPSBulkdata is the only option that includes the login function so Im not sure how to make this call
any ideas?
When you add a service reference several classes are being generated from the service' WSDL. Take a closer look at the generated code 🤓 There will be something like GPSBulkDataClient.
This generated client class can be used to communicate with the service.
The error is correct; you cannot instantiate an Interface.
If you open Object Browser in Visual Studio and search for IGPSBulkData you should be presented with a list of classes which implement it. From there you can instantiate your client object (if that's what you need to do with that class).
So if there was a class called GPSBulkDataThing which implements IGPSBulkData your code might resemble:
Dim client as serviceReference1.IGPSBulkData = new GPSBulkDataThing(maybe with some arguments here)
Just starting to investigate the Yodlee soap example and I am having problems with an
Unable to cast object of type 'System.Xml.XmlNode[]' to type 'BankData'.
error in the DisplayBankData class. I have tried downloading and creating the Yodlee dll from the wdsl definitions from 2014Q3WSDLs as well as using the DLL that came with the download with no success. The same problem is also happening with the CardData class (and possibly others)
Am I missing something or is there a problem with the wsdl definitions supplied?
After spending many hours trying to work out whats going on here, I have finally worked out that there is something wrong with either the WDSL files generated by Yodlee, or the way that WSDL.exe interprets the WSDL files.
The actual cause of it is because the WSDL does not seem to indicate what type is returned under ItemData1.Accounts, this is because it can be either BankData or CardData, since VisualStudio does not know what type to expect, it de-serialises the object as an XML node.
The way I have managed to get round this is when you use the WSDL.exe to produce the yodleeProxies.vb file, you will need to go into the generated file and then find the defenition for the ItemData1 Class
Partial Public Class ItemData1
You will need to change
Public Property accounts As Object()
to
Public Property accounts As BankData()
Then it knows that the object will be of type BankData
I have also added a new property that expects CardData so that CardData will appear under this one, and will de-serialise correctly
Public Property accounts2 As CardData()
Get
Return Me.accountsField
End Get
Set(value As CardData())
Me.accountsField = value
End Set
End Property
So thats my hack on how to resolve it, if any one else has worked out a more elegant way of getting round this, please do let me know.
I found adding the XmlInclude() attribute below to the ItemData1 class in the proxy file glyn johnston mentioned solves the issue - apparently the deserializer doesn't know to consider ItemAccountData and its descendants when deserializing that property.
I believe 'accounts' should be kept as an array of objects as there are several types that inherit from ItemAccountData including CardData, BankData and others, and upon inspecting the WSDL directly 'accounts' appears to be defined as a 'List' of type 'anyType'.
It is possible it is defined this way to allow for adding newer types in the future without causing de-serialization issues, so basically you need to inspect each element in the array and determine its type individually, ignoring the types you do not know or care about.
...
[System.Xml.Serialization.XmlInclude(typeof(ItemAccountData))]
public partial class ItemData1 {
...
I believe the source of the problem is the Xml deserializer doesn't consider types that aren't somehow tied to the definition of the class ItemData1 via its method signatures, properties etc. and the XmlInclude() is the attribute to use to fix that.
I am creating an XML web service that passes an array of custom types. In my consuming code I am referencing the code as a web reference which I have given the namespace MYWS. Now in code I am trying to assign the results of my web service call to an array of my type like so :
'instance to make a call to my web service
Dim srv As New MYDWS.ServiceNameWSSoapClient
'array to hold the results
Dim arr() As MyClass
'assign the web service call results
arr = srv.myWebMethod()
When I do this the complier complains, saying:
Value of 1 dimensional array of my.namespace.MyClass cannot be
converted to 1 dimensional array of my.namespace.MYWS.MyClass because
my.namespace.MYSW.MyClass is not derived from my.namespace.MyClass
Now I understand the message, the thing is they are the same class. The class is declared in my calling code by the web service references a dll from that project. How do I tell the compiler that these are the same type? Any help would be very much appreciated. Thanks!
The upshot is that you have a namespace mismatch. If you right-click on MyClass in your example and select Go To Definition, where does it take you? I suspect that you may end up in a locally defined class.
The solution is to change
Dim arr() As MyClass
to
Dim arr() As MYWS.MyClass
Update based on information in comments
The problem with using the web service is that you cannot cast it to a local class.
You have a couple of options depending on exactly what you need out of the local class.
If you only need methods to act on the data in the class or you need additional properties, you can create a partial class in your environment that extends the class created by the web service. For example:
Namespace MYWS
Public Partial Class MyClass
Public Property SomeAdditionalData As String
Public Sub SomeMethod
' Perform some operations on the class members
End Sub
End Class
End Namespace
However, if you have calculations or other work embedded in the class, then you will need to get the data using the web service class, then copy the data from that class into your local class. If the properties have the same names, you could ease this task using reflection.
As another option, if you have control over the web service, you could change it to a WCF service. This will allow you to reuse the exact same class code on both ends of the communication pipe.
Found a solution to the problem. In the web.config I found this:
<add key="net.mydom.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
which was what the system automatically entered when I registered the web service. I got the error messages on screen, but everything compiled and ran w/o problem.
When I manually changed to this:
<add key="net.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
The error messages went away and everything continued to function as expected.
(That only took my 7 years to figure out...)
UPDATE:
Well, not quite the fix, but it must be close. After awhile, the problem came back, when I switched back to to:
<add key="net.mydom.mydom" value="http://localhost:7452/dir/mysvc.asmx"/>
it went away again...sure to come back at any time...
UPDATE
If I explicitly add:
imports net.mydom
to the top of my code, the message goes away again (even though I was explicitly using the full net.mydom. when typing the variables.
Ran across a weird problem with my WCF references this morning. In a nutshell, I have a duplex service set up so that a server can notify a client by sending objects in a data contract. When a client connects, it runs a function on the server to return a List(Of NewItem) based on what's in the shared queue of the service class. The trouble is, when I update my service reference in the client, it says the function returns a NewItem object, not a List(Of NewItem) object. I can go into the reference and manually change it to a List object and it'll transfer just fine. Any ideas why the service reference generator would arbitrarily change my return type?
Here's the relevant code:
<ServiceContract(
CallbackContract:=GetType(INotifyCallback),
SessionMode:=ServiceModel.SessionMode.Required)>
Public Interface INotifyService
<OperationContract()>
Function GetNewServerItems() As List(Of NewItem)
End Interface
<DataContract>
<Serializable>
Public Class NewItem
<DataMember()>
Public Property ItemNum As String
<DataMember()>
Public Property Timestamp As DateTime
End Class
<ServiceBehavior(
ConcurrencyMode:=ServiceModel.ConcurrencyMode.Single,
InstanceContextMode:=ServiceModel.InstanceContextMode.Single)>
Public Class NotifyService
Implements INotifyService
Shared _server_items As New List(Of NewItem)
Public Function GetNewServerItems() As List(Of NewItem)
Return _server_items
End Function
End Class
And in Reference.vb (simplified):
<System.ServiceModel.OperationContractAttribute(Action:="http://tempuri.org/INotifyService/GetNewServerItems", ReplyAction:="http://tempuri.org/INotifyService/GetNewServerItemsResponse")> _
Function GetNewServerItems() As NotifyGateway.NewItem()
You and I fell into the same trap: we both misread the VB.NET code generated for the proxy method as returning a single item. In fact, it is returning an array.
WSDL uses XML Schema to describe the shape of the request and response. XML Schema has no concept of a "list", only of a sequence. By default, when it sees a sequence of items, "Add Service Reference" generates an array. You can change this to generate a "List", simply by changing the collection type on the "Advanced" tab of the "Add Service Reference" or "Configure Service Reference" dialogs.
When adding a reference the way you did, you should change the "Collection type" in the Advanced Service Reference Settings (Add Service Reference dialog) to "system.Collections.Generic.List". By default it is "System.Array".
I would not recomend though using the Add Reference way because you lose control over the configuration of your WCF service, and VS adds a lot of garbage that you do not need, and that would make your client/service link harder to maintain.
Hope this helps.
There is another, less well-known, but more powerful mechanism for preserving the collection types without resorting to using the default collection type setting.
This mechanism is especially useful if you have CollectionDataContract classes that you use in your code on both sides of a WCF pipe.
The solution involves editing the svcmap that is generated as part of the WCF service reference and adding specific CollectionMapping entries for each of the collection types that you want to serialize. The primary thing to watch out for here is generics: if WCF finds more than one match for a given class, it will refuse to generate the code.
To actually make the changes:
1) Show all of the files in the project which contains your WCF service reference.
2) Expand your service reference
3) Double-click on the Reference.svmap file to edit it.
4) Add your entries in the CollectionMappings section (if it does not exist, you can add it).
For example, in order to transfer generic Dictionaries and Lists, and to transfer StringCollections, you can have the following entries:
<CollectionMappings>
<CollectionMapping TypeName="System.Collections.Generic.Dictionary`2" Category="Dictionary" />
<CollectionMapping TypeName="System.Collections.Generic.List`1" Category="List" />
<CollectionMapping TypeName="System.Collections.Specialized.StringCollection" Category="List" />
<CollectionMappings>
The first item with a category of Dictionary will serve as the default Dictionary collection type and the first item with a category of List will serve as the default Collection type.
We have over 200 collection classes that we use this way for Silverlight and Windows Forms clients and it is an extremely efficient way to reuse your own code on both sides of a WCF pipe.
One important note: to reuse your classes, you need to ensure that the "Reuse types in referenced assemblies" flag in the service reference configuration is checked or that that the GenerateInternalTypes flag in the reference.svmap is set to false (these are the same thing).
I am trying to use Generic DataContract class so that I don't have to implement several types for a collection of different objects.
Exp :
I have a Profile object which contains a collection of objects.
So I want to have one Profile<Foo> and Profile<Foo1> where profile contains a collection of Foo or Foo1 objects.
I have been reading that WCF does not support generic classes and actually the error that I get is the following.
Type 'GL.RequestResponse.ProfileResponse1[T]' cannot be exported as a schema type because it is an open generic type. You can only export a generic type if all its generic parameter types are actual types.`
Now the ProfileResponse is this Profile object that I am trying to use.
Now in my host I am doing the following. :
ServiceConfig(typeof(ProfileHandler<EducationResponse>).Assembly,
typeof(ProfileRequest).Assembly,
typeof(Container)).Initialize();
This is dhe definition of the handler with the datacontract.
public class ProfileHandler<T> : RequestHandler<ProfileRequest,
ProfileResponse<T>>
The Container is using Windsor Container to register the objects.
The registration works fine but after I instantiated the Service Host for WCF processor, and call Open Method of the host I get the above error.
Is there really no way for me to write generic response requests for wcf with agatha ?
It feels like such a waste to have to define a Profile container class for each type being contained in that collection.
thanks.
One cannot have open generic handlers, because the server side needs to know what the type is.
One can use so called closed generic methods. This way the server side knows the types for witch to load the handler.
Also, one could potentially configure Agatha so that it allows to receive extra information related to the request. In this case, it would be the type wrapped in the response.
One could do this by defining a a BaseRequest class and having all the request extend this class. This class can have a property which takes the type of the response. Or the type to be wrapped in the response.
In the process, when examining the request, the process can get the type to be wrapped in the Response, so that i knows how to load the class.
I have not implemented this, since it would take too much time and I am not sure I want to be responsible for maintaining Agatha for our application, but this is how I would do it.