2009年|张宁的博客

存档

2009年档案

Silverlight的设计时间大会

2009年11月30日没有评论

简介

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

开发人员的生产力：尝试想象没有Silverlight的开发工具如Visual Studio或混合！自定义控件，您可能需要提供您的控件在Visual Studio的设计时体验或混合自己。
设计师：XAML和工具，如混合，使开发人员和设计人员一起工作。 Silverlight控件的一个关键设计标准是不写一行代码，确保设计师可以使用它们。

设计时体验通常包括（但不限于）以下：

元数据属性窗口，如类，信息提示，自定义属性/绑定/收集编辑等。
元数据设计图面，喜欢的初始化，装饰器，上下文菜单，适配器等。
工具箱的整合，如图标，控件注册
代码编辑器的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.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工具包的设计时功能的实现，更多信息。

设计子文件夹

因此，同时支持Visual Studio和Blend中，每个运行时组装三个设计时程序集，在同一目录中，和一个包（像Silverlight SDK或Silverlight工具包）通常包含几个运行时组件。因此，目录变得有点拥挤。一个小规模的改善，是把一个设计子文件夹下的设计时组件。所以命名约定是进一步增强： 如果一个设计师（如Visual Studio或混合）无法找到相应的设计时间组件，在相同的目录中，运行时大会将寻找他们在设计子文件夹，如果它存在。

支持多个版本的MWDs

设计时，都是建立在顶级设计师的可扩展性的框架，其中包括几个DLL的Microsoft.Windows.Design.Extensibility.dll和Microsoft.Windows.Design.Interaction.dll。我们通常所说的，统称为MWDs。为了让生活更有趣，有时候我们必须引入的可扩展性框架的变化，打破像MWD的版本3.5，VS2010的Blend3使用MWD的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中，混合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方法添加）。因此，我们需要知道哪些元数据获胜。最简单，最逻辑的设计是最后一胜。这主要是真实的，但并不总是的。有时结果可以被联合国确定的相同的设计时元数据时指定了几次，但使用不同的值。