只要有人谈到开发者与设计师在 Silverlight/WPF上协同工作时，他们就会谈论“设计，开发工作流程”这个
问题。即使您是您自己的设计师，这工作也始终是永远存在于当你在“设计师”和“开发”之间切换“帽子”的过程中。
我是一个使用工具创建用户界面的支持者。 我的生活让我不能理解为什么有人会选择非产能(non-productive)
和手写XAML的事情。
你能找出的一个情况就是当你使用(Expression Blend & Visual Studio WPF/Silverlight Designer)这类工
具进行工作时，如果使用正确，这些工具会对提高生产力起到巨大的推动作用。然而，这篇帖子不是关于如何使用
这类工具，而是关于如何帮助那些使用您的控件作为工具进行设计的人。本文是关于开发者着手去让设计师有更容
易的(设计)体验并减少摩擦。
控件提供商和开发者通常都想给自己的控件以更好的体验。然而，在这个问题上其缺乏大量的信息。我决定用
本文纠正这种情况。
本文也与那些在项目中有设计师一起工作的开发者有关。
介绍：
首先，我们会考虑在设计时的Assemblies工作。
考虑下面这个类:
public class myControl : Control
{
public string MyStringProperty { get; set; }
}
现在，考虑下面这个设计时属性的类：
[Description("I am a control")]
public class myControl : Control
{
[Description("I am a property")]
public string MyStringProperty { get; set; }
}
在设计时assemblies 工作的方式就是将设计时属性与实际的类进行分离。之后我们的类会是这个样子：
public class myControl : Control
{
public string MyStringProperty { get; set; }
}
并且在我们的设计时组装过程时，代码相当于：
AddCallback(typeof(myControl), builder =>
builder.AddCustomAttributes(new DescriptionAttribute("I am a control 2")));
AddCallback(typeof(myControl), builder =>
builder.AddCustomAttributes("MyStringProperty", new DescriptionAttribute("I am a property")));
在没有研究太多API的情况下，可以看到第一行会显示“myControl has the following DescriptionAttribute”，
第二行显示：“myControl.MyStringProperty has this DescriptionAttribute”.
我们从运行时代码中分离出设计时代码. 下面让我们看一下在BLEND中，它的样子:
这一做法有哪些优势？
2.基于工具修改设计时属性。这种做法允许支持不同的设计时属性，而这些属性基于它们运行的工具。
3.设计时变更无须重新编译运行时组件。
4.不是运行时组装的author可以添加设计时属性。
5.高级的设计时支持，并不需要我们使用GUIDs注册Visual Studio软件包。
参考架构
这里有一些步骤. 从本质上讲，我们要建立以下结构：
一点都不乱，是吧？简单地说，这仅仅是参考模型。
我们将创建3个新项目。
*. VisualStudio.design.dll -将包含设计时的功能，仅用于Visual Studio。
*. Expression.design.dll -将包含设计时的功能，仅用于Expression blend。
这种命名约定是强制性的。
