I have a WCF Service (.NET4.0). Client is in .NET2.0. Enum values passed by the client into the service are always set with enum default value (which is the first enum member).
Is this an issue in .NET2.0 ? Are there any workarounds ?
The <FieldName>Specified is a feature used by the XmlSerializer. I've been stung by this before. It seams everyone finds out about this feature in a similiarly painful manner.
As you say, if this is set to false then your field won't be serialised. Unfortunatly false is the default for a boolean field so it can very annoying if you forget to set it.
If you do not appreciate this feature then you should be able to just delete the <FieldName>Specified field without consequence. Then the field will always be serialized.
These fields only make a difference because you are using the XmlSerializer in .NET 2. In your .NET 4 WCF app you are using the DataContractSerializer which does not possess this feature.
The default value of the enum is not really received by WCF. Really nothing is received on the server for that enum. Consequently the enum is not set, so it remains the default value.
Related
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 have a WCF service method that takes a complex parameter, which in turn has complex properties. The problem is that this parameter once it arrives at the server contains null for some of the properties.
I have checked using WCF tracing and Fiddler and the data is definitely going over the wire. Seems to be when the XML is deserialized into .net objects something goes wrong and some properties get set to null.
I've tried rebuilding the proxy in case some mismatch there.
EDIT: OK all fixed now. The data objects were POCO's generated from the EF T4 template and which have a separate field for the foreign key id's. I was forgetting to set this on the client, as soon as I did I started to get the complex properties returned on the server. Not exactly sure why though.
Have you used DataMember on these properties? and if the type is class, you should use DataContract on these types too.
Actually, when you use WCF tracing, you can see the xml.
Using WCF3.5SP1, VS2008. Building a WCF service that exposes about 10 service methods. We have defined about 40 [DataContract] types that are used by the service.
We now experience that adding an additional [DataContract] type to the project (in the same namespace as the other existing types) does not get properly exposed. The new type is not in the XSD schemas generated with the WSDL.
We have gone so far as to copy and rename an existing (and working) type, but it too is not present in the generated WSDL/XSD.
We've tried this on two different developer machines, same problem.
Is there a limit to the number of types that can exposed as [DataContract] for a Service? per Namespace?
No, there's no hard limit on the number of Data Contracts - mostly certainly not as low as 40 or 50!
What I'm guessing might be the problem is this: you can add as many DataContracts as you like - but unless they're actually being used (as an input parameter or return type of a service method), they won't be serialized into the WSDL/XSD.
What happens if you add another dummy service method which takes one of your newly added types, and returns an arbitrary INT value or something. Does it show up in the WSDL/XSD then??
If I have an object that holds the parameters for my method. I need to change the Object to have an additional property. I have full control over the server, but not over all of the clients. Will this change make those clients break?
I am using a self-hosted service with a binary endpoint.
I am new to WCF so my apologies if this is a silly question.
I guess you are asking about a class that represents your DataContract.
Learn about DataContract versioning and how various changes in your DataContract affect the compatibility in MSDN
In short the answer is No, it will not break the client code. The serialized graph of the data contract will deserialize to the available data members matching by their names and assigned through the property setter method. Obviously in this case, your newly added data member will not have value. Since you have full control on the server side code, you just have to make sure this newly added member need to be dealt in such a way that it is meaningful in the new implementation and allow for default/unassigned value.
I have two .NET 3.5 WCF services build with VS2008.
I have two WCF clients in Silverlight to consume these services. The clients are generated with the 'Add Service Reference'. I am using Silverlight 4.
ONE of the proxies is generated with Specified properties for each property. This is a 'message-in' class for my service method :
// properties are generated for each of these fields
private long customerProfileIdField;
private bool customerProfileIdFieldSpecified;
private bool testEnvField;
private bool testEnvFieldSpecified;
Now my other service (still with a Silverlight client) does NOT generate Specified properties.
Now I don't care about 'tenets of good SOA'. I just want to get rid of these damn properties because in the context of what I'm doing I absolutely hate them.
There has to be some difference between the two services - but I don't want to have to completely rip them apart to find out the difference.
A similar question before had the answer 'you cant do it' - which is definitely not true because I have it - I just don't know what I did differently.
Edit: I am now in a situation where I regenerate my Silverlight 4 proxy to my 3.5 WCF service (all on the same localhost machine) that sometimes I get 'Specified' properties and sometimes I don't. I no longer think (as I suspected originally) that this is due solely to some endpoint configuration or service level [attribute]. Theres certain triggers in the message itself that cause Specified to be generated (or not). There may be many factors involved or it may be something very simple.
try this in your WCF service where the property is declared
[DataMember(IsRequired=true)]
public bool testEnvField { get; set; }
IsRequired=true will negate the need for the testEnvFieldSpecified property
These extra Specified properties are generated for value types which are being specified as optional in either the contract or the attribute markup.
As value types have a value by default, the extra Specified flags are being added for these properties, to allow the client (and server) to distinguish between something explicitly not specified or explicitly specified - which may well be set to the default value. Without it, integers would always end up being 0 (and being serialized) even if you don't set them (because of the mapping to int) in your client code. So when you do, you need to also make sure that you set the Specified flag to true, otherwise these properties will not get serialized.
So to prevent these flags being generated for value types, you would have to change the contract to make these value type properties mandatory, instead of optional.
Hope that makes sense.
OK I've found one thing so far that will cause Specified properties to be generated:
The presence of an XTypedElement in the message.
These are used by Linq2XSD. I was returning an element from a Linq2XSD model.
This triggered Specified properties to be generated EVERYTHING in all my classes :
public XTypedElement Foo { get; set; }
This however didn't :
public XElement Foo { get; set; }
Still curious as to why this is, and if there are any other things that trigger this.
NOTE: I realize this is an old question. I'm adding this here because this question comes up as a top result on Google, and it's helpful information for whoever comes looking.
Try adding this line into your operation contract declaration:
[XmlSerializerFormat]
It should look something like this:
namespace WebServiceContract
{
[ServiceContract(Namespace = "http://namespace")]
[XmlSerializerFormat] //This line here will cause it to serialize the "optional" parameters correctly, and not generate the extra
interface InterfaceName
{
/*...Your web service stuff here...*/
}
}
I found that if I put a DataTable in a service DataContract then the generated client will use xml serializer and thus generate the *IsSpecified members.