Silverlight的设计时间大会
介绍
如果你写的Silverlight控件，你应该考虑两个简单的原因，也写您的控件的设计时组件：
- 开发人员的生产力：尝试想象没有Silverlight的开发工具如Visual Studio或混合！ 对于自定义控件，您可能需要提供您的控件的设计时体验多在Visual Studio或混合自己。
- 设计师：XAML和工具，如混合，使开发人员和设计人员一起工作。 Silverlight控件的一个关键设计标准，以确保设计人员可以使用他们不写一行代码。
设计时体验通常包括（但不限于）以下内容：
- 元数据的属性窗口，如类别，信息提示，自定义属性/绑定/集合编辑器等。
- 元数据设计的表面，如初始化，装饰器，上下文菜单，适配器等。
- 工具箱的整合，如图标，控件注册
- 代码编辑器的IntelliSense
除的intellisense（请参阅你的Silverlight控件添加丰富的Intellisense ）和控制登记（请参阅注册Silverlight控件与Visual Studio和Blend ），以上的设计时间的经验通常是通过设计时间组件交付。 下面我将讨论各种方法，提供设计时的经验，在日益复杂性和灵活性，并逐步引入件设计时组件的命名约定。
仅运行大会
提供设计时体验最简单的方法是打包成运行时组件设计时的代码，尤其是在设计时元数据在运行时是有意义的太像， TypeConverterAttribute 。
这种方法的优点和缺点：
- 临：简单
- 没有单独的设计时组件，安装简单
- 设计时属性直接指定上运行的代码，更易于维护
- 缺点：紧耦合的运行时和设计时代码
- PERF的退化，因为无用的设计时代码在运行时
- 得到拖入运行不必要的设计时间依赖性（像MWDs和其他VS /混合组件）
- 不能独立服务运行时或设计时
- 不能支持多个设计师（既像VS2008/Blend2和VS2010/Blend3的）
缺点是Silverlight的特别不好，因为设计时间组件实际上是到Silverlight类型的引用，。NET程序集。 混合Silverlight和。NET组件可以挑战和混乱，并可能导致微妙的错误。 此外，Silverlight应用程序大多是Web应用程序，所以下载的尺寸和性能尤为重要。 拖动NET程序集在Silverlight应用程序肯定没有帮助。 因此，这种做法是非常气馁，除非有充分的理由。
共享设计时大会
如此革命性的一步是分离设计时和运行时代码，发布和服务，与单独的组件。 这开辟了各种可能性。 当然，我们需要一种方式，其相应的运行时组件，而不引入任何不必要的依赖或PERF退化的运行时组件，连接设计时组件。 因此命名约定，如果运行装配Foo.dll的Silverlight项目中引用，设计师 （如Visual Studio和Blend） 将首先尝试加载一样的图标设计时间信息 （通过另一个命名约定，请参阅如何添加一个工具箱图标为您的Silverlight控制 ）和设计时元数据（通过接口，像IRegisterMetadata为VS2008和Blend2，VS2010的和Blend3 IProvideAttributeTable请参阅如何编写Silverlight的所有设计师设计时间：Visual Studio 2008中，Blend 2中; Blend 3中，和Visual Studio 2010中 ）的运行时组件，它就会寻找由名称Foo.Design.dll的设计时，在相同的目录作为Foo.dll的大会，如果发现，设计师将尝试加载富设计时间信息。Design.dll以及。
设计师具体设计时间大会
Visual Studio是主要用于开发，而混合大多是设计师，所以他们有不同的要求设计时体验。 把所有设计时代码在一个共享的设计时间大会介绍了紧设计师之间的耦合。 这样的命名约定是增强： 运行组装Foo.dll，那里是一个共享的设计时间的装配Foo.Design.dll这是所有设计师加载每个设计师也将自己设计的一次集会，试图像Foo.VisualStudio加载。为Visual Studio和混合Foo.Expression.Design.dll design.dll。 设计师具体设计时间大会后装入共享的设计时间大会。第三方设计师可以定义自己的设计师具体设计时间组装。 Silverlight工具包2008年12月推出使用此命名约定。 更多信息，请参阅Silverlight工具包设计的时代特点和Silverlight工具包的设计时功能的实现 。
设计子文件夹
因此，支持Visual Studio和Blend中，每个运行时装配有三个设计时组件，在同一目录中，像Silverlight SDK或Silverlight工具包 ）包（通常包含几个运行时组件。 因此，目录变得有点拥挤。 一个小规模的改善，是把一个设计子文件夹下的设计时组件。 这样的命名约定是进一步加强： 如果一个设计师（如Visual Studio或混合），不能在同一目录中找到相应的设计时组件，它作为一个运行时组件会寻找他们在设计的子文件夹，如果它的存在。
支持多MWDs版本
设计时，都建立在顶级设计师的可扩展性的框架 ，其中包括几个dll文件像Microsoft.Windows.Design.Extensibility.dll和Microsoft.Windows.Design.Interaction.dll。 我们通常称他们为统称为MWDs。 让生活更有趣，有时候我们必须引入打破的可扩展性框架的变化，如随钻测量的版本3.5，VS2010和Blend3使用的随钻测量4.0版本的VS2008和Blend2使用，它们是不相容的。 所以如果你有一个运行的的装配Foo.dll，和你想你的用户能够对发展与VS2008和VS2010的，你必须提供两套设计时组件：内置对V3.5 MWDs的和使用的一组VS2008中，与另一组对V4.0内置MWD和VS2010中使用。 两套设计时组件可能有很多共同的代码，同时为VS2010的一个可能有一些新的代码，利用VS2010中暴露的新功能。 由于设计时程序集加载的名字，你不能有两个相同名称的文件，所以再次增强的命名约定：
为运行装配Foo.dll，共享的设计时间大会名为Foo.Design * DLL，Visual Studio的具体设计时间大会名为Foo.VisualStudio.Design *。dll文件，并具体设计时组件混合名为Foo 。Expression.Design DLL。*，其中*可以是零个或多个文件名 的有效字符。 当设计师（如Visual Studio或混合）试图加载设计组装和几个合适的命名约定，零个或一个将被载入：
- 如果装配设计时所引用的MWD版本有不同的比设计师的MWD版本的主要版本号码，然后装配设计时将不加载，并绕过。
- 如果一个以上的设计时组件是与设计师的MWD版本兼容，设计加载的MWD对最高版本是小于或等于设计师的MWD版本编译的。
Silverlight 3的工具包2009年10月推出使用此命名约定，同时支持VS2008和Blend3/VS2010。 请参阅Silverlight的设计时工具包2009年10月推出更新 ， 如何编写Silverlight的所有设计师的设计时间：Visual Studio 2008中，Blend 2中; Blend 3中，和Visual Studio 2010 ， 可扩展性系列- WPF和Silverlight的设计时代码共享-部分，我更多的信息。
同时支持WPF和Silverlight
生活进一步复杂化，因为WPF和Silverlight是非常类似的，你可能会尝试编写一次，WPF和Silverlight运行。 你并不孤单。 有许多文章对如何共享源代码和/或跨Silverlight和WPF双星。 我们想要做的，设计时组件，即具有相同的WPF和Silverlight控件的设计时组件。 一种方法是使大部分设计时间组件平台无关，与特定于平台的限制（WPF或Silverlight）的代码和一个小平台特定的程序集的引用。 的Silverlight 3 SDK东德2 （安装VS2010的自动过）使用这种方法为DataGrid设计师（SDK目录中有一个System.Windows.Controls.Data.VisualStudio.Design.4.0.Silverlight.dll）。 扩展系列- WPF和Silverlight的设计时代码共享-第一部分的详细信息，请参阅。
最后一胜
一类或它的成员同样的设计时间元数据可以指定多个设计时组件，它允许共享的设计时间大会指定默认的/共同的行为，然后设计师具体设计时组件来覆盖它，如果必要多次。 相同的设计时元数据也可以被指定在一个单一的设计时间组件（请参阅多次在Silverlight工具包的设计时功能的实现作为一个例子，其中一类或者其财产DescriptionAttribute可以，由AddDescriptions，AddAttributes和AddTables方法添加） 。 因此，我们需要知道哪些元数据获胜。 最简单，最逻辑的设计，是最后一个胜利 。 这主要是真实的，但并非总是如此。 有时结果可能是相同的设计时元数据时指定了几次，但与不同的价值观的非确定性。
反馈
设计时听起来很容易，但魔鬼在细节！ 反馈总是赞赏。 请让我知道你遇到什么问题，什么样的请求/你想设计时间经验和设计师的可扩展性框架，使改善。 谢谢！
最新评论