im working on a Window server 2008, in this server i developed a vb.net 2008 console application that open a excel 2003 file and use its contents to create a xml file, so i have two situations:
1. Differences in execution of the program: if i run the application from the Visual Studio or directly from the executable it open and process the excel without problems but if i configured a task on the windows task scheduler or in the adtempus that execute this program its failed and throws this exception:
Exception from HRESULT: 0x800A03EC- at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad)
at .Module1.convertExcelToXmlFile(String excelFile)
i have read alot about this exception, but at the moment im unable to resolved, so I want to know how this program can execute correctly from Visual Studio or directly from the execute but failed when its execute on a task if both situations are in the same server? is there a way to fix this behavior?
2. In the console application when i open the excel file with the open method, the file in excel appears for a few seconds then it closed, is there a way to access the excel file contents but that the file dont show in Ms Excel?
thanks.
You should not be using Office Interop in an unattended process.
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.
http://support.microsoft.com/?id=257757
There are a number of products that will manipulate Excel docs and run correctly unattended.
Is the Excel file you're trying to open on the network?
If so, the problem is most likely because your Task Scheduler service and any jobs it runs are (by default) running under the local SYSTEM account, which is prohibited from network access.
If you change the task to run under a different account (say, for example, a domain account that you have given privileges for the remote fileshare). (Note that this change may effect how other scheduled tasks run, so you'll want to be quite sure of the permissions needed.)
Just in case you have not figured it out yet, the most-likely resolution which worked for me can be found at this URL :
https://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64?forum=innovateonoffice
If your server is a 64-bit one, create a folder named 'Desktop' in the below mentioned path i.e. C:\Windows\SysWOW64\config\systemprofile\Desktop
If your server is a 32-bit one, please make this folder C:\Windows\System32\config\systemprofile\Desktop
Related
I am receiving an error which says The requested operation requires elevation when I am trying to create an outlook object either by early binding or late binding method with below statements
Set olApp = New Outlook.Application
or
Set olApp = CreateObject("Outlook.Application")
It only works when I open this Excel file with "Run as Admin" mode and run my macro. Can you help me to resolve this issue? I do not want to run my Excel with "Run as Admin..." mode to execute my code.
I am using MS-Office professional 2013 and I am also part of the administrative group on my machine.
The only reason for this that I can think of, is that you somehow have OUTLOOK.EXE itself configured to run as administrator.
Unless you remove that configuration, the only way to instantiate an Outlook application is through an elevated process, since a non-admin process can't spawn an admin process.
Close all instances of Excel, and possibly reboot your computer.
Or in my case, I was able to use SysInternals Process Explorer to kill all instances of Excel and Access (I use VBA in both, with references between the two).
In Windows 10, I find I cannot do some things in VBA if my Excel or Access are started with normal user rights. I found a search result somewhere (which I now cannot find) that recommended starting them with administrative rights. I did so, and it resolved the error. Since then I created shortcuts to always start them with admin rights.
However, the bookkeeping software we use exports to Excel, and it sometimes creates new instances. So when I look in Process Explorer, I find multiple root-instances of Excel, some with administrator rights and owned by Explorer.exe, and others with user rights and owned by the bookkeeping program or some other Windows automation process.
With Windows Task Manager, it doesn't always show all instances. So without it, if closing Excel doesn't fix the problem, it means there's a hidden instance still running, and the only way to fix it is to reboot (or install Process Explorer and use that).
We have a WCF application on our web server. One of the service methods in this app creates an Excel XLS file with data and places the file in a directory so the user can down load the file later.
Our problem is that when this app attempts to create the Excel object, we get this error: Error in Create Excel Helper Workbook, and Application: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046}
failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password.
This is the line that causes the error:
using EX = Microsoft.Office.Interop.Excel;
EX.Application Application = new EX.Application(); //causes error
I did some research and what I have tried is to go into DCOMCNFG - Computers - My Computer - DCOM Config and Right clicked "Microsoft Excel previewer" - properties - Security, then added several groups and users to have Local Launch, Local Activation, etc....
But this did not help. Some of the articles say to choose "Microsoft Excel Application". However, I only see "Microsoft Excel previewer" in my DCOM Config.
Excel is installed on this server but we still have the above problem.
One strange thing is that if I remote into the server, then have my client(browser) on my PC call the service method to create the XLS, this works without a problem.
What do I have to do to resolve this issue?
You can attempt to make this work by setting the IIS AppPool Identity to a user that has interactive logon rights. The interop assemblies actually work by launching an Excel instance on the server and then communicating with it to perform work.
That being said, having gone down this road before, it is a poor solution. The challenges you'll face are as follows:
Issues with DCOM permissions that are difficult to diagnose and resolve (you're running into this now)
Excel processes get spawned on the server and half the time do not close properly, so your application has to be smart enough to go around killing errant Excel processes, or living with the fact that your application is going to leak memory like crazy
It isn't supported or recommended by Microsoft
Office wasn't designed with server-side security considerations in mind
See the following for additional details:
https://support.microsoft.com/en-us/kb/257757
I have created some automated scripts in VBS to execution some tasks automatically on a remote virtual machine. However, whenever I want to email the result to the people that it concerns, Outlook, on start, gives me this error, preventing me from sending any email. The script could not send anything until I manually dismiss this message (but I did not have to actually solve this). The client machine that sends email is a remote virtual machine. It is managed by a driver machine (another remote virtual machine) in such way that every time a new build comes out the client machine gets restored to a checkpoint and downloads the build and installs it and then tests it. It seems that since it is using a snapshot, the outlook data file will have to be out-of-sync with what's on the server, possibly causing the aforementioned error.
Does anyone know how to handle this error in VBScript? Thank you in advance!
You could try to avoid the use of outlook.ost at all. Turn off cached mode (for Exchange) or turn off any Send/Receive settings for folders. Close Outlook and rename outlook.ost to .old.
Open Outlook and check too see if outlook.ost is not created again.
I've made VB.NET application in VS2010 that uses a 2007 Access database, called MenuDB.mdb. During development, everything was fine.
Now that I'm publishing it, I'm getting weird errors because for some reason the app isn't connecting to the database.
I install the application and run it but as soon as it opens it gives this error:
System.Data.OleDb.OleDbException (0x80004005): Could not find file
'C:\Users\Administrator\AppData\Local\Apps\2.0\Data\OV86PXJA.K3R\8575R5AY.95Z\menu..tion_0d4fa454d69e8e6b_0001.0000_8340d263807cbb71\Data\MenuDB.accdb'.
I know the problem has to do with the way I'm relating the application to the database, but I don't know which way is right. In Solution Explorer I changed the Build Type of MenuDB.accdb to "Content" (earlier it was embedded resource". But it doesn't work either way. In my App.config I have the following connection string:
connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\MenuDB.accdb"
I want that when I deploy the application, the database should just sit in the application folder, wherever it gets installed. How can I do that?
Edit
I don't mind deploying it in such a way that I need to paste the database somewhere myself on the target machine - as long as it works.
If you have multiple users using the same or similar database, and dont have access to a SQL server (MySQL, MSSQL, or others), then co-locate the database at a central location (preferably network location) that all the users will have access to and change the connection string to accomidate the database location being on the network.
Just let it be known, Access can handle up to 10users when doing simple data retrieval/submission but if you ever have it open while others are accessing via data objects, then you may lock them out.
We're instantiating a VB6 COM component from classic ASP on a Windows 2000 Server using Server.CreateObject. We get the 'invalid progid' error message.
The DLL is registered. In fact we can run a VBS file that uses WSCRIPT to instantiate and run the component so that shows it is registered.
Why is ASP failing to instantiate it? Is this permissions related? We've tried things like putting the IUSR and IWAM accounts in the Administrators group (just temporarily) and it didn't seem to help. We've granted Everyone access to the folder containing the DLL.
We were able to register the DLL on another server and run the same ASP page there so it does work.
Just one other thing: the server may have been renamed at one time (the IUSR account name differs from the machine name).
Any help appreciated!
-Krip
You haven't said what OSs are involved, for example those supporting UAC. You also haven't said how this library was registered.
It is very likely that you tried to self-register this thing (for example running regsvr32.exe) and the registration ended up in a virtualized location. Thus it will only be seen as "registered" by a process running under the same user context and subject to virtualization (no manifest declaring it Vista aware).
It could also be registered "per user" in the user's HKCU, but this normally doesn't happen without taking special action.
Even a PDW package would get around this, but an Installer MSI would be better. Just copying things around and running regsvr32.exe on them is not proper deployment.
Start Procmon and see what registry key your app is trying to access. Then go to that key and see where it points.
I am thinking that you simply misspelled the name of the ProgID in your ASP.