delphi - servidor - ¿Cuál es la mejor prueba futura de mi aplicación que necesita conectarse a Outlook?
outlook 2016 no puede conectar con el servidor de correo saliente(smtp) (2)
Tengo una aplicación de administración de contactos escrita en Delphi que tiene una función "Sincronizar con Outlook" que desarrollé hace 10 años. Ahora, voy a volver a agregar algunas características y corregir algunos errores. Esta función de sincronización utiliza el modelo de objetos de Outlook para comenzar, pero tiene un modo opcional llamado "Usar mejoras de MAPI" donde usa MAPI puro para acelerar la forma en que busca cambios, y permite que las notas se sincronicen con RTF en lugar de solo texto simple
Me pregunto si es una buena idea o no apoyar dos caminos paralelos de ejecución.
Si fuera compatible con MAPI, creo que evitaría algunas indicaciones de seguridad y evitaría situaciones en las que el antivirus tenga funciones de bloqueo de secuencias de comandos que impidan que mi aplicación se conecte a Outlook. Pero creo que, en el lado negativo, mi aplicación de 32 bits no podría conectarse con Outlook 2010 de 64 bits utilizando MAPI. Y me pregunto sobre el futuro de MAPI en general.
Si me apego al modelo de objetos de Outlook, ¿podrá mi aplicación de 32 bits conectarse al modelo de objetos de Outlook (ya que está fuera de proceso COM)? De ser así, esta es una razón convincente para mantener en funcionamiento mi ruta de ejecución del modelo de objetos de Outlook. Pero si no, y si mi aplicación necesita ser compilada para x64, entonces ¿por qué no simplemente usar MAPI pura?
Confirmé mediante pruebas que: 1. Una aplicación de 32 bits puede conectarse a Outlook 2010 x64 a través de la automatización COM. 2. Una aplicación de 32 bits no se puede conectar a Outlook 2010 x64 a través de MAPI puro.
Por lo tanto, parece que es mejor mantener mi código de automatización COM de Outlook en su lugar para admitir Outlook 2010 x64, y mi código MAPI solo se puede usar en x86 Outlook.
Pero noté que en Outlook 2007, se agregó el objeto "PropertyAccessor" que le permitirá leer las propiedades de MAPI sin recurrir a MAPI. Esto podría darme los beneficios de leer / escribir notas RTF ... que es la principal característica que falta si no puedo usar MAPI.
Eso es correcto, necesitará compilar su código ya sea en 32 bits o 64 dependiendo de la bitness de Outlook.
En cuanto al futuro de MAPI, todavía está allí y cuenta con el apoyo activo de MS. Outlook 2010 sigue siendo MAPI puro.