I have a code that open an Excel file and read the content. Each time i run the code for the first time, it opens the Excel file without prompting me. But from the second time going it always prompt me this message
TestFile.xlsx is being modified by user 1. Open as read only
and it always prompt at this portion of the code:
Excel ._Workbook xlsBook = xlsApp .Workbooks.Open (_fileName,0,false,5 ,"","",false ,Excel .XlPlatform .xlWindows ,"",true ,false ,0,true ,false ,false );
NB: i also close the file after the operation done and also using VS 2012
So what can be the problem of this prompt ??
After running your Code and exiting, look in the taskmanager, most likely die EXCEL.EXE instance is still running.
you most likely didn't release all the com objects like:
System.Runtime.InteropServices.Marshal.ReleaseComObject(_theWorkbook);
System.Runtime.InteropServices.Marshal.ReleaseComObject(_sheets);
System.Runtime.InteropServices.Marshal.ReleaseComObject(_workSheet);
System.Runtime.InteropServices.Marshal.ReleaseComObject(_range);
System.Runtime.InteropServices.Marshal.ReleaseComObject(_excelObj);
Make sure there are no resources where the file would be still opened. Could you post the code you're using to close the resource? Perhaps there's an error there.
Finally, as ugly as it is, it's valid for testing purposes: try manually calling the garbage collector after closing the file.
FINALLY, consider using the OpenXml API to work with Excel/Word files, as opposed to the Interop DLLs (remember these require the client to have Excel installed, as opposed to the OpenXml libraries which you can deploy with your application).
Related
Language used: C#
Theory:
I want to create a file with the flag FileOptions.DeleteOnClose in a temporary folder.
The file is successfully created and I write dato onto it, the next step is to launch the application associated with the file Process.Start(...) and allow the user to inspect the document, finally I close my handle and as soon as other process close the handle to the temporary file, the file is deleted by operating system.
My problem is that other processes cannot open the file, even for reading, despite if I add FileShare.ReadWrite | FileShare.Delete to the sharing mode.
Any suggestions?
The other processes need to specify FileShare.Delete when they open the DeleteOnClose file
From the MSDN CreateFile docs:
"FILE_FLAG_DELETE_ON_CLOSE... Subsequent open requests for the file fail, unless the FILE_SHARE_DELETE share mode is specified."
Check this:
You need to make sure that all processes are opening the file with FileShare.ReadWrite and FileShare.Delete.
Even if the creator opens with share-readwrite, if a second program tries to open with share-read, the second program is basically saying no-one else can write. But the first program already has that power so the second open fails.
Switch to Linux scnr
Ok, seriously now: That is a flaw in the Windows operating system which can't really be worked around. Each program opening the file must agree on other programs having the file open in the same time. That was a problem I got many years back when I still used Windows as well. It doesn't suffice to open a file and say: Let anyone else open this as well. The others must also say open this file even if it's open already.
On Linux on the contrary, the operating system doesn't allow any file locking in the way Windows does at all. Here, if any file is used by more than one program simultaneously, the programs itself must make sure, that concurrent accesses get locked out. Additionally, on Linux, we can just create the file, make sure the other process has been started and opened the file and then just delete the file (while it is open). The filename is then removed from the file system immediatelly, but the file is still maintained by the file system driver until the last link (including open file handles) got removed.
Back to your problem: As all of this doen't work on Windows, you could do two other approaches:
Register the file to be deleted on next boot (in the Win3x days, there was a section in the win.ini for that. Newer Windows version still support that, I just can't recall any longer, how it's done now).
Start the other process, wait for it to open the file, close the file and then try each minute to delete the file until deletion succeeds ...
Regards, Bodo
I am busy writing an additional module to an existing C# application. In my module I have to generate some data and add it to ZIP archives created by the main program. (Ionic.Zip library is used). In most cases I can successfully update existing archives and store them again. But sometimes (and quite often) this does not work, since, as far as I understand, something in the main program opens a stream to the concerned archive file and fails to close it before I try to access it.
It is absolutely clear that the process that locks the files is the main program itself (tested with a tool based on How do I find out which process is locking a file using .NET?).
I am not aware of any technical possibility to trace down the point in the code where a file is opened without being (somewhere) closed, but it is my hope that such a technique may exist however and that someone could share some information on it.
TIA
We recently upgraded from Excel 2007 to Excel 2010, and we have found that existing code started failing.
Exception Message:
Office has detected a problem with this file. To help protect your
computer this file cannot be opened.
We have traced this to the line where we open the file
excelApp.Workbooks.Open
Even when opening the file manually, the Protected View Messagebox comes up.
How can we work arround this using C#.
Have a look at using Application.FileValidation Property (Excel) before your Open statement.
Returns or sets how Excel will validate files before opening them.
Read/write
Files that do not pass validation will be opened in a Protected View
window. If you set the FileValidation property, that setting will
remain in effect for the entire session the application is open.
You can set it to one of the enum values in MsoFileValidationMode Enumeration
msoFileValidationDefault
msoFileValidationSkip
if you set it to msoFileValidationSkip before the Open statement, it should bypass the check.
Something like
excelApp.FileValidation = MsoFileValidationMode.msoFileValidationSkip;
before the open statement.
Late to the game here, but this is a common annoyance: you need to define a 'Trusted Location'.
You're not the only developers encountering this problem when your code tries to open a spreadsheet file, and "Office has detected a problem with this file. To help protect your computer this file cannot be opened." is an extremely unhelpful error message.
Look up the Trusted Location code published by Daniel Pineault on DevHut.net in 2010:
DevHut code example: Trusted Location using VBScript
I'll get downvoted to hellandgone for posting VBA in a C# forum, so I'd better not post my implementation of Daniel's code (yes, I'm a VBA developer, bashing out VBA macros all day, not a real coder working with pointy things and curly braces). If you really want to see the VBA, it's in a reply to another post:
https://stackoverflow.com/questions/2962728/office-trusted-locations/28115700#28115700
I believe the proper salutation is 'Share and Enjoy'.
Do, please, put an acknowledgement of the original author, Daniel Pineault, if you reuse the code: it's been widely published without attribution on 'Expert' sites, and that's rather rude.
We had the same issue. Our SSIS package at SQL server uses Excel.Interop to parse files. One day we installed Office 2010 x64 on new server and for some files started getting error:
Office has detected a problem with this file. To help protect your computer this file cannot be opened.
At the same time, other servers work good. We found distinguish in versions of Excel: 14.04763.1000 doesn't work, but 14.0.7015.1000 works for us. The last version number belong to Office 2010 SP2. Eventually we downloaded SP2 and installed it,as result, the error has gone.
here is my question:
I have developed a program that uses Microsoft.Excel COM components in order to read/write over Excel files. Well, my app is doing good but when I open, for instance, another file directly with Excel while my program is running, the file(s) that my app uses appear within Excel. I do not want this. I tried also the Visibility property of Excel Application class, but that was not the solution, it just does not work.
NOTE : I have checked this question out.
Restrict access to excel file opened by C# program
Yet, it says no proper solution actually.
You can use Application.IgnoreRemoteRequests = true. This will avoid users opening excel files in the same Excel process as the one you are using.
There is one caveat though: you have to make sure that all execution paths of your application reset this property to false. This property WILL NOT reset itself when you quit and release your Excel application which means that Excel will not respond correctly to a subsequent user who double clicks on a *.xls file for example.
EDIT: Possible issues with IgnoreRemoteRequest
Ok, to make this clearer I'll detail a little bit more what issues you can run into using this feature (at least these are the only ones I've run into when I had to use this feature).
When setting IgnoreRemoteRequests = true you have to make sure you reset this property BEFORE quiting and/or releasing the COM Excel application. If you don't, Excel will not respond to DDE requests which means if someone double clicks on a *.xls file, the file will not open (Excel will start up, but it wont open the file automatically).
This however is only true if you quit the application and/or release it without reseting the property. You just have to make sure that wherever it is in your code that you are quitting/resetting you set the IgnoreRemoteRquests back to false before.
If you'r application crashes and it hasn't been able to clean up (unhandled exception) then the EXCEL process will keep running (if invisible, you will only see it in the Task Manager). That is normal as your app didnt have a chance to quit and release the internal Excel it is using. This however is not an issue. If a user ignores this "leaked" Excel process until it's eventually killed in next reboot or whatever, or manually kills it from the task bar, Excel will work perfectly fine.
Note: MS Excel 2007. Don't know about behavior of previous versions.
Have you tried running your program under a service account? This should avoid the excel com object interfering with the instance used by the logged in console user, so they will not see the effects of your com objects. It's probably also better security practice to run COM type applications under a service account instead of a user account as well, but that's for another question.
Language used: C#
Theory:
I want to create a file with the flag FileOptions.DeleteOnClose in a temporary folder.
The file is successfully created and I write dato onto it, the next step is to launch the application associated with the file Process.Start(...) and allow the user to inspect the document, finally I close my handle and as soon as other process close the handle to the temporary file, the file is deleted by operating system.
My problem is that other processes cannot open the file, even for reading, despite if I add FileShare.ReadWrite | FileShare.Delete to the sharing mode.
Any suggestions?
The other processes need to specify FileShare.Delete when they open the DeleteOnClose file
From the MSDN CreateFile docs:
"FILE_FLAG_DELETE_ON_CLOSE... Subsequent open requests for the file fail, unless the FILE_SHARE_DELETE share mode is specified."
Check this:
You need to make sure that all processes are opening the file with FileShare.ReadWrite and FileShare.Delete.
Even if the creator opens with share-readwrite, if a second program tries to open with share-read, the second program is basically saying no-one else can write. But the first program already has that power so the second open fails.
Switch to Linux scnr
Ok, seriously now: That is a flaw in the Windows operating system which can't really be worked around. Each program opening the file must agree on other programs having the file open in the same time. That was a problem I got many years back when I still used Windows as well. It doesn't suffice to open a file and say: Let anyone else open this as well. The others must also say open this file even if it's open already.
On Linux on the contrary, the operating system doesn't allow any file locking in the way Windows does at all. Here, if any file is used by more than one program simultaneously, the programs itself must make sure, that concurrent accesses get locked out. Additionally, on Linux, we can just create the file, make sure the other process has been started and opened the file and then just delete the file (while it is open). The filename is then removed from the file system immediatelly, but the file is still maintained by the file system driver until the last link (including open file handles) got removed.
Back to your problem: As all of this doen't work on Windows, you could do two other approaches:
Register the file to be deleted on next boot (in the Win3x days, there was a section in the win.ini for that. Newer Windows version still support that, I just can't recall any longer, how it's done now).
Start the other process, wait for it to open the file, close the file and then try each minute to delete the file until deletion succeeds ...
Regards, Bodo