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.
Related
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.
I've received requirements to upgrade a legacy Outlook addin, which requires an active logged on user, to a standalone microservice (implemented using NServiceBus).
The goal of the addin is to monitor incoming emails (by communicating with the Exchange) that match certain pre-set criteria and do stuff with it.
Is VSTO sufficiently robust to run inside a Windows Service?
Is it sufficiently threadsafe?
Could it lock up the mailbox, making it unreachable via human interaction?
Could VSTO make the service crash?
Even worse, could VSTO cause the Exchange to lock / crash?
If any of these concerns are real, are there alternatives?
I would say that it not advisable to run VSTO within a windows service. Writing something in VSTO is useful for its UI components, presenting something to the user, interacting with the user, and would mean you would need to start an instance of Outlook for your add-in to load. Installing Office on the server is typically frowned upon, create problems when used in a multi-threaded way, and create problems most developers are unprepared to handle.
There are also other avenues you might want to explore, so instead of using the Outlook library directly you can use Exchange Web Services (EWS) via the EWS Managed API, or if you are not on-prem, go with the REST or Graph API.
I have a weird problem, i have an silverlight application which uses Interop to execute a piece of code .
My Production server has a complex login procedure and the password never stays the same for a user after a stipulated time. i.e the password keeps changing.
So when i run this application , until any user is logged in the application works well, as soon as the person logs out or the session expires , the interop stops working as it doesn't have an interactive user.
I have read in several posts of this issue and majority like this asks to configure identity in the DCOMCNFG settings. But i am unable to find any microsoft office component (powerpoint,onenote,word,excel...) in my DCOMCNFG but in my local i am able to find it. Also the Interop is not found. The error is referring to this CLSID {00024500-0000-0000-C000-000000000046} .
How can i solve this issues. Is there any problem with the Office installation so as the file should appear in my DCOMCNFG ?
even if it does appear is there a ray of hope through which i can solve the identity problem ? as the password of my production server keeps changing so even if i go to the dcom component and go to identities tab in the properties , will i be able to give "this user" a fixed name and password ? or should i use the launching or interactive user ?
any help would be appreciated.
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.
You can read more about that in the Considerations for server-side Automation of Office article.
I'm trying to write an asp.net (using c#) app that accesses my Outlook mailbox and display the messages. I searched on google but couldn't find useful info, any help is appreciated?
You must be aware of the fact that outlook is running on user local machine, and your ASP.NET application is running on some server and there is no way that your server side ASP.NET code can use Outlook local data.
AFAIK only way to do something like that would be creating outlook addin that will export all mails to ASP.NET application
If you are using Exchange then you can use Exchange Web Services to read emails.
Please see here
Be very careful that you do not attempt to access Outlook on the server side by using the Automation interfaces. All of the Microsoft Office desktop applications are written to be run by an interactive user in a process with a message pump, with all synchronization happening via the UI. When you run them in a multi-threaded environment like ASP.NET, horrible things will happen. If you're lucky, the application will simply crash.
If you're not lucky, you can suffer from data corruption, random crashes in unrelated code, and all the other things that happen when an application corrupts memory.
You may also violate your license if the people accessing the Office application through your web site are not individually licensed to use the application on their desktop.
You can't connect to Outlook via C# (ASP.NET), but you can connect to your mailserver via POP3/IMAP to read the mail.
IMAP Client library using C#
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.