Prev: Reading excel file giving 2 sheets
Next: Consuming web service receiving/returning objects
From: Raj on 8 Jan 2010 23:42
I shall make appropriate changes as per your suggestions

Thanks indeed for your time and patience

Regards
Raj

"Family Tree Mike" wrote:

>
>
> "Raj" wrote:
>
> > 1. The object has public properties
> > 2. I am not using WCF
> > 3. I am not using XML serialization using only binary serialization
> >
>
>
> I'm pretty sure that nothing shown below changes your service from xml to
> binary serialization.
>
>
> > This is the object sent/returned:
> >
> > namespace WebServiceData
> > {
> > [Serializable]
> > public class Result
> > {
> > private string data;
> >
> > public Result()
> > {
> > }
> >
> > public Result(string data)
> > {
> > this.data = data;
> > }
> >
> > public string Reader
> > {
> > get{return data;}
> > }
> >
> > public string Writer
> > {
> > set{data=value;}
> > }
>
> When your object is serialized and deserialized, Reader has no _set_ method
> and Writer has no _get_ method. They will not serialize, to the best of my
> knowledge, and therefor the private field data will never be restored.
>
> > }
> > }
> >
>
> Mike
From: Raj on 8 Jan 2010 23:43
I shall make appropriate changes as per your suggestions

Thanks indeed for your time and patience

Regards
Raj


"Jeroen Mostert" wrote:

> On 2010-01-08 10:01, Raj wrote:
> > 1. The object has public properties
> > 2. I am not using WCF
> > 3. I am not using XML serialization using only binary serialization
> >
> You cannot use binary serialization in a web service. A web service always
> uses XML serialization. The attributes do not choose the mechanism used;
> they only provide information to whatever mechanism serializes. If what
> you're doing is not compatible with XML serialization, it won't work.
>
> > This is the object sent/returned:
> >
> > namespace WebServiceData
> > {
> > [Serializable]
> > public class Result
> > {
> > private string data;
> >
> > public Result()
> > {
> > }
> >
> > public Result(string data)
> > {
> > this.data = data;
> > }
> >
> > public string Reader
> > {
> > get{return data;}
> > }
> >
> From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
> not convert methods, indexers, private fields, or read-only properties
> (except read-only collections)."
>
> > public string Writer
> > {
> > set{data=value;}
> > }
>
> And that note should also include write-only properties, but it doesn't,
> because write-only properties are a bad idea to begin with. See
> http://msdn.microsoft.com/library/ms182165.
>
> --
> J.
> .
>
From: Raj on 8 Jan 2010 23:47
Could you please let me know, How do I XMLSerialize the object which needs to
be sent and return?

Thank you

Regards
Raj

"Family Tree Mike" wrote:

>
>
> "Raj" wrote:
>
> > 1. The object has public properties
> > 2. I am not using WCF
> > 3. I am not using XML serialization using only binary serialization
> >
>
>
> I'm pretty sure that nothing shown below changes your service from xml to
> binary serialization.
>
>
> > This is the object sent/returned:
> >
> > namespace WebServiceData
> > {
> > [Serializable]
> > public class Result
> > {
> > private string data;
> >
> > public Result()
> > {
> > }
> >
> > public Result(string data)
> > {
> > this.data = data;
> > }
> >
> > public string Reader
> > {
> > get{return data;}
> > }
> >
> > public string Writer
> > {
> > set{data=value;}
> > }
>
> When your object is serialized and deserialized, Reader has no _set_ method
> and Writer has no _get_ method. They will not serialize, to the best of my
> knowledge, and therefor the private field data will never be restored.
>
> > }
> > }
> >
>
> Mike
From: Raj on 8 Jan 2010 23:48
Could you please let me know, How do I XMLSerialize the object which needs to
be sent and return?

Thank you

Regards
Raj

"Jeroen Mostert" wrote:

> On 2010-01-08 10:01, Raj wrote:
> > 1. The object has public properties
> > 2. I am not using WCF
> > 3. I am not using XML serialization using only binary serialization
> >
> You cannot use binary serialization in a web service. A web service always
> uses XML serialization. The attributes do not choose the mechanism used;
> they only provide information to whatever mechanism serializes. If what
> you're doing is not compatible with XML serialization, it won't work.
>
> > This is the object sent/returned:
> >
> > namespace WebServiceData
> > {
> > [Serializable]
> > public class Result
> > {
> > private string data;
> >
> > public Result()
> > {
> > }
> >
> > public Result(string data)
> > {
> > this.data = data;
> > }
> >
> > public string Reader
> > {
> > get{return data;}
> > }
> >
> From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
> not convert methods, indexers, private fields, or read-only properties
> (except read-only collections)."
>
> > public string Writer
> > {
> > set{data=value;}
> > }
>
> And that note should also include write-only properties, but it doesn't,
> because write-only properties are a bad idea to begin with. See
> http://msdn.microsoft.com/library/ms182165.
>
> --
> J.
> .
>
From: Peter Duniho on 9 Jan 2010 00:05
Jeroen Mostert wrote:
> [...]
> And that note should also include write-only properties, but it doesn't,
> because write-only properties are a bad idea to begin with. See
> http://msdn.microsoft.com/library/ms182165.

I would not go so far as the code analysis rule given. Just as one
common use for read-only properties are when they are synthetic and it
doesn't make sense to write the value, so too can it sometimes make
sense to have a synthetic write-only property, where it doesn't make
sense to read the value (because it's setting some state that doesn't
actually correspond to one single thing, or even some stable combination
of things).

I would certainly agree that it's something to use carefully and only
when it clearly makes sense. The situations when a write-only property
is good design are very rare.

In the class being shown here, I think the read-only _and_ write-only
property is just plain absurd. The whole point of a property is to have
a single class member that encapsulates a value, and when that value can
be both read and written, to split that value between two different
properties seems ridiculous to me.

I suspect that the OP will have much more success with the serialization
if the class is changed so that it just looks like this:

[Serializable]
public class Result
{
private string data;

public Result()
{
}

public Result(string data)
{
this.data = data;
}

public string Data
{
get{return data;}
set{data=value;}
}
}

Of course, there still remains the question why the OP has a whole class
just to wrap a string value. Why doesn't he just serialize the string
value instead of messing around with the class?

But having a simple read/write property should make serialization go a
lot better, I would think.

Pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Reading excel file giving 2 sheets
Next: Consuming web service receiving/returning objects