Microsoft Office Excel cannot access the file 'c:\inetpub\wwwroot\Timesheet\App_Data\Template.xlsx'
Try this:
- Create the directory
C:\Windows\SysWOW64\config\systemprofile\Desktop
(for the 32-bit version of Excel/Office on a 64-bit Windows computer) or
C:\Windows\System32\config\systemprofile\Desktop
(for a 32-bit version of Office on a 32-bit Windows computer or a 64-bit version of Office on a 64-bit Windows computer).
- For the Desktop directory, add Full control permissions for the
relevant user (for example in Win7 & IIS 7 & DefaultAppPool set permissions for user IIS AppPool\DefaultAppPool).
Original post with answer:
- Excel 2007 automation on top of a Windows Server 2008 x64
Microsoft Excel cannot access the file on Windows Server 2012
So I came across this Microsoft Blog. Although this is very weird that why you need to create the Desktop folders but it works. In case the link gets removed see the Answer Below
Resolution
************ ·
A “Desktop” folder seems to be necessary in the “systemprofile” folder in the location C:\Windows\SysWOW64\config\ to open an Excel file ·
Create the “Desktop” folder for Windows 2008 Server (x64) under the location C:\Windows\SysWOW64\config\systemprofile ·
And for a 32 bit Windows 2008 Server create the “Desktop” folder under the location C:\Windows\System32\config\systemprofile ·
After creating the folder the SQL Server jobs should execute successfully
C# Error: Microsoft Excel cannot access the file '...'. There are several possible reasons
Unsupported
The short answer is that trying to programatically manipulate an Excel document using the Automation API is not supported outside of a UI context. You will come across all sorts of frustrations (for example, the API is permitted to show dialogs - how are you going to click on "OK" if it's running on a web-server?).
Microsoft explicitly state this here
Microsoft does not recommend or support server-side Automation of Office.
So what do I use?
I would recommend using the OpenXML SDK - this is free, fully supported and much faster than the Automation API.
Aspose also has a set of products, but they are not free, and I've not used them.
But I HAVE to do it this way
However, if you absolutely have to use the COM API then the following might help you:
HERE BE DRAGONS
The big problem with automation in Excel is that you need to ensure you close every single reference whenever you use them (by calling ReleaseComObject on it).
For example, the following code will cause Excel to stay open:
var range;
range = excelApplication.Range("A1");
range = excelApplication.Range("A2");
System.Runtime.InteropServices.Marshal.ReleaseComObject(range)
range = Nothing
This is because there is still a reference left over from the call to get range "A1".
Therefore, I would recommend writing a wrapper around the Excel class so that any access to, e.g., a range frees any previous ranges accessed before accessing the new range.
For reference, here is the code I used to release COM objects in the class I wrote:
Private Sub ReleaseComObject(ByVal o As Object)
Try
If Not IsNothing(o) Then
While System.Runtime.InteropServices.Marshal.ReleaseComObject(o) > 0
'Wait for COM object to be released.'
End While
End If
o = Nothing
Catch exc As System.Runtime.InteropServices.COMException
LogError(exc) ' Suppress errors thrown here '
End Try
End Sub
Cannot access excel file
There is a detailed MS knowledge base article titled Considerations for server-side Automation of Office. Some key excerpts:
User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the
applications. The applications try to initialize toolbars, menus,
options, printers, and some add-ins based on settings in the user
registry hive for the user who launches the application. Many services
run under accounts that have no user profiles (such as the SYSTEM
account or the IWAM_[servername] accounts). Therefore, Office may not
initialize correctly on startup. In this situation, Office returns an
error on the CreateObject function or the CoCreateInstance function.
Even if the Office application can be started, other functions may not
work correctly if no user profile exists.Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some
circumstances, applications may need to be made visible for certain
Automation functions to work correctly. If an unexpected error occurs,
or if an unspecified parameter is needed to complete a function,
Office is designed to prompt the user with a modal dialog box that
asks the user what the user wants to do. A modal dialog box on a
non-interactive desktop cannot be dismissed. Therefore, that thread
stops responding (hangs) indefinitely. Although certain coding
practices can help reduce the likelihood of this issue, these
practices cannot prevent the issue entirely. This fact alone makes
running Office Applications from a server-side environment risky and
unsupported.
Obviously, as has been pointed out in the comments, using the SYSTEM
account is a mistake. You would need to run the service under an account that has a user profile.
But even when you fix that, the other bullet point will kill you. Office applications do indeed assume they are running under an interactive desktop. My advice is to abandon attempting to automate Office from a service. Use a library like Aspose instead. Or run the process on an interactive desktop.
Related Topics
Does ASP.NET MVC Have Application Variables
Cast Linq Result to Observablecollection
C# Guid and SQL Uniqueidentifier
How to Get the Taskbar's Position and Size
How to Unmask Password Text Box and Mask It Back to Password
Nested "From" Linq Query Expressed with Extension Methods
Break Out of a While Loop That Contains a Switch Statement
Extremely Large Single-Line File Parse
Microsoft.Office.Interop.Excel Really Slow
Why Is It Impossible to Override a Getter-Only Property and Add a Setter
How to Use a Controller in Another Assembly in ASP.NET Core MVC 2.0
How Does Datetime.Touniversaltime() Work
C# MVC 3 Using Selectlist with Selected Value in View
How to Make JSON.Net Serializer to Call Tostring() When Serializing a Particular Type