We recently finished development of a VSTO Outlook add-in. For some configuration data, it uses custom olText properties on a [Folder](https://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.folder.aspx).

When our add-in detects that these properties are not available, it uses the UserDefinedProperties property of the Folder to [Find/Add](https://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.userdefinedproperties_methods.aspx) our custom properties if they don't exist.

```
if (folder.UserDefinedProperties.Find(propertyName) == null)
    folder.UserDefinedProperties.Add(propertyName, OlUserPropertyType.olText);

```

While our add-in is running, we get and set these properties many times. We use the [PropertyAccessor](https://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.propertyaccessor.aspx) GetProperty and SetProperty methods to do that. Again, all of our properties are type OlUserPropertyType.olText. In addition, we always dispatch to Outlook's UI thread when we get and set the properties.

```
//set
string value = "blah";
folder.PropertyAccessor.SetProperty(GetSchemaName(propertyName), value);

// get
string value = folder.PropertyAccessor.GetProperty(GetSchemaName(propertyName)

```

GetSchemaName returns ("<http://schemas.microsoft.com/mapi/string/>" + assemblyGuid + "/" + propertyName).

However, our usage of GetProperty and SetProperty on the PropertyAccessor of the Folder results in frequent runtime COMExceptions. Here is an example exception for a call to GetProperty. We have seen this issue in both Outlook 2010 and 2013.

```
System.Runtime.InteropServices.COMException (0x80020005): Type mismatch.
(Exception from HRESULT: 0x80020005 (DISP_E_TYPEMISMATCH))
at Microsoft.Office.Interop.Outlook._PropertyAccessor.GetProperty(String SchemaName)

```

My question is this: Is there a known issue with using the Folder PropertyAccessor to get and set properties in VSTO? If not, why is this happening?