Consuming Wcf from classic asp (with datacontract) - wcf

I'm currently developing a WCF service (Service.svc) and I would like to consume it with classic ASP. Naturally, i first checked how to on Google and Mdsn Library. I managed to connect my service.
But here is the problem, i can call simple method like :
string GetData(int i)
But I have some DataContracts too a methods signed like this :
IsAvailRef[] AreAvailable(MyInType data)
\With IsAvailRef as DataContract and so is MyInType.
And when I call these methods, I've an Asp error 'ASP 0106 : 80020005' saying "A data type not supported has been detected."
So here is my question : Can't we use DataContract with VB script ?
This is the signature of my function in the library generated by regasm.exe like explained in this article : http://msdn.microsoft.com/en-us/library/ms752245.aspx
[id(0x60020000)]
HRESULT AreReferencesAvailable([out, retval] SAFEARRAY(_IsAvailRef*)* pRetVal);

I believe DataContract is a class and is not a valid VBScript subtype:
http://www.csidata.com/custserv/onlinehelp/vbsdocs/vbs6.htm
You can probably call it's methods, however I doubt you can store it in a variant.

Related

WCF and System.Drawing.Color

Thanks for the quick answers all. But I am looking for an answer and not a workoaround (serialize as string) as I want to know how to use other types from the framework
I am fairly good at WCF but I think I am still at the beginners stage since I cannot serialize a System.Drawing.Color.
This is my Service Contract
using System.Drawing;
using System.ServiceModel;
namespace wcfServer
{
[ServiceContract]
public interface IColorService
{
[OperationContract]
Color DoWork();
}
}
And here is an implementation
public class ColorService : IColorService
{
public Color DoWork()
{
return Color.Yellow;
}
}
However, at the client WCF doesn't use a System.Drawing.Color but it generates it own color type (a struct) ?
The net result is that the color Yellow does not arrive at the client
I thought that this wasn't a problem since the .net Color type is marked with the serializable attribute
Kind Regards, Tom
Colors are usually a mess - there are so many of them. Just convert to color to a 32-bit ARGB structure (the Color class has a method that does this) and use that in your WCF interface. If you want to be extra careful, define your own struct with A, R, G and B (as bytes, WPF has them as doubles, but nobody really needs that), and decouple your service from any specific UI platform.
However, at the client WCF doesn't use a System.Drawing.Color but it generates it own color type (a struct)? [...] I thought that this wasn't a problem since the .net Color type is marked with the serializable attribute
I'm assuming you use basicHttp or wsHttp here. What I'm saying doesn't go for all bindings.
Communication between a WCF service and client has nothing to do with .NET. Keyword is interoperability. The client doesn't have to be written in .NET, it might very well be a PHP or Java or whatever kind of client.
WCF therefore uses SOAP to send and receive data, which all major programming languages implement. So to let a service and client exchange data, a format for that data has to be defined. You can't say "Hey, I'm gonna send a System.Drawing.Color", since that may very well not be a valid class or struct definition in the client's language.
So your service defines a WSDL, containing a schema definition, where the contents of the Color struct will be copied from System.Drawing.Color. It won't be linked to the .NET framework from the point it gets serialized and sent over the wire.
I was able to fix this problem by using "KnownTypeAttribute" on a data contract. So you can try "ServiceKnownTypeAttribute" on a service contract like this :
[ServiceContract]
[ServiceKnownType(typeof(System.Drawing.Color))]
public interface IColorService
{
[OperationContract]
Color DoWork();
}
This works fine assuming that the client code is also using .NET.
The strategy with "KnownType" worked well in my project http://www.nquotes.net/ and let me avoid additional serialization hassle. They should have included Color as one of the base types (as they do with Guid, for example, which is "known" automatically - http://msdn.microsoft.com/en-us/library/ms731923.aspx ).

Client side code is not generated for XElement properties

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.

Problem while using MessageContract attribute : Exception -> End element 'Body' from namespace 'http://schemas.xmlsoap.org/soap/envelope/' expected

I am moving my WSE3 web services to the WCF. But the client is WSE3 client.
All the Operation Contracts return an instance of the MessageContract classes. This works for 2 operations but somehow fails for one operation of the same service contract. The error is:
The signature or decryption was invalid.
When I look into WCF trace file, I found the following:
The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation 'MyOperationName'. End element 'Body' from namespace 'http://schemas.xmlsoap.org/soap/envelope/' expected. Found element 'MyOperationName' from namespace 'urn:MyProject:MyModule:2006:04:MyAuthorizationModule'.
My observation is, when I use XmlRoot attribute to decorate response class (instead of using MessageContract attribute), I do not get this exception. However, response object cannot be deserialized. i.e. I can see the XML response in input trace but since the expected XML structure does not match, service call returns null at client side.
The MessageContract class has only one public property (MessageBodyMember) which returns an instance of another class which is decorated with the XmlRoot attribute. This class (which is decorated with xmlRoot) has a property which gives the Collection of objects of some entity class which has XmlElement properties in it.
Which all things I need to check/verify?
I can provide class code snippets if required.
There was no problem with the MessageContract which was used in response. The problem was with the input parameter to the OperationContract.
When I looked at the old WSE3 web service proxy method (WebMethod) and created the OperationContract for it in WCF service, the OparationContract I created did not accept any parameter.
While investigating this issue, I used the svcutil.exe to create .NET classes from the WSDL of the old WSE3 service. When I looked into the specific OperationContract I came to know that I need to create a MessageContract which will be used as request parameter to the OperationContract. So I created a MessageContract without any MessageBodyMember. When I used it, the problem got resolved.
Obviously, if we compare the OperationContract signature with the ASMX WebMethod signature, they dont match since we have introduced input parameter. But this works. I do not know how and why. It would be great if someone explains why it works.

Calling a WCF service from Java, redux

Calling a WCF service from Java
Following on from the above question, does anyone know how to get wsimport to see WCF properties marked with the [MessageHeader] attribute, and hence generate fields for said properties on the generated Java proxy classes?
Unfortunately the requirement has now come up (from another vendor, le sigh) to use [MessageHeader] as well as [MessageBodyMember] and as a result the Java interop is breaking - which is making me a Sad Pandaâ„¢. And nobody wants that.

.NET webservice using an instance of a parameter type?

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.