I was hoping someone could point me in the right direction as far as how to run background task in Outlook 2007 while preserving a good User experience. I have a process that loops through each item in a default Outlook calendar and sends information (subject, location, etc.) to a back-end server. I have tried ThreadPool.QueueUserWorkItem and creating a Thread and setting it isBackground to true, but the User experience of normal operation in Outlook while this task is running seems to be compromised. Ideally I would like for this background task to run and not have Outlook seem sluggish. Any thoughts on how I could achieve this?
Thanks
Running background threads in out are not recomended, it can be done but it depends on what you are actualy doing in your code, The OOM is run in a single threaded apartment COM server, so every COM call is executed on the main thread of outlook.exe
From you description the best bet would be to process the items not using the OOM.
If you are running Exchange (dependant on the version) you can use EWS or ExchangeDav.
Otherwise MAPI.
Marcus
Related
well this has been bugging me for a couple of days on and off. I am at a clients site where they have a number of bespoke, written in house, services running on a Windows 2008R2 IIS server. The problem is that a couple of these services keep hanging, they are stuck in a “Stopping” state and the only way to kill them off is to open process explorer and kill the threads. Before anyone says anything about using ‘runas’, or logging on as the local admin, or the service owner, etc we’ve been through all of that.
The problem lies with the executable itselfs. The development team, in another country are going to look at this but it will take 4-5 months minimum, and we’re not certain they’ll get it right then.
I have a Powershell script to check the services on a regular basis which has the ability to ensure the services are running and if not, the force a stop and restart of the service, then it sends an email to confirm the actions. However with these specific services mentioned it can do nothing. They can’t be killed in task manager, taskkill, or process explorer (unless one kills the threads) it just says access denied. It is possible to change the permissions in process explorer and kill it but that’s a lengthier process than killing the threads.
To make things a little more difficult I can’t use the process name as on this server there are two other websites using an exe with the same name, just in a different folder.
What I’m after is a way to find and kill the threads of a processID, which I’ve already obtained via the script I have, so the rest of the script can complete the task of restarting the said service. At the moment this service dies on an inconsistent basis throughout the day and night, and the support guys have to RDP onto the server, open process explorer, find the offending process and kill the threads off then restart the services. A bit too much hassle for these already over worked guys especially if we can get powershell to do it automatically.
Hope someone can help on this. Thanks in advance.
Low level thread handling is likely to require native Win32 API usage. Powershell might help with P/Invoke, but the process is going to be complex. For starters, find out if the following tools can be used to identify the stuck thread. Maybe you can combine this info with some Sysinternals tools like handle.exe to find out what really blocks the thread.
The .Net framework has some tools available via System.Diagnostics.Process namespace. A list for threads for named process is available like so,
$ps = [diagnostics.process]::getProcessesByName("iexplore")
$p = $ps[0]
$p.Threads[0]
Full documentation is in MSDN. There is no method for killing a thread, but this should be kind of starting point for identifying the stuck one.
Another a way is to use WMI to get win32_thread data like so,
$threads = gwmi win32_thread
The output is quite different and some filtering is needed. Some examples are available. Another a WMI solution attempt might be based on Win32_process that has Terminate method.
I'm having the problem that my Outlook add-in is not running in the processes main thread. This applies at least to some callbacks, maybe more, I'm still investigating. It's a big problem since several important API functions only work from the main thread.
This happens only at a customer's computer (Win8 + Outlook2013 64-Bit), but not on my computer with the same Windows/Outlook version.
I've never seen this before.
Any ideas what might trigger this?
Any hidden setting in Office, any third-party security tools?
Any build settings that I can use to prevent it?
Outlook always runs COM add-ins on the main thread.
What exactly makes you think that you are running on a secondary thread? How exactly does the problem manifest itself?
I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010.
The result is a windows forms based DLL using .Net 4 Client Profile.
Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.
But the the (synchronous) method I need to call can take a minute or longer to get back.
I know your answer:
Use a worker thread...
I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.
But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.
Why? Is it because Excel is always running as STA (Single Thread
Apartment)?
How can I keep the Excel GUI responding?
Is there a way to make it really asynchronous?
Thanks for any answers,
Jörg
Finally, I've found an answer to this topic:
I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.
Together we changed the threading model of the COM-DLL:
OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)
Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.
Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.
Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).
I'm currently working on a solution that has two projects, a console and a form application. The console application is the main entry point to my application, and from the console the user would run the form application.
The problem is, when the user boots the form application the rest of the business logic (from the console app) won't run until the form is closed. My first thought was to use a background worker for the form, but the business logic in the form project already uses a background worker (and I only have two CPUs...). Perhaps this could be my ignorance for multithreading, but is there a way to do this?
Any thoughts are much appreciated!
Cheers
Well, this is pretty unusual. In general, it doesn't make a lot of sense to provide the user with a nice GUI and still leave a console window up and interactive.
But yes, calling Application.Run() or Form.ShowDialog() is going to block the thread. It has to, the message loop needs to be running to keep the GUI alive. If you do this, be sure to put the [STAThread] attribute on the Main() method.
The only other decent alternative is to start a thread. This isn't a problem, a UI thread doesn't burn any CPU cycles. Code only ever runs when the user does something, it's otherwise idle 99% of the time. Be sure to call the thread's SetApartmentState() method before you start it, STA is required.
I'm looking hard at WF 4.0 right now, but I'm having a hard time figuring out how to run workflows in STA threads. I've got a requirement for constructing XPS documents in a workflow, which means I need to create UI elements (FixedPage), which means the thread running the workflow has to be STA.
In 3.0, you could do some magic (I didn't manage this part of the code, so no details here) with the ManualWorkflowSchedulerService to get the workflow running in a STA thread. But now 4.0 is much different; even beta 2 is different from beta 1...
Anybody know how to get 4.0 workflows running in STA threads?
I can't use the WorkflowInvoker because it is only for short-lived workflows that don't require persistence, which I do.
Have you tried using the WorkflowInvoker? This should just execute the workflow on the original thread and not schedule work on a background tread.