classe Microsoft.Office.Interop.Outlook.Recipient: setter de propriétés AddressEntry.Name et AddressEntry.Address n'a aucun effet

Question

En utilisant msvs 2008/.net 3.5/Outlook 2007 J'ai rencontré le problème suivant:
en essayant de créer et ajouter un nouveau bénéficiaire à une instance MailItem existante:

using Microsoft.Office.Interop.Outlook; 
Recipient rcp = mail.Recipients.Add("foo@bar.com"); 
if (rcp.Resolve()) 
{ 
    rcp.AddressEntry.Name = "Foo"; 
} 

aucune erreur de compilation ou d'avertissement survenu, sans exception est levée, mais après la cession de la propriété « Nom », sa valeur reste la même ('foo @ bar. com '). Ne devrait-il pas être "foo"? (cette propriété est largement documentée en tant que 'lire/écrire')

Est-ce que quelqu'un a une quelconque indication sur la raison de ceci?
Plus généralement (je suis nouveau sur .net): est-ce une caractéristique commune de C# que les setters peuvent échouer silencieusement?
Merci pour tout conseil!

Autre solution:
Cette syntaxe:

Recipient rcp = mail.Recipients.Add("Foo foo@bar.com") 

instancie un objet Recipient où:

rcp.AddressEntry.Name == "Foo" 
rcp.AddressEntry.Address == "foo@bar.com" 

Answer 1

Pour votre question perspectives Alors que vous avez raison que la propriété Name sur AddressEntry est en lecture/écriture , il spécifie qu'il ne doit pas être modifié après résolu, et peut être défini in order to lookup. Je ne serais pas surpris s'il y a des gardes dans le setter. Vous pouvez également reference this thread qui décrit le même problème et a une réponse avec plus d'informations indiquant Changement du Recipient.Name, ou pour créer un nouveau AddressEntry et l'assigner.

Pour votre C# question de la propriété Dans .net (COM et ainsi - Interop perspectives se fait par COM), une propriété est vraiment une méthode avec une syntaxe différente.

Normalement en C#, vous le feriez define a property comme tel:

private string _name; 
public string Name 
{ 
    get{ return _name;} 
    set{ _name = value;} 
} 

Si le AddressEntry.Name a été défini comme celui-ci, alors oui, vous pouvez vous attendre à obtenir « Foo » retour juste après que vous définissez.

Mais rien ne l'empêche d'être déclaré:

private string _name; 
public string Name 
{ 
    get{ return _name;} 
    set 
    { 
     if(ValidateName(value)) 
     { 
     _name = value; 
     } 
    } 
} 

Notez que dans ce cas, le champ de support (_name) n'est pas réglé à moins que la méthode ValidateName renvoie true. Donc, si vous définissez la propriété name et qu'elle n'est pas valide, demander la valeur de la propriété name n'affichera pas vos mises à jour. Donc je ne dirais pas qu'ils "échouent" en silence - la pratique normale serait d'exposer le problème de façon documentée (IDataErrorInfo, une exception, etc) - mais plus qu'un ensemble de propriétés n'est pas du tout comme définir un valeur de la variable. Au lieu de cela, c'est comme si vous appeliez une méthode supposée pour définir une valeur.