I use squish for testing and it doesn't close the tested application correct always.
In that case office (Word, Excel, PowerPoint) starts with some recovery options (previous documents getting restored, some dialog windows appear, etc) I need to reset the status of the application before the start of new test.
Isn't it better to close the Office application properly?
For example, you could automate Office application using Automation. The recovery options mean the host application was not closed gracefully or something unexpected happened with it (crash?). So, I'd recommend asking squish developers what is wrong with their software other than looking for a workaround to suppress evidences.
Related
In our organisation a problem occurs when saving Excel files.
Whenever we close a file there is a 50/50 chance that it saves in the location it was already in, but the other times it saves where another file was last saved.
We are all working on a Terminal Server (Windows 2019) using Office 2019.
Did anyone else stumble upon this as well? And perhaps found a solution?
The Considerations for server-side Automation of Office article 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.
I'd suggest using the Open XML SDK instead if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office for more information.
I have a Windows service filling cells in an Excel Workbook via OLE Automation.
The save process is not working, the file is never saved. But when done in a GUI app, the save process works.
The service user is an administrator account. I suspect the interaction with the Desktop.
Any idea?
Don't do this. Find another solution. Microsoft does not support or recommend OLE automation of Office software from anywhere but a workstation desktop session. I can't paraphrase any better than what they say directly, so here's the advice (link above goes into more detail) :
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
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.
If you need your service to store data, a database is probably a good choice. Any users that require the data in an excel spreadsheet could populate their documents from the database. You could even set up template documents to do this automatically.
I had the same problem, run a Delphi software as service, with an administrator user and it gave to me a lot of errors in the read/write process like SaveAs method of Workbook class failed
The solution for read/save was create both folders below:
C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile\
There isn't much sense at all, but it worked.
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
I developed an Addin which consists of Login and the data entry and retrieval functionality. The data entry and retrieval are accessed through REST URL's. The Outlook Startup doesnt has any code, except it checks the outlook version. I implement a plain form which show the user "loading message" initially and the rest of the logic will be handled by a thread. So i hope everything is followed according to the performance, but still i am receiving an addon error as "Outlook Detected an Addin Problem" The Add-in caused outlook to start slowly. I am able to overcome this problem and more and more i am able to get the time statistics for application start or shutdown events. couldany help me how do i resolve this?
Are you trying your AddIn in a debug mode or through an installer ?
First of all, make sure that it has been disabled because it is slow and not because it has errors.
If it has errors, it will cause Outlook to work slowly or even crash.
If it just working slowly, you can try to optimize your AddIn, go through your code again and see what you can do again in a less performance consuming way.
One other thing you can do is, when you will create a setup project for your AddIn to run an installer (instead of debug), you can set your Load Behavior to 16 in the registry.
This will cause the AddIn to load at Outlook startup on the first time after installation and to load on demand the other times. (Load on demand means when the user clicks on the AddIn icon).
This way, your AddIn won't slow Outlook down, except for the first time.
We are working on .NET environment.
Mainly my applications having operation on microsoft files(open/close/save)
As there are many message box prompt comes while opening few microsoft files.
So user has to close this dialog manually and then it will start processing next file.
So is there any way, we can perform our process without any message box interruption ?
Or is there a way, we can close any dialog/messagebox from C# code ?
Thanks