属性不会得到序列化到了.Designer.cs文件 [英] Properties won't get serialized into the .designer.cs file

问题描述

在VS2010，控件属性不会得到尽管ShouldSerializeFoo方法系列化，与DesignerSerializationVisibility.Visible /内容以及

下面的代码：

 类class1：用户控件{
 [可浏览（真）] 
 [DesignerSerializationVisibility（DesignerSerializationVisibility.Content）
公共字符串美孚{
获得;组; 
} 
公共BOOL ShouldSerializeFoo（）{
返回真; 
} 
公众的Class1（）{
美孚=DUPA; 
} 
} 
  

不过，设计师不会为这种事属性：

  // 
 // class11 
 // 
 this.class11.Location =新System.Drawing.Point（224，262）; 
 this.class11.Name =class11; 
 this.class11.Size =新System.Drawing.Size（150，150）; 
 this.class11.TabIndex = 2; 
 this.class11.Load + =新System.EventHandler（this.class11_Load）; 
  

解决方案

您正在混合系列化方案。设计师序列化（这是 DesignerSerializationVisibility 是）有什么用实例序列化机制做（这是 ShouldSerializeXXX 功能，在许多其他事情，处理）。

DesignerSerializationVisibility.Content 并没有作出多大意义一个字符串（或任何其他不可变型）。设计人员可以查看酒店的序列为三种类型：

• 无 - 它从来没有序列化对房地产

什么
• 可见 - 它会序列化属性的实际值


• 内容 - 它会序列的属性的值的属性值
  

默认情况下，房地产被认为是可见。我意识到我的内容的定义可能是有点混乱。我的意思是这样的：

 公共类MyControl：控制
 {
公共类SomeOptions 
 {
公共字符串选项1 {搞定;组; } 
公共字符串选项2 {搞定;组; } 
} 
 
 [DesignerSerializationVisibility（DesignerSerializationVisibility.Content）
公共SomeOptions选项{搞定;私人集; } 
 
公共字符串美孚{搞定;组; } 
} 
  

现在，当这个类是由设计师序列化，它看起来像这样的：

  // myControl1 
 this.myControl1.Foo =值; 
 this.myControl1.Options.Option1 =选项1; 
 this.myControl1.Options.Option2 =选项2; 
  

这应该有希望更有意义;标志着财产内容意味着，而不是串行化的实际值的属性（在这种情况下的，这将是<$实例C $ C> SomeOptions ），它应该序列化值，而不是属性值。

所以，回到你的问题，这就是为什么你不想内容为字符串属性。因为字符串是一成不变的，没有什么为设计师序列化。无论是将其标记为可见或离开属性完全关闭（因为这是默认值）。

虽然这是可能的提供自定义方向设计师为您是否想序列化一个特定的属性，这是一个非常受累（和肮脏）的过程。在容易的办法，虽然是使用默认值属性的财产。如果是否应序列可以通过其值进行比较，以一个恒定来确定属性（换句话说，它不依赖于在运行时别的，像另一个属性的值），则可以修饰这样的属性：

  [默认值（富）] 
公共字符串美孚{搞定;组; } 
  

如果设计者则认为该值富等于foo的，那么就不会在所有序列化属性。

In VS2010, control properties won't get serialized despite the ShouldSerializeFoo method, with the DesignerSerializationVisibility.Visible/Content as well.

Here's the code:

class Class1 : UserControl {
    [Browsable(true)]
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
    public string Foo {
        get; set;
    }
    public bool ShouldSerializeFoo() {
        return true;
    }
    public Class1() {
        Foo = "dupa";
    }
}

However, the designer doesn't generate anything for this property:

        // 
        // class11
        // 
        this.class11.Location = new System.Drawing.Point(224, 262);
        this.class11.Name = "class11";
        this.class11.Size = new System.Drawing.Size(150, 150);
        this.class11.TabIndex = 2;
        this.class11.Load += new System.EventHandler(this.class11_Load);

解决方案

You're mixing serialization schemes. The designer serialization (which is what DesignerSerializationVisibility is for) has nothing to do with the instance serialization mechanism (which is what ShouldSerializeXXX functions, among many other things, deal with).

DesignerSerializationVisibility.Content doesn't make much sense for a string (or any other immutable type). The designer can view a property's serialization as three types:

• None - it never serializes anything about the property
• Visible - it will serialize the actual value of the property
• Content - it will serialize the property values of the value of the property.

By default, a property is considered Visible. I realize that my definition of Content might be a little confusing. What I mean by that is like this:

public class MyControl : Control
{
    public class SomeOptions
    {
        public string Option1 { get; set; }
        public string Option2 { get; set; }
    }

    [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
    public SomeOptions Options { get; private set; }

    public string Foo { get; set; }
}

Now, when this class is serialized by the designer, it will look something like this:

// myControl1
this.myControl1.Foo = "value";
this.myControl1.Options.Option1 = "option1";
this.myControl1.Options.Option2 = "option2";

This should hopefully make more sense; marking a property as Content signifies that, rather than serializing the actual value of the property (in this case, it would be an instance of SomeOptions), it should serialize the property values of that value instead.

So, back to your question, that's why you don't want Content for a string property. Because strings are immutable, there's nothing for the designer to serialize. Either mark it as Visible or leave the attribute off entirely (since that's the default).

While it's possible to provide custom direction to the designer as to whether or not you want to serialize a particular property, it's a pretty involved (and nasty) process. The easy way, though, is to use the DefaultValue attribute on the property. If whether or not the property should be serialized can be determined by comparing its value to a constant (in other words, it's not dependent upon anything else at runtime, like the value of another property), you can decorate the property like this:

[DefaultValue("foo")]
public string Foo { get; set; }

If the designer then sees that the value of Foo is equal to "foo", then it won't serialize the property at all.

这篇关于属性不会得到序列化到了.Designer.cs文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！