我应该在构造 ExtendedPropertyDefinition 时使用 GUID 还是 DefaultExtendedPropertySet.PublicStrings？答案

【问题标题】：Should I use GUID or DefaultExtendedPropertySet.PublicStrings while constructing ExtendedPropertyDefinition?我应该在构造 ExtendedPropertyDefinition 时使用 GUID 还是 DefaultExtendedPropertySet.PublicStrings？
【发布时间】：2014-08-11 17:54:13
【问题描述】：

我正在使用 EWS Managed API 1.2 和 Exchange Server 2007 开发 C# .NET Framework 4.5 Windows Form 应用程序，它执行某种邮件同步。

现在我正在处理扩展属性，我想澄清一些事情：

Q1.DefaultExtendedPropertySet类的目的是什么？ MSDN says “定义默认的扩展属性集。”

是否只是对扩展属性进行分组？
如果是，为什么首先要进行分组？
我们是否有任何 Ews API 方法可以获取属于某个项目的同一组的所有扩展属性的值？

Q2.在构建ExtendedPropertyDefinition 时，我无法决定是否应该使用自定义GUID 或DefaultExtendedPropertySet.PublicStrings：

var MyXProp = new ExtendedPropertyDefinition(
             DefaultExtendedPropertySet.PublicStrings, 
            "MyXProp", MapiPropertyType.String);

或

Guid MyPropertySetId = new Guid("{C11FF724-AA03-4555-9952-FA248A11C3E}");            
var extendedPropertyDefinition = new ExtendedPropertyDefinition(
             MyPropertySetId, "MyXProp", MapiPropertyType.String);

决定上述决定的因素有哪些？
上述两种方法又有什么区别？

【问题讨论】：

标签： c# .net exchange-server exchangewebservices

【解决方案1】：

我自己的问题的即时答案如下。但是在阅读之后，我意识到还有更多相关的事情需要了解。所以这些事情就跟着答案了。

第一季度。

是的，DefaultExtendedPropertySet 用于分组目的。 Microsoft 预定义了一些命名空间以鼓励对命名属性进行逻辑分组并将它们包含在此枚举中。
分组是为了方便，同时也是为了避免不同供应商引入的不同属性名称之间的冲突。
没有 API 可以获取属于同一组的所有属性的值。

第二季度。

GUID 创建一个新组，从而在组级别和名称级别提供两个级别的分隔，但是，具有非通用名称的DefaultExtendedPropertySet.PublicStrings 也足够了。重点是避免与其他供应商创建的命名属性发生冲突。如果应用程序要与其他一些应用程序集成，PublicStrings 还可以提供更好的可发现性（在集成期间可能需要非常仔细地指定 GUID）。

MAPI 属性

Microsoft 使用消息传递 API (MAPI) 作为连接不同消息传输组件的方法。 MAPI 规范将大多数对象表示为由属性标识符或 PropID 标识的属性。
属性标识符是一组十六进制值，范围从 1 到 0xFFFF（总共 65536）。
从历史上看，为了方便起见，这些属性被划分为逻辑组。
标准 MAPI 属性或固定属性 - 0x8000 下方的属性。该范围细分为：
- 可传输 - 此范围由 Exchange 可以随消息一起发送的属性组成。
- 内部 - 此范围由只能由 Exchange 设置的属性组成。
- 不可传输 - 此范围表示 Exchange 传递消息时未在组织外部传递的属性
命名属性 - 0x8000 以上的属性。它们允许供应商/开发人员通过添加自己的属性来扩展标准 MAPI 属性集。命名属性有两种风格：
- 带有数字名称的属性 - 由 MS Outlook 等程序使用；这些属性名称通常在源文件中定义。
- 具有字符串名称的属性 - 这些属性具有与其关联的 GUID 以及名称，因此允许开发人员将命名属性划分为属性集。每个 GUID 代表一个属性集，因此具有相同 GUID 的所有命名属性都与它们属于同一个属性集。

rfc822 x-headers 到 MAPI 属性的转换

在 Internet 上发送的消息以 message/rfc822 格式发送，该格式支持称为 x-headers 的一组属性。
从 rfc822 x-headers 键值对到 MAPI 属性的转换是由一个名为 Imail 的组件完成的。
因此，如果入站邮件具有 x-header，Imail 将为它创建命名属性并将其存储在邮件中。

有一些微妙的历史细节如

Imail 在 Exchange 2000 中被重新编写，以包含 Ad-hoc 标头，而后者又包含 x-headers。
由于 MAPI 属性的数量 (65536) 有限制，因此在 Exchange 服务器上为它们分配了配额
由于不同的设计决策，从版本到版本的 Exchange 服务器发生了以下变化：
- MAPI 属性将在特定邮件或整个邮箱数据库中进行维护
- 为 MAPI 属性保留 GUID 和名称的规则

在以下链接中阅读更多详细信息：

【讨论】：

在DefaultExtendedPropertySet.PublicStrings 以外的任何内容上设置的扩展属性仅在项目创建者的邮箱中可见。例如。如果在约会上使用 GUID 设置扩展属性，则在从其他收件人（或房间）邮箱读取约会时，扩展属性将不可用。只有从组织者邮箱读取约会时，扩展属性才可用。

【解决方案2】：

Q1) DefaultExtendedPropertySet 枚举定义了 Exchange 具有的默认扩展属性 sets，例如 DefaultExtendedPropertySet.Task。它不适用于您自己的自定义扩展属性集。

Q2)MSDN 非常明确地表示将 Guid 用于任何自定义扩展属性集，所以我确实会这样做。在该属性集中，您当然可以为您的属性使用任何名称。

【讨论】：