I have a Windows forms project and a Web Service project in my solution, and I'm trying to call the web service and return a customer object as the result. The problem is that when I try to receive the return object, I get an error that it can't convert it. For example, here is the signature for my webservice:
Public Function GetDriverByID(ByVal DriverID As Integer) As Driver
And here is the code I'm using to call it:
Dim d As Driver = mywebserviceinstance.GetDriverByID(1)
But I receive this compile-time error (wsDrivers is the name of the web reference I've added to my form project): "Value of type ProjectNamespace.Common.wsDrivers.Driver cannot be converted to ProjectNamespace.Common.Driver"
This "Common" namespace contains the Driver class, and I'm not sure why the return class from the web service isn't just a generic "Driver", but is instead a "wsDrivers.Driver", and I can't convert it back. Anybody know how I can deal with this type mismatch?
EDIT: Thanks for the explanations - this actually makes it clear what it's doing. However, is there any way that I can force it to use the actual type instead of the proxy (or, rather, is there any way to convert between the "real" instance and the "proxy" instance), or do I have to serialize the properties before I send them over the wire, and then manually de-serialize the return values?
This is actually pretty common. What's happening is that the Web Service has defined in it the definitions of all the types used in the web service. When you add a reference to that web service, it auto-generates a proxy type in a sub namespace of your namespace. That is what is being returned by your web service when you call it.
However, you probably are also referencing the same library that the web service does seperately that contains the same type. That is the type that is expected when you Dim Driver. That's why there is a mismatch.
The web service reference in a VB.NET or C# project can reference any type of web service and is not limited to those provided by ASP.NET. That is why Visual Studio creates proxy classes for each object which can be retrieved from the web service.
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)
I am aware that you cannot, nor does it make sense to serialize a SQL Connection. However I have an issue where identical code prevails on both our production and development servers and our production web service works fine, while our development machine fails (along with my local dev machine).
The error I get is this:
An ExceptionDetail, likely created by
IncludeExceptionDetailInFaults=true, whose value is:
System.InvalidOperationException: An exception was thrown in a call to
a WSDL export extension:
System.ServiceModel.Description.DataContractSerializerOperationBehavior
contract: http://tempuri.org/:IWFHandlerService ---->
System.Runtime.Serialization.InvalidDataContractException: Type
'System.Data.SqlClient.SqlCredential' cannot be serialized. Consider
marking it with the DataContractAttribute attribute, and marking all
of its members you want serialized with the DataMemberAttribute
attribute. If the type is a collection, consider marking it with the
CollectionDataContractAttribute. See the Microsoft .NET Framework
documentation for other supported types. at
System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String
message, Type type)...
The source code I have has the following method in it:
Public Function GetCentralConnection() As SqlClient.SqlConnection Implements IWFHandlerService.GetCentralConnection
Dim conn As New SqlClient.SqlConnection(My.Settings.MDISCentralConnection)
Return conn
End Function
When I review the WSDL from the production web service, I can clearly see the GetCentralConnection method being available to me.
If we can start a dialog to begin looking to what the solution might be, but I'm at my last nerve with why this service will not run on a different web server.
I have a problem with a webservice I'm calling from vbscript. The service has a method which I need to call, which has a Guid as one of the parameters. I don't know how to pass along the guid to the webservice. Tried it like this:
proxy.SiteExists "{A523D7D2-692A-4464-9B0F-FED023641F03}", "/site"
the proxy object (WCF service moniker) is created without any problems and I can call a test ping ok. The above causes the following error message:
"Type 'System.Collections.Generic.Dictionary`2[TKey, TValue]'
cannot be exported as a schema type because it is an open generic type.
You can only export a generic type if all generic parameter types are
actual types."
Maybe there's something wrong with the way I'm passing in the parameters, or passing a Guid as a string isn't correct?
My domain service has invoke operation method and returns a custom
type say 'User'. This class has many properties such as String,
Integer, Boolean, XElement. When I rebuild the solution to generate
client-side proxy, it generates code for the class User in the client
for all the properties, except for XElement. What is the fix for this?
Will RIA not generate any code for XNode or XElement types? Should
these elements be converted to String? Are there any fixes for this
error?
I'm using VS2010 SP1, .Net Framework 4, WCF RIA, Silverlight 5.
According to the Silverlight DataContract documentation, you can mark your classes as either opt-in using the DataContract/DataMember attributes or opt-out and rely on only serializing public scope class members. You need to show the code of the class you're having problems with to get better suggestions.
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