How do you exclude a property from serialization using CodeDomSerializer

[tribbles]

You can use NonSerialized to exclude a field (not a property) from the
serializer. If you are using the XmlSerializer you can use
XmlIgnore. However, I can't find any way to exclude a property from
the CodeDomSerializer. The problem I am trying to solve is that I
have Controls that have references to other controls. I have used the
[NonSerialized] on several property to exclude the Control objects
from serialization and a bool property that indicates whether those
control references have been re-established after deserialization.

The control properties have a value of null that I want, but the bool
property has a value of true, when it should have a value of false.

So with a little debugging I noticed that without NonSerialized, the
serialization and deserialization would record and set public and
private fields in addition to public and private properties. Field
were first, followed by properties.
Not having the NonSerialized set on the Control fields caused an
seriliazation exception as expected. With, properites no exception
occurs, but no value is serialized.

So it appears to be by pure change that the Control properties are
working as I intended. The boolean property on the other hand is
always serialized out, one way or the other. :(

All of these properties are part of an interface and you can not use
fields in interfaces, unless I'm missign something obvious and
wonderously useful...

So... Any ideas on how to exclude properties from serialization,
besides coding my own serilization service and using the
XmlSerializer? (Previous dev team attempted to use XmlSerializer and
said it didn't work, I have no real info on what didn't work though).

For additional context, serialization is used for cut/copy/paste/undo/
redo services.


[NonSerialized]
private bool controlsNormalized = false;
public bool ControlsNormalized {
get { return controlsNormalized; }
set { controlsNormalized = value; }
}

//
// Don't serialize out, only used during design time.
//
[NonSerialized]
private Control baseControl = null;
public Control BaseControl {
get { return baseControl; }
set { baseControl = value; }
}
//
// This property is used with the auto Parser to serialize out
the control and to
// deserialize the needed information to 'relink' to the
control in the designer.
// Since there is no gaurantee that the control will have been
deserialized and added
// to the designer before valdiation is deserialized, we need
a 2 step process.
//
private string baseControlName = "";
public string BaseControlName {
get {
if (BaseControl == null) {
return "";
}

return BaseControl.Name;
}
set { baseControlName = value; }
}

[Mick Doherty]

Have you tried adding ShouldSerializePropertyName methods?

private bool controlsNormalized = false;
public bool ControlsNormalized
{
get { return controlsNormalized; }
set { controlsNormalized = value; }
}
private bool ShouldSerializeControlsNormalized()
{ return false; }

private Control baseControl = null;
public Control BaseControl
{
get { return baseControl; }
set { baseControl = value; }
}
private bool ShouldSerializeBaseControl()
{ return false; }

[schneider]

Also the attribute:

[DesignerSerializationVisibility( DesignerSerializationVisibility.Hidden)]





"Mick Doherty"

Post by Mick Doherty
Have you tried adding ShouldSerializePropertyName methods?
private bool controlsNormalized = false;
public bool ControlsNormalized
{
get { return controlsNormalized; }
set { controlsNormalized = value; }
}
private bool ShouldSerializeControlsNormalized()
{ return false; }
private Control baseControl = null;
public Control BaseControl
{
get { return baseControl; }
set { baseControl = value; }
}
private bool ShouldSerializeBaseControl()
{ return false; }
--
Mick Doherty
http://dotnetrix.co.uk/nothing.html

[tribbles]

Wow! I spent a day going over various documentation and did not see
anything about either method mentioned. I tried the method and it
solved the problem nicely. Thanks!

[schneider]

Yep, A lot of these little things come with experience building controls.

You might want to review the Attribute derived objects, there are a lot of
designer related items.

Schneider

Post by tribbles
Wow! I spent a day going over various documentation and did not see
anything about either method mentioned. I tried the method and it
solved the problem nicely. Thanks!

[jokiz]

or just read the designer related sample chapter of chris sell's book,
a lot stuff is in there
On May 11, 4:20 am, "schneider"

Post by schneider
Yep, A lot of these little things come with experience building controls.
You might want to review the Attribute derived objects, there are a lot of
designer related items.
Schneider

Post by tribbles
Wow! I spent a day going over various documentation and did not see
anything about either method mentioned. I tried the method and it
solved the problem nicely. Thanks!

[tribbles]

Post by jokiz
or just read the designer related sample chapter of chris sell's book,
a lot stuff is in there

<snip>

Are you referring to this book: Windows Forms 2.0 Programming (2nd
Edition) ?

Always willing to buy a book that has good info in it. Unfortunately
I have 4 books on windows forms that have nothing about designers in
them. So any books with designer is of interest to me!

[jokiz]

yes, it has one chapter for design time integration. i've also read a
book from bluevision but it's just a good reference but hard to
understand.

Post by tribbles

Post by jokiz
or just read the designer related sample chapter of chris sell's book,
a lot stuff is in there

<snip>
Are you referring to this book: Windows Forms 2.0 Programming (2nd
Edition) ?
Always willing to buy a book that has good info in it. Unfortunately
I have 4 books on windows forms that have nothing about designers in
them. So any books with designer is of interest to me!