I must run a Computer Aided Engineering (CAE) application as a service but it doesn’t work with AlwaysUp. I guess that Visio is the problem because the startup phase of the tool runs up to the Visio initialization (via COM) and then hangs. When I try to register Visio standalone, it’s also not working.
Any idea what I can do to isolate the problem?
— Rüdiger Lange, AUCOTEC
Hi Rüdiger. You are likely running into a couple of problems. Here are our recommendations to resolve the issues:
Specify the correct Windows account in AlwaysUp
Your CAE application needs to run in the Windows account where Visio was installed. If not, your tool will fail when it tries to start Visio.
You see, when you installed and configured Visio, it saved several settings in your account. Those settings are not accessible to other users of the computer.
Even if another user found and launched the Visio executable, Visio would start, but it may come up “blank”. Whatever settings you provided at installation (and any changes you subsequently made while using Visio) may not be visible.
So please enter the user name and password of your Visio Windows account on the Logon tab to have AlwaysUp start your CAE application in that account. For example, here we have configured the “Administrator” account:
Start Visio as a Windows Service too
AlwaysUp will run your CAE application in the background, in the isolated Session 0. Now because COM components cannot communicate easily across login sessions, Visio must run in the same session. Therefore, you should also launch Visio as a Windows Service with AlwaysUp.
We don’t have a tutorial for Visio but setup should be the same as for any application in the Microsoft Office suite. Here are the guides for:
But please be aware of the following cautionary note from Microsoft for when running an Office program as a Windows Service:
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.
That sounds pretty bad, right? However, in our experience, there is a large subset of Office features that work perfectly fine unattended.
However please heed the Redmond warning and test thoroughly, to make sure that your automation functions as expected in the background in Session 0. We will be here to help you if you run into any trouble!