I have the following C# function in my project, which is supposed to open and return an existing Excel workbook object:
Application _excelApp;
// ...
private W
I was running into the same issue and I have investigated infomation about "registry hack".
After all, I found another solution that changes no registry values and everything works on properly.
This solution is ...
・Windows 2008 Server x64
Please make this folder.
C:\Windows\SysWOW64\config\systemprofile\Desktop
・Windows 2008 Server x86
Please make this folder.
C:\Windows\System32\config\systemprofile\Desktop
...instead of dcomcnfg.exe.
This operation took away office automation problems in my system.
A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.
It disappears from Windows2008, Windows2003 had the folder, and I think it cause this error.
I think it is safer than "registry hack".
If you try this solution, please let me know results.
I found the following page:
http://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64
Where it says that...
it’s not supported to automate office products UI less. It seems that Windows Server 2008 and Excel 2007 enforce the given statement.
The questioner then describes exactly the situation I am in with a Windows Service that cannot open an Excel file, although the same code in a command-line program has no problem.
The response advises to create the following folder:
Windows 2008 Server x64: C:\Windows\SysWOW64\config\systemprofile\Desktop
Windows 2008 Server x86: C:\Windows\System32\config\systemprofile\Desktop
I have tried this and it worked a treat! Can anyone explain why it is needed and any downsides?
Thanks,
--- Alistair.
Run the program as admin, the C:/ cannot be accessed by a program unless the user is running as admin. You can make your program prompt the user it must be run as admin by altering the ApplicationManifest: How do I force my .NET application to run as administrator?
I had this issue today.
Surprisingly, it seems that the error occurred when the application was run as Administrator.
After we moved to Windows 10, some things (mainly related to IIS) would only work if running Visual Studio as Administrator, so it quickly became a habbit to start VS as Administrator.
The solution was to NOT run the application as Administrator.
This might be related to how our work environments are set up, but I thought it was worht sharing, if anyone else experiences the same issue, and the other solutions don't work for them either.