dotnet
Windows 11 Email cannot identify the default mail app.
Description
This code, running in .Net 7 (have yet to try in .Net 8) always produces the error message I supply after it:
if (!CanSendEmail) return false;
EmailMessage mail = new EmailMessage
{
Subject = email.Subject,
Body = email.Message,
BodyFormat = EmailBodyFormat.PlainText,
To = email.Recipients,
Bcc = email.RecipientsBcc,
Cc = email.RecipientsCc,
};
foreach (KcEmailAttachment attachment in email.Attachments)
{
mail.Attachments.Add(new EmailAttachment(attachment.FilePath, attachment.ContentType));
}
await Email.Default.ComposeAsync(mail);
Error produced: "There is no email program associated to perform the requested action. Please install an email program or, if one is already installed, create an association in the Default Programs control panel."
Steps to Reproduce
- In Windows 11, create a .Net Maui application utilizing .Net Maui Email.
- Clear any associations in Registry | HKLM | Software | Clients | Mail.
- Be sure a default email client is associated with MAILTO and .eml in Settings | Default Apps.
- Restart Operating System and recheck that steps 2 and 3 are unchanged.
- Attempt to send an email via Essentials | Email's implementation within the application .
Expected : Default email client opens and sends the email. What did happen: .Net Maui Email says it cannot identify the default mail client. Happens whether in Settings I've set that default to Microsoft Mail or to a Browser that knows what site to open for email processing.
Link to public reproduction project repository
No response
Version with bug
7.0.101
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
Windows 11 (10.0.2261)
Did you find any workaround?
Until fixed, I use Share instead of Email. THAT does supply a choice of some email clients, but all the recipients also have to be re-entered.
Relevant log output
No response
If you use any other application that implements a "mail to" command, does it bring up the e-mail dialog with those defaults?
https://github.com/dotnet/maui/blob/main/src/Essentials/src/Email/EmailHelper.uwp.cs#L12
The underlying essentials API is a wrapper around Win32 DLLs. There could be an issue with how that's implemented, but it could be worth seeing if any other app that can call up that dialog would also be affected by what you're seeing. It may not be MAUI related.
Hi @DavidPressman. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
I do have an older WPF version (already in Microsoft Store) (and even older Xamarin version) of the same app. While it does not use the same dlls to send email, I can try to experiment a bit to see if I can call them. However, when you say "dialog" are you referring to the error message or to something else? David Pressman
I do have an older WPF version (already in Microsoft Store) (and even older Xamarin version) of the same app. While it does not use the same dlls to send email, I can try to experiment a bit to see if I can call them. However, when you say "dialog" are you referring to the error message or to something else? David Pressman
Yeah, you should get the same error message outside of using the Essentials Library. The Essentials code is invoking Win32 DLLs through PInvokes, so it's calling into Windows to generate those dialog prompts, that's not from MAUI. So my guess is that if you bring up the generic Windows dialog for sending emails, you would get that error dialog as well.
Not saying there couldn't be an implementation problem with how it's invoked in Essentials, but it's trying to nail down "is it Windows or is it MAUI"
CC @mattleibow
e. Also to note, it's doing this now because the previous implementation using EmailManager only applied for UWP apps, and not general WinUI desktop ones and the WinUI side hasn't ported it over, so MAUI had to change so it would work at all. That's also why it would work with a Xamarin.Forms UWP app, since it's using EmailManager and is totally different from this implementation. Your WPF app could be doing the same.
Hi @DavidPressman. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
Have verified this is an issue on both current Windows 10 and 11. Used the Platform Integration Demo in the .Net Maui Samples and got the exact same error message on both my physical Windows 11 and on a Windows 10 Virtual Machine. Considering that Microsoft has scheduled to this year replace Windows Mail with "Outlook for Windows", which seems to have no ability even to receive .eml files, the situation seems likely to worsen.
That's not what I asked. I do believe you that you're seeing that error, but what I'm trying to understand is "is it from MAUI" or "Is it from Windows", so running the same code from MAUI Essentials doesn't help. Lucky for us, another people already wrote a project implementing MAPI (https://github.com/castorix/WinUI3_SendMail/tree/master) that's using WinUI 3 directly, without MAUI.
If you run the MAPI commands from that program, I think you would see the same results. On my machine, if I had the built in Windows Mail client loaded as the default, it would throw the "Could not find default client" message. Where if I had the Office Outlook client or Thunderbird installed and set as default, it would work. I think the root issue here is two:
- The default Windows Mail/"new" Outlook client doesn't support MAPI.
- MAUI Essentials in net7.0+ uses the MAPI Windows library to wrap its service.
The actual code works fine, but only if you have a supported client installed. Thunderbird works, Windows Mail doesn't, but that's due to the client, not the underlying MAUI implementation or the MAPI32.dll. So, IMO, that's something that would need to be revisited as to what Windows API gets wrapped for email. As a "bug" though, I don't think there is one.
CC @mattleibow @Redth.
Thank you for your insights, which may well enable me to provide my Windows app users a decent workaround. Also, I was not previously aware that, like AOL app users, Google app users can utilize an app-related password, but that is what is shown in the referenced Win UI SendMail markdown. I will be looking into it. Google has always been my greatest concern over its OAuth needs and severe PlayStore restrictions for apps with internal emailing. My app actually uses Rebex SecureMail whenever possible for internal emailing and downloading (greatly simplifying retrieval by other of a user's devices), but when it comes to sites requiring OAuth token use, I would first have to program means of receiving initial authentication. I am trying to give any such users alternate means of using their own mailto client until I can provide site-specific authentication. From all we've seen regrettably Windows Mail is not such a client, as I had expected it would have been, as it is registered in my Windows as its mailto default app, and I was testing against it. Yesterday I spent much of the day trying to fulfill your info request and once thought I had found a workaround, which I posted but later retracted. All I proved is Mail will receive .eml files but refuse to do anything with them, even after adding a header that may have worked for some in the past. Oddly I also found that Firefox, for one, though set to hand off mailto it receives and having been set in Windows as the mailto default, also did not do anything with them in my testing. Odd. Your reasoning seems sound and I wonder if a warning about Windows Mail as ineligible for EmailMessenger use could be added into Maui's Email documentation?