I have an console application for sending mails on Outlook. When I try to run it's .exe by double clicking on it, it runs fine and emails are delivered but when I try to schedule it through Windows Task Scheduler it does not send any mail. In task scheduler it is showing task completed successfully but doesn't send any mail.
I tried various solution suggested on same type of questions but no luck. Please if can anyone suggest anything.
Application app = new Application();
MailItem mailItem = app.CreateItem(OlItemType.olMailItem);
mailItem.Subject = "Test mail";
mailItem.To = "xxx#microsoft.com";
mailItem.Body = "Test body";
mailItem.Send();
Console.WriteLine("mail send.....");
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Read more about that in the Considerations for server-side Automation of Office article.
You may consider as a possible workaround:
Use Exchange web services, see Start using web services in Exchange for more information.
A low-level API on which Outlook is based on - Extended MAPI. Or just any third-party libraries around API such as Redemption.
Related
I am converting an old Silverlight application into Asp.Net Core, using Blazor and Razor Pages.
The old application is opening Outlook, and creating an email ready to send with a Subject, From etc, plus a series of attachments. It is creating an object to do this using the following code:
Dynamic outlook = AutomationFactory.GetObject(“Outlook.Application”).
In my web-site, I do something similar:
Use a COM reference to the Microsoft Outlook 16.0 object library.
If Outlook is already running, then get a reference to its associated “Outlook.Application” COM object as per https://renenyffenegger.ch/notes/Microsoft/dot-net/namespaces-classes/System/Runtime/InteropServices/Marshal/GetActiveObject.
Otherwise, create an object using Microsoft.Office.Interop.Outlook.Application appOutlook = new Microsoft.Office.Interop.Outlook.Application();
This works when running my web-site locally in Visual Studio, however I cannot deploy it to Azure:
C:\Program Files\dotnet\sdk\6.0.201\Microsoft.Common.CurrentVersion.targets(2926,5): Error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild. See https://aka.ms/msbuild/MSB4803 for further details.
I’m assuming that I won’t be able to use this approach, however I can’t see any alternative. Any suggestions as to how I can do this in an ASP.Net Core Blazor web-site would be greatly appreciated.
You cannot use Outlook, or any other Office app, in a service (such as IIS). Even if you do manage to make it run, it won't help you - your code is running on the server, and the message you populate and display will be on the server, where nobody would ever see it.
You can either use a mailto: link (it supports address, subject, and body) or (if you need HTML and/or attachments), dynamically create an EML (MIME) file - Outlook on the client side will be happy to open it. To make sure the message is editable, add X-Unsent: 1 MIME header.
In my web-site, I do something similar:
Use a COM reference to the Microsoft Outlook 16.0 object library.
The Considerations for server-side Automation of Office states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
From a JS code you can automate Outlook from Internet Explorer (only on Windows). Other browsers don't know anything about the COM technology. So, I'd suggest considering other approaches for getting the work done. The easiest way, like Dmitry suggested, is to use the mailto protocol. It opens a client's e-mail system and begins a new email message. The following example shows a link that will prepare an e-mail message:
<a href="mailto:user#example.com?
subject=MessageTitle&
body=Message Content">
Contact Us</a>
You may consider using EWS or Graph API if you need to send email silently.
Error message:Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
I have tried changing the DCOM config settings required but still I am getting it,If I debug my code the mail gets sent.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using a low-level API on which Outlook is built on - Extended MAPI. Or just any other third-party wrapper around that API such as Redemption.
Okay so I have a application that runs every hour through windows scheduler. It runs successfully, and I can tell that by windows scheduler. When I click on the executable the application runs with no issue.
When I run the same application through windows scheduler it does not work as expected.
It closes outlook as it should, but it doesn't reopen it.
Rather it starts the executable but the Outlook application doesn't show up on my desktop.
My application should do this: Close my email, send emails, open outlook.
I need to close Outlook in the first place because if I don't close it before I try to send emails it will try to access the data-file, and since I have my email up on my desktop before hand windows scheduler can't open the data-file.
static void Main(string[] args)
{
foreach(Process proc in Process.GetProcesses())
{
if(proc.ProcessName.Equals("OUTLOOK"))
{
proc.Kill();
}
}
//Removed code which sends emails.
openOutlook();
}
private static void openOutlook()
{
Thread.Sleep(1000);
Process.Start(#"C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.exe");
}
Automating Outlook from a windows scheduler (service) is not a good idea.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using a low-level API - Extended MAPI. Or any third-party wrapper around that API such as Redemption.
The best solution that I came up with was to close outlook before emails were being sent.
If a process of Outlook is open then kill all instances; proceed with sending emails as needed. Open Outlook manually after the program has finished.
A possible alternative is to create some VBA that attaches emails at a certain time. You could also look into the other links that were provided on this page.
Scheduler is a service that runs in a local user context different from the currently logged user. Outlook will be opened in that user context and the currently logged in user will not see it.
I have made one web site for configuring time slot for particular date. For example I stored Email id of user, date, Stating time of lecture, Ending time of lecture in database.
I want to display pop up on desktop before 5 minute of starting time.
Suppose I connect my database with outlook calendar.
How can I connect with outlook?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
If you deal with Exchange profiles only consider using EWS, see EWS Managed API, EWS, and web services in Exchange for more information. Or just use the System.Net namespace classes for accessing your mailbox.
I wrote some code about sending mail, Task, Appoinment etc. For example you can add someone to your outlook contact list over asp.net page. Every thing is ok on my local machine. But if I publish my application to a server I can not add noone on my outlook. Please help me it is important.
This is generally not a good idea, as Microsoft themselves state:
Microsoft does not currently
recommend, and does not support,
Automation of Microsoft Office
applications from any unattended,
non-interactive client application or
component (including ASP, ASP.NET,
DCOM, and NT Services), because Office
may exhibit unstable behavior and/or
deadlock when Office is run in this
environment.
Read the article to find out which obstacles await you.
I think you need to create an outlook/mapi profile on the server for the user that is sending the email. nOte that since you're runnning on ASP.NET then the user sending the email will be the identity of the Application pool that the virtual directory of the web application is running in.
This is an old article about creating a profile with outlook installed.