class Microsoft.Office.Interop.Outlook.Recipient : setter of properties AddressEntry.Name and AddressEntry.Address has no effect

Using msvs 2008/开发者_开发知识库.net 3.5/Outlook 2007 I ran into the following problem :

while trying to create and add a new Recipient to an existing MailItem instance :

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

No compilation error or warning occured, no exception is thrown, but after assignment of property 'Name', its value remains the same ('foo@bar.com'). Shouldn't it be "foo" ? (this property is extensively documented as 'read/write')

Does anyone has any indication on the reason for this ?

More generally (I am new to .net) : is it a common C# 'feature' that setters may silently fail ?

Thanks for any advice!

Alternate solution :

This syntax :

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

instanciates a Recipient object where :

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

For your outlook question While you are correct that the Name property on AddressEntry is read/write, it does specify that it should not be modified after resolved, and can be set in order to lookup. I would not be surprised if it has some guards in the setter. You can also reference this thread which describes the same problem and has a response with some more information stating to Change the Recipient.Name, or to create a new AddressEntry and assign it.

For your C# property question In .net (and COM as well - outlook interop is done through COM), a property is really a method with different syntax.

Normally in c#, you would define a property like such:

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

If the AddressEntry.Name was defined like this, then yes, you would expect to get "Foo" back right after you set it.

But nothing prevents it from being declared:

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

Note that in this case, the backing field (_name) is not set unless the ValidateName method returns true. So if you set the name property and it wasn't valid, asking for the value of the name property would not show your updates.

So I wouldn't say they silently "fail" - normal practice would be to expose the problem in some documented way (IDataErrorInfo, an exception, etc) - but more that a property set is not at all like setting a variable's value. Instead, it's like calling a method that is assumed to set a value.