混纺|张宁的博客

存档

帖子标记'配方'

Silverlight的设计时组件

2009年11月30日没有评论

介绍

如果你写的Silverlight控件，你应该考虑用你的控件设计时组件也为两个简单的原因：

开发人员的生产率：尽量想象没有像Visual Studio或混合Silverlight开发工具！对于自定义控制，您可能需要为您提供the控件在Visual Studio或混合自己的设计时间experience much。
设计师：XAML和工具，如配方使开发人员和设计人员一起工作。 Silverlight控件的一个关键的设计准则是要确保设计人员可以使用，而无需编写一行代码他们。

设计时的经验，通常包括（但不限于）以下内容：

元数据属性窗口，如类，infotip，自定义属性/绑定/收集编辑等
元数据设计的表面，如初始化，adorner，上下文菜单，适配器等
工具箱集成喜欢的图标，控制登记
编辑器的代码的intellisense

除智能感知（请参阅新增的Silverlight控件为您丰富的Intellisense ）和控制登记（请参阅Studio和Silverlight的控件与交融注册视觉）的经验，最重要的设计时间通常是通过设计组件交付时间。下面，我将讨论设计时的经验提供各种办法，在日益复杂和灵活性，并逐步介绍了设计时程序集命名约定件。

运行时，只有大会

最简单的方式提供设计时的经验，是包也喜欢设计时间码到运行时组件，特别是当设计时元数据是有意义的运行时间TypeConverterAttribute 。

在这种方法的优点和缺点：

专业版：简单
- 没有单独的设计时组件，安装简单
- 设计时属性直接指定在运行时代码，易于维护
缺点：运行时和设计时间紧耦合的代码
- PERF的下降，因为无用的设计时代码在运行时
- 设计时间依赖关系（如MWDs和其他比/混合组件）进入运行时不必要地拖累
- 不能服务时间独立运行或设计
- 不能支持都喜欢VS2008/Blend2和VS2010/Blend3多个设计师（）

犯人们都特别为Silverlight坏的，因为设计时组件实际上是。NET程序集，并以Silverlight的类型引用。混合Silverlight和。NET程序集可以是具有挑战性和混乱，并可能导致微妙的错误。此外，Silverlight应用程序大多是网络应用软件，因此下载的尺寸和性能尤为重要。拖动英寸NET程序集在Silverlight应用程序肯定没有帮助。因此，这种做法是非常沮丧，除非有充分的理由为它。

共享设计时大会

因此，革命的进步是解耦设计时和运行时的代码，发布和服务，他们分别集会。这开辟了各种可能性。当然，我们需要一种方法来设计时组件连接到其相应的运行时组件，不引入任何不必要的依赖PERF的退化或运行时组件。因此，命名约定： 如果一个运行时组装Foo.dll是一个Silverlight项目中引用，在与交融设计师 （如Visual Studio中） 将首先尝试加载图标另一个命名（通过公约信息，如设计时 ，看到如何添加工具箱图标为您的Silverlight的控制）和设计时间元数据（通过接口，比如IRegisterMetadata为VS2008的和Blend2，或Blend3 IProvideAttributeTable为VS2010和。请参阅如何撰写Silverlight的设计时间为所有设计师：Visual Studio 2008中，混合2，配方3，和Visual Studio 2010 ） 从运行库程序集，它会寻找一个名称Foo.dll设计时间由Foo.Design.dll装配在同一目录中，如果发现，设计师将尝试加载信息从Foo设计时间。Design.dll以及。

具体设计时设计师大会

Visual Studio是主要用于开发，而配方是主要设计者，所以他们有时间体验不同的设计要求。放在一个共享的设计时间大会介绍了所有的设计中设计师的时间代码紧耦合。因此，命名约定是加强：运行时组装Foo.dll，有一个共同的设计时间大会Foo.Design.dll这是所有设计师加载，每个设计师也将尝试加载自己的设计时组件Foo.VisualStudio，等等。 Design.dll为Visual Studio和混合Foo.Expression.Design.dll的。 设计者设计时的具体程序集加载时间后，共享的设计组装。第三方设计人员可以定义自己的设计师具体设计时程序集。 Silverlight的工具包2008年12月发布正在使用此命名约定。请参阅在Silverlight设计工具包的时代特点和实现在Silverlight Toolkit的设计时功能的更多信息。

设计子文件夹

因此，为了支持Visual Studio和配方，每个运行时装配有三个组件的设计时间，在相同的目录，以及SDK或包（像Silverlight Silverlight的工具包）通常包含几个运行时组件。因此，目录变得有些拥挤。一个小规模的改善是将子文件夹下一个设计组件的设计时间。因此，命名约定是进一步加强： 如果一个或混合设计（如Visual Studio中）一又找不到相应的design same运行库程序集的目录中的程序集时，它会寻找他们在设计子文件夹，如果它存在。

支持多个版本的MWDs

设计时都建立在顶级设计师的可扩展性的框架，其中包括Microsoft.Windows.Design.Extensibility.dll Microsoft.Windows.Design.Interaction.dll和几个dll文件等。我们通常称他们统称为MWDs。为了让生活更有趣，有时候我们要介绍的可扩展性的框架打破变化和Blend2像VS2008的使用，随钻版本3.5，VS2010和Blend3使用随钻4.0版，它们是不相容的。因此，如果你有一个运行时组装Foo.dll，您希望您的用户能够反对发展同VS2008的和VS2010，你必须提供两套设计时程序集：一组对v3.5版本MWDs使用和建设由VS2008的，以及对4.0版又建了一套MWD和由VS2010使用。设计时组件的两套可能有一个共同点很多代码，而对VS2010有可能有一些新的代码由VS2010利用公开的新功能。由于设计时加载的程序集的名字，你不能有两个同名的文件，因此命名约定是再次提高：

对于一个运行时组装Foo.dll，共享的设计时间组装*. dll文件名为Foo.Design，在Visual Studio中的具体设计时程序集名为Foo.VisualStudio.Design *. dll文件，并具体设计时的混合组装名为富。Expression.Design *. dll文件，其中*可以是零或多个文件名的有效字符。 当一个或混合设计（如Visual Studio中）试图加载一个程序集设计时间和几个适合的命名约定，零或一个将被载入：

如果随钻版本所引用的程序集设计时有一个设计师的分子量分布不同版本的主版本号比，那么设计时将不加载程序集，并绕过。
如果有一个以上的设计时程序集的版本兼容设计师的随钻测量，随钻的设计荷载版本的反编译一个版本的最高分子量分布小于或等于设计师。

2009年10月3 Silverlight的工具包发布使用这个命名约定，以支持VS2008的和Blend3/VS2010。请参阅Silverlight的设计时间：2009年10月发布工具包的更新，如何撰写Silverlight的所有设计师设计时间为：Visual Studio 2008中，混合2，配方3，和Visual Studio 2010 ，并扩展系列-与Silverlight的WPF的设计时代码共享-第一部分更多的信息。

同时支持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）。请参阅可扩展系列-与Silverlight的WPF的设计时代码共享-第一部分以获取更多信息。

最后一台WINS

同样设计为一类或它的成员时元数据可以指定在多个设计时组件，它允许共享的设计时间大会指定默认/设计师共同的行为，然后具体设计时组件，如果需要重写多次。同样的设计时元数据也可以指定时间内多次组装一个设计（请参阅在Silverlight工具包实现设计时间特征为例，在DescriptionAttribute一类或者其财产可以AddDescriptions添加，AddAttributes和AddTables方法）。因此，我们需要知道哪些元数据获胜。最简单，最逻辑的设计是最后一胜 。这主要是真实的，但并非总是如此。有时结果可能是联合国确定的，当这样的设计时元数据指定若干倍，但不同的价值观。