I am using WCF Web API Preview 6 with its inbuilt Test Client to request a resource by Id. The object returns with all its data except for the ‘CreateDate’ and ‘LastModifiedDate’ properties which are of type DateTimeOffset and are empty. I have tried setting the values manually by calling DateTimeOffset.UtcNow and DateTimeOffset.Now and although the values are set on the object they never make it through to the other end in the response.
I have also tested this by changing my property types to DateTime and manually setting their values by using DateTime.Now and everything works fine and I get what looks like a DateTimeOffset value.
<CreateDate>2011-12-13T16:15:47.4269538+00:00</CreateDate>
<LastModifiedDate>2011-12-13T16:15:47.4269538+00:00</LastModifiedDate>
Does anybody know if there is a problem with the use of the DateTimeOffset type in Preview 6 or is it something I am doing wrong? I have had a similar problem with filtering the fields using oData (see SO question)
I have also submitted this bug report to the WCF Web API codeplex site on the filtering issue. However that was over two weeks ago and haven’t had any response.
After many hours of testing and debugging I am running out of options on this one! So if anybody out there can provide me with some helpful hints it would be much appreciated.
It's not a Web API issue, it's Microsoft serialization issue. The XmlSerializer does not handle DateTimeOffset. I believe it has the same issue with TimeSpan.
Just implement IXMLSerializable on your object and handle it yourself.
See here How can I XML Serialize a DateTimeOffset Property?
Related
I'm building a multi-layered Windows VS C# solution that has a WCF Service Library project with EF6.2 loaded, and an ADO.NET Data layer with EF6.2 also.
The EDMX model is built as a 'database first' set of tables from my MSSQL Server Express 2016 server on my laptop. My WCF Service Interface and code
only have properties and methods for one of the tables at this point. And that table has also been built out in logic and data layer methods.
So, I'm testing that service now with the WCF Test Client, and I'm receiving some integer data correctly in my service's response from to the data layer, but no string data.
While testing my "GetMemberByID" method, it returns all String column results as a value of "(null)", and a type of "NullObject",
but returns Integers with their actual value. The WCF Soap response shows the returned String values as "". But,
the integers are returned like this: "7". There are over 50 data rows in my test database which is used as the source
for the EF6.2 EDMX build. My App.config's in data and service layers are referencing the same (localdb)\ V13.0 server and database.
Has anyone had this issue, and can you tell me what I'm missing? The MSSQL database was originally an (OleDb) MS Access database and I imported it into
MSSQL Server. Thanks in advance.
It seems that there is something wrong with the serialization process. On my side, the string field can be returned properly. By default, the DataContractSerializer is used to deserialize/deserialize the complex object data.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/using-data-contracts
The most possible reason might be that the nullable field is not decorated by the [DataMember] attribute. Please check if the column of the DataContract autogenerated on the client-side contains the [DataMember] attribute.
http://sivakrishnakuchi.blogspot.com/2010/05/troubleshoot-wcf-service-returning.html
Feel free to let me know if the problem still exists.
Okay, I found my mistake. When translating the business domain objects back to the Service objects in the Service.cs code file, I was only translating the MemberID and the RowVersion - and no other columns. So, the only thing that was showing up in the WCF Test Client result was the MemberID and the RowVersion - which happen to be the only two non-strings in my entity. All the string types were null because I was not translating them back into the Service. Thanks for taking a look at this, Abraham, but you made me start looking closer, and thanks for the advice. The MS Documentation was helpful, too. Once I did a full "step into" debug trace from the UI through to the Data Layer and back, I was able to see the data translation failure. One more thing, before I could debug step by step all the way to the Data layer and back to the Service layer, I had to fix my "Underlying database did not open" issue that so many have had. I'm hosting my service through my local IIS, and had to make a few changes to the IIS application concerning the user credentials. My App.config is set to use "Integrated Security=True" - which is a "passthrough" credential in the IIS App pools. I had my IIS App set to "Specific User", but was not using a UserID/Password in my Connection String. Once I changed my IIS App to "Passthrough" - I was able to connect, and to debug to the DAL and back.
I am using SOAPUI to call a WCF endpoint with a decimal value. Somewhere the value is getting converted to a zero.
I can call the same service, with the same parameters from a .NET application and the value is not getting altered. I can de-serialise and inspect the values being passed from my .NET app and SoapUI, and both de-serialised versions of the object are identical.
I have been able to capture the request in Fiddler after it has left SoapUI and the decimal value is still in tact so I know it is getting converted down stream somewhere.
This post suggests that this can happen when the proxy is generated:
int properties are 0 when consuming WCF in .Net 2 - but evidence is not pointing to this being a problem in the service, not the client.
Apologies I can't share WSDL nor XML due to corporate privacy restrictions.
The resolution in my case was to change the order of my request parameters.
I was able to determine this by enabling WCF tracing, including message payloads, and then comparing the payloads from my .NET application against the payloads from SoapUI.
The payloads are massively different, but ignoring namespaces, correlation ids, keys and dates I was able to determine that my problematic parameter was in a different position. Changing the order within SoapUI XML request resolved the issue.
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
We're attempting to move to VS 2010 and we've noticed some odd behavior with our WCF services.
In VS 2008, when I add a given WCF service reference, for each object field that's not a reference type, the Object browser shows a fieldNameSpecified bool property. I realize that this exists so that there's a way to determine whether or not the value coming back from the service actually has a value, since DateTime, ints, etc can't be null.
When I try to add the same reference in VS 2010 (set to .Net 3.5), all of these fieldNameSpecified fields are missing. We have code that we wrote in VS 2008 that look at these fieldNameSpecified fields which causes our apps to be broken when attempting to use VS 2010 (because the proxies generated in VS 2010 don't have these fieldNameSpecified fields).
Is there a way to get VS 2010 to put these specified fields back in? Is there some other solution that won't require us to rewrite our code?
Also, what is the proper VS 2010 way of determining whether or not a value type field (int or DateTime) actually has valid data in it coming back from the service?
Any help GREATLY appreciated!
Clarification: The fieldNameSpecified fields are NOT part of the WSDL. VS 2008 apparently adds these into the proxy for you as a convenience...
I ran into an opposite situation recently. There wasn't any xxxspecified field before, but now they showed up. And we have only used VS2008. This acutally cause the value of the optional fields not being passed to the client application, since the xxxspecified fields are default to false.
If you look at both versions of the auto generated reference.cs file under your service reference, you should notice the difference. One uses DataContractSerializer, the other uses XMLSerializer.
When you add the service reference, if you use the URL for the service, e.g. http://localhost/MyService.svc, it would use DataContractSerializer. If you use the URL for the WSDL, e.g. http://localhost/MyService.svc?wsdl, it would use XMLSerializer.
You can use an attribute called EmitDefaultValue to resolve your problem as well. Follow these instructions:
http://bukovics.wordpress.com/2007/03/23/exposing-nullable-fields-to-net-11-web-service-clients/
This also explains why you get a fieldNameSpecified property. It's exactly what you need to fix your problem.
As I understand it, if the data contract requires the properties (for example, if you're using a [DataMember(IsRequired=true)] attribute), the "Specified" fields aren't auto-generated. Unfortunately, making the fields non-required would require a code change, but at least it wouldn't do so on the client.
An alternate way to allow callers to be able to not specify parameters (don't know if it's more VS 2010-ish than the "Specified" fields) is to use Nullable<> types.
I haven't tested it, but perhaps you could remove your Service References and instead put a pre-build step into your projects to run the old version of WSDL.exe to generate the proxies.
Has anyone got a RESTful WCF service (in .NET4) successfully using JSON.NET to do serialization/deserialization?
What's the best approach?
Can you provide a few more details about what you're trying to do with JSON.NET? I'm not exactly sure what scenarios you're trying to deal with -- but I'll give you my general experience with JSON.NET and WCF RESTful services.
I've built a number of WCF RESTful services that are called, primarily, by my client app using jQuery's AJAX functionality. Generally, I have not had to use JSON.NET as the JsonSerializer does a fine job of serializing my return values (single values or List<T> collections) perfectly fine and can navigate through the object without issue.
The times that I've had to use JSON.NET is when I'm sending a JSON object as part of my POST variables that I've serialized on the client using the JSON2.js library. JSON.NET has done a fine job of serializing and deserializing those values without issue, too.
I like JSON.NET -- haven't had any issues. Honestly, when I started out, I thought I would use it a lot, but have found that I only need it for edge cases. Generally I rely on the built-in JSON serialization and deserialization capabilities in WCF.
I hope this helps. Please let me know if you need more info or if there are specific scenarios you're trying to handle, and I'll update my answer accordingly. Thanks!