In my WCF web method i have a operation contract which accepts List of string array, but when i create a proxy for this service it converts that to List of List of string.
List<string[]> to List<List<string>>.
Can anyone please tell me if there is some way i can make sure that this does not happen and my proxy also contains List
Thanks
If you are using the Service Reference in VS, go to Configure Service Reference and set the collection type to System.Collections.Generic.List. That should fix it. If you are using svcutil the switch is /collectionType: http://msdn.microsoft.com/en-us/library/aa347733.aspx
Have you tried editing the code generated by svcutil.exe? Editing generated code = ugh, I know, but ...
Take a look at the advanced settings, and you can change the collection type there:
I got this image from http://i.stack.imgur.com/bkwoc.png
Related
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.
I wish to create a MonoTouch MTDialog-based app that upon launching adds a single element to the MonoTouch Dialog and then render the screen. This single element will be a JsonElement similar to this -
var je = new JsonElement ("Dynamic Data", "http://tirania.org/tmp/demo.json");
as shown in the sample application. However, instead of referencing a pre-built json file on a server, I wish to have the url point at a WCF OData service which will dynamically build the json data.
I am not sure what is the easiest way to do this. I am a bit lost after reading over the documentation. Is there some library I can include in my server-side C# app which I can then use to build out the elements and return as a json string of information?
I already have a WCF application up and running and just need to add an entry point which will call the method to create some simple json data for MonoTouch dialog to consume.
Any examples or suggestions are greatly appreciated as I am trying to get a simple solution completed by this weekend.
You're looking for a C# JSON library? How about JSON.NET http://james.newtonking.com/pages/json-net.aspx
You might also look at ServiceStack.NET -- they have a MonoTouch client.
I have a WCF web service that I am working on and I built it and was delighted to find that I could use complex types in it. I added some and then realized that they were still not useable as those types on the client end. This is an internal web service so these types are known on both sides. Anyway, that's not the problem, as I took the complex types out, but I think it may have left some residual issues.
When I then changed my additions to all be base types (string, date, int, etc) then added the web service to the client project, I got a "[enumtype] is already defined" error. It occurred in the reference.cs file so I opened it up. Sure enough there were duplicate enums. Plus there were a bunch of helper (serializing) functions. The duplicate enum was from code that had been in there before I picked this web service up to work on. It had not caused an issue previously.
I opened up the reference.cs for the previous (successful) service reference. It did not have the duplicates or functions and also I noticed a difference between the entries that were in there. The reference.cs that was failing to compile had this additional attribute in several places:
[System.ServiceModel.XmlSerializerFormatAttribute()]
I also see that my new failed code was using string[] and the old was using ArrayOfString. I did not intentionally change this, but must have somehow set something differently in the process.
Does anyone have a few clues?
Thanks!
Have you tried deleting the service reference from the project and re-adding it? You may have to manually remove some (or all) of the serviceModel contents too. If that is the only Service Reference then definitely remove the serviceModel element contents too.
Once its all gone, re-add the Service Reference. If you're still having problems then it may be that the service metadata is generating invalid WSDL causing the duplicate enums.
UPDATE: Just for verifying the WSDL is not valid, you could try creating the service proxy manually using the SvcUtil command line utility. It generates your proxy code like Visual Studio does and may give you more troubleshooting info.
After a lot of experimentation this is what I found out:
Our web service up to this point was using the Request / Response classes for input and output. There were required in 1.0, and were a carry over from that. I attempted to create a simple entry point that sent in a string and returned a string. This compiled ok, but:
Although you can use regular types for input and output, if you are using Request / Response types exchanges for other entry points, then you cannot.
Mixed method of request / response and regular types will compile, but it will not successfully import (at least into Visual Studio 2008). What ends up being created seems to be an attempt to create input and output classes for all of the functions to translate them to their complex types, along with the Request / Response types which creates duplicate entries and will not compile.
This then also means that you cannot send in a request object and return a string (which is how I found out that this was not allowed) – this generated an error in the unit test, which started me down this path.
So if you have a request / response web service, all functions must follow that protocol.
I'm having very strange issue with my WCF Service Proxy client generated by "svcutil.exe" . My WCF Service works very fine if I don't have a function that returns DataTable. As soon as I add a method that returns a DataTable the client generated by svcutil.exe is behaving very strangely. The Interface is no longer found and client is not able to call the service. But if I add as a Service Reference its working very smoothly. I know its not a good habit to use DataTable as a return type but I need to. I cannot use the Service Reference :-( Any idea why its behaving or what I'm missing!!!
Have a look at the DataTableSurrogate class. It is used by the SyncFramework for serialization and really easy to use.
MSDN DataTableSurrogate
You shouldn't really serialize datasets, instead you should use datamodels and keep anything to do with datasets, tables, readers etc on your backend & in the business layer.
But.. if you want to do so you need to add the following "include" in svcutil, which is causing your issue. (Tells to reuse the types defined in System.Data.dll and not generate them in the proxy)
/r:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I got a class called "Board" and one of its property's is an ObservableCollection. When i send the ObservableCollection through WCF (from server to client) end call it from my proxy, it's turned into an Array, which is no good for me.
Can i keep the ObservableCollection after being sent, or do i have to kick the Array till it becomes an ObservableCollection again?
Check out the 'Configure Service Reference' option in the context menu in VS for the reference. You can choose the collection type that is transmitted across the service. By default I think it is set to array but there are several choices (I believe list and observablecollection are options).
EDIT: I just checked, and unfortunately observable collection is not one of the choices. It looks like you'll have to pick from:
Array
ArrayList
LinkedList
List
Collection
BindingList
By default - no, you cannot do anything about it. WCF will serialize your structures into something that can be represented with XML schema. XML Schema has no knowledge of anything but raw, and fairly simplistic data structures. You can only transfer concrete, raw data - no "magic" behavioral addon.
There is one solution to the problem, IF you own both ends of the wire: you could put your service and data contracts into a separate class library assembly, and share those between server and client. In that case, you only ever have one single implementation of your data contract - your ObservableCollection.
If you share that assembly between your service (implementation) class, and the client (add the reference to that assembly before you "Add Service Reference" from Visual Studio!), then your client should pick up that ObservableCollection and continue to use that (instead of creating a XML schema compatible Array on the client side).
Thank you both for the answer.
I will look at both solutions when i continue the project, and will start with try and change the Collection send through the wcf service.
I'll let you know what works for me...