MAPI, UAC & .NET

Question

I've used MAPI to create emails with attachments from my application and it works very well on XP and Vista (without UAC). Of course, if you have UAC enabled, it just doesn't work (though it gives no errors, and doesn't prompt the user for permission to continue).

I've done a bunch of reading and have found a lot of differing ideas:

• Require Admin privileges for the app
• Require some form of elevated privileges for the app
• Create a COM object for the small portions of code that require elevation
• Get the OS to prompt the users asking them if they want to continue.

I'm wondering what SO Users would do given that I really only need elevation for one or two functions. I'm looking for the minimal amount of pain here (I don't do COM, but I can P/Invoke with the best of them...), and I'm working in .NET 2.0 (it's a legacy app).

EDIT: I agree that elevating the whole app isn't a great idea given that only part of it needs the eleveation, but my thought had been that might be easier in the long run than trying to elevate only part of it.

Also, I'd rather stay away from the .NET SMTP solution, since my goal is simply to create a message and with an attachment, but display it to the user so that they can add more text and send it at their leisure...

Answer 1

If you can give up MAPI in favor of the more general SMTP, you can use .NET's System.Net.Mail.SmtpClient class. Together with the MailMessage class, you can add attachments and send messages via any willing SMTP server.

All available in good old .NET 2.0 as managed code - no need for p/invoke or COM. Examples in the referenced pages.

Answer 2

I'm afraid I don't know anything about the specifics of UAC and MAPI, but I would strongly suggest that you don't elevate the whole application just so that it can occasionally send email.

The elevated COM object or helper process sounds like the right approach if MAPI really doesn't work as a non-admin. You'll automatically get the prompt from the OS as a side-effect of using one of these mechanisms.