I have a WCF Service running SOAP and allowing Flex / Flash to connect to it using basicHttpBinding by using the 'Data' \ 'Import Web Service' option. Unfortunately when I consume and invoke this service within Flex it throws the following error...
Error: Cannot find definition for type
'http://schemas.datacontract.org/2004/07/System.Drawing::Size' at
mx.rpc.xml::XMLDecoder/decodeType()
...when using the following code...
// This will return an array of presentations
var service:PresentationAuthoring = new PresentationAuthoring();
var token:AsyncToken = service.getAllPresentationByClientId(
mClientId , mUserId , mWCFServiceHash );
token.addEventListener( ResultEvent.RESULT, onResult );
token.addEventListener( FaultEvent.FAULT, onFault );
This method returns an array of Presentation objects that are retreived by the service. At the moment there are no DataContracts and I'm allowing the POCO Presentation object to be serialised and punted out by the service that works fine. However, this class has a readonly property of the type System.Drawing.Size that derived from appropriate height and width properties. Looking through the generated code, it doesn't register a 'Size' class in the base import schema although it still seems to create a Size class.
An alternative has been to stop the derived property from being serialised using the [XmlIgnore] but that has not worked.
Ideally, I need a way of allowing my Flex application to communicate with my WCF service but it seems to choke on the System.Drawing.Size type and while I could change this, there are other framework types such as Point, Rectangle, etc, etc. that are utilised within the project. Has anyone else experienced this problem or can suggest an alternative approach to take?
[Please note that the WCF Service functions correctly when a .NET application consumes it.]
Kind regards and thanks in advance - S
Well the answer was to box the Size struct with a custom class that worked perfectly although it is somewhat irksome I might have to do this with (potentially) other native drawing structs. Ho hum.
Related
I have a WCF Data Service layer that is exposing POCO entities generated by the POCO T4 template. These POCO entities are created in their own project (i.e. Company.ProjectName.Entities) because I'd like to share them wherever possible.
I have a set of interfaces in another project (Company.ProjectName.Clients) that reference these POCO types by adding an assembly reference to the Company.ProjectName.Entities.dll. One of the implementation of these interfaces is a .NET client that I want to consumes the service using the WCF Data Service Client Library.
I've used the Add Service Reference to add service reference. This generated the DataServiceContext client class and the POCO entities that are used by the service. However, these POCO types gemerated by the Add Service Reference utility now have a different namespace (i.e. Company.ProjectName.Clients.Implementation.WcfDsReference).
What that means is that the POCO types defined in the interfaces cannot be used by the types generated by the utility without have to cast or map.
i.e. Suppose I have:
1. POCO Entity: Company.ProjectName.Entities.Account
2. Interface: interface IRepository<Company.ProjectName.Entities.Account>{....}
3. Implementation: ServiceClientRepository : IRepository<Company.ProjectName.Entities.Account>
4. WcfDsReference: Company.ProjectName.Clients.Implementation.WcfDsReference
& Company.ProjectName.Clients.Implementation.WcfDsReference.Account
Let's say I want to create a DataServiceQuery query on the Account, I won't be able to do this:
var client = new WcfDsReference(baseUrl);
var accounts = client.CreateQuery<Company.ProjectName.Entities.Account>(...)
OR: client.AddToAccounts(Company.ProjectName.Entities.Account)
, because the CreateQuery<T>() expects T to be of type & Company.ProjectName.Clients.Implementation.WcfDsReference.Account
What I currently have to do is to pass the correct entity to the CreateQuery method and have to map the results back to the type the interface understands. (Possible with a mapper but doesn't seems like a good solution.)
So the question is, is there a way to get the Add Service Reference utility to generate methods that use the POCO types that are in the Company.ProjectName.Entities namespace?
One solution I am thinking of is to not use the utility to generate the DataServiceContext and other types, but to create my own.
The other solution is to update the IRepository<T> interface to use the POCO types generated by the utility. But this sounds a little bit hacky.
Is there any better solution that anyone has come up with or if there's any suggestion?
Ok, a few hours after starting the bounty I found out why it wasn't working as expected on my end.
It turns out that the sharing process is quite easy. All that needs to be done is mark the model classes with the [DataServiceKey] attribute. This article explains the process quite well, in the 'Exposing another Data Model' section
With that in mind, what I was trying to do is the following:
Placing the model on a separate class library project C, sharing it with both webapplication projects A and B
Create the data service on project A
Add the service reference on project B
Delete the generated model proxies out of the service reference, and update it to use my model classes in project C
Add the DataServiceKey attribute to the models, specifying the correct keys
When I tried this it did not work, giving me the following error:
There is a type mismatch between the client and the service. Type
{MyType} is not an entity type, but the type in the
response payload represents an entity type. Please ensure that types
defined on the client match the data model of the service, or update
the service reference on the client.
This problem was caused by a version mismatch between project C (which was using the stock implementations on the System.Data.OData assemblies) and the client project B that was calling the service (using the Microsoft.Data.OData assemblies in the packages). By matching the version on both ends, it worked the first time.
After all this, one problem remained though: The service reference procedure is still not detecting the models to be shared, meaning proxies are being created as usual. This led me to opt out of the automatic service integration mechanic, instead forcing me to go forward with a simple class of my own to serve as the client to the Wcf Data service. Basically, it's a heavily trimmed version of the normally autogenerated class:
using System;
using System.Data.Services.Client;
using System.Data.Services.Common;
using Model;
public class DataServiceClient : DataServiceContext
{
private readonly Lazy<DataServiceQuery<Unit>> m_units;
public DataServiceClient(Uri _uri)
: base(_uri, DataServiceProtocolVersion.V3)
{
m_units = new Lazy<DataServiceQuery<Unit>>(() => CreateQuery<Unit>("Units"));
}
public DataServiceQuery<Unit> Units
{
get { return m_units.Value; }
}
}
This is simple enough because I'm only using the service in readonly mode. I would still like to use the service reference feature though, potentially avoiding future maintenance problems, as evidenced by the hardcoded EntitySet name in this simple case. At the moment, I'm using this implementation and have deleted the service reference altogether.
I would really like to see this fully integrated with the service reference approach if anyone can share a workaround to it, but this custom method is acceptable for our current needs.
I have searched google and exhausted a fair bit of my time trying to figure out what is going on with my WCF and client Windows form app.
I am continuously getting the following error
"Unable to set field/property Ingredients on entity type Datalayer.UnitOfMeasure. See InnerException for details."
...
inner exception is
"An item cannot be added to a fixed size Array of type 'Datalayer.Ingredient[]'."
Stack Trace -
at System.Data.Objects.Internal.PocoPropertyAccessorStrategy.<AddToCollection>b__0[T](Object collectionArg, Object item)
at System.Data.Objects.Internal.PocoPropertyAccessorStrategy.CollectionAdd(RelatedEnd relatedEnd, Object value)
The way I have configured my solutions I have a WCF web-service which reference my DataLayer class library, I have a windows app (test app) which references the WCF services as well as DataLayer project.
If I don't reference the DataLayer in my test app, this issues does not occur however I lose the ICollection<Ingredient> to simple Ingredient[] array. Now as you can see this becomes a coding pain to initialize the array every time.
Any idea anyone? thanks in advance.
I was running into this exact error, but the accepted answer wasn't quite the solution I needed. It turns out that the client was sending a List<Order> up to my WCF service, but since the Customer.Orders property was defined as an ICollection<Order>, the WCF deserializer deserializer just deserialized it in the simplest form it could, which was an array of type Order, i.e., Order[].
The only solution I was able to come up with was to change the property in question on my POCO objects from an ICollection<Order> to a HashSet<Order>. See Stop WCF Deserializing Empty ICollection into Zero Capacity Array for a few more details.
When you are adding reference to WCF service in the test using 'Add Service Reference' there is a option to configure the default collection type for the generate proxy on the client. The default i think is array, you can change it to a generic list.
In case you are using svcutil,that too allows the same thing.
Weird. I had this same error, and was doing the right thing, calling "ToArray()". Changed it to "ToList()" and it started working fine.
I am working with an XML web service using VB.NET, created using VS 2010. One of my web methods returns a collection(type that inherits from list) of custom objects. It's a simple return statement, it is my understanding that .NET handles most of the tricky protocol stuff as well as serializing/unserialzing of objects.
The issue is in my consuming application when I get the the return value of the web method that returns a custom collection I get an array of the custom objects. Is this normal behavior? It will be easy enough for me to take that array and insert it into a custom collection object but if I could I would like to skip this step. Googling hasn't returned anything that I found useful. Could anyone tell me if this is typical behavior? Thanks much!
Assuming you are using WCF, try adding CollectionDataContractAttribute to your custom collection, as per Customizing Collection Types section of Collection Types in Data Contracts.
In the case you are using your service by setting up a Service Reference in the consuming application, then an even easier method would be to right-click the service name, select Configure Service Reference..., and about 1/3rd the way down of the dialog that pops up there will be a dropdown with "Collection type:" label. Default is to use System.Array, but here you can easily change it to use whichever collection type you prefer.
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 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.