After reading [C # | Excel] by the farmer's uncle, I accidentally remembered a small project I created two years ago, I have encountered this strange problem that the Excel process cannot end. In fact, the solution is very simple. Excel is a very special thing, all operations on the resource are exclusive, so it is necessary to strictly release the resource. In order to better communicate with you and help those programmers who are being confused, I will attach a small piece of my previous code below. In order to be faster and more easily explained, the Code has been deleted and only the structure integrity is saved, but it cannot be compiled smoothly. The Code is as follows:
Namespace to be referenced
Using Execl = Microsoft. Office. Interop. Excel;
Code
Try
{
Microsoft. Office. Interop. Excel. Application excel = new Microsoft. Office. Interop. Excel. Application ();
Microsoft. office. interop. excel. workbook workbook = excel. workbooks. open (lujing2, System. type. missing, false, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing, System. type. missing );
Excel. Visible = true;
Microsoft. Office. Interop. Excel. Worksheet worksheet = (Microsoft. Office. Interop. Excel. Worksheet) workbook. Worksheets. get_Item (1 );
// Start the Excel operation
If (excel. ActiveWorkbook. Saved = false)
{
Excel. ActiveWorkbook. Save ();
}
Excel. Quit ();
Excel = null;
Application. Exit ();
GC. Collect (System. GC. GetGeneration (worksheet ));
GC. Collect (System. GC. GetGeneration (workbook ));
GC. Collect (System. GC. GetGeneration (excel ));
}
Catch
{
}
Finally
{
GC. Collect ();
}
At the same time, there is a controversial issue here. I hereby declare that Microsoft strongly recommends against using the GC. Collect method to forcibly execute spam phones, because it will impede GC's working methods. The GC. Collect method is used to call the collector only when it is clearly known that a large number of objects have stopped referencing.
The com provided by Microsoft for excel is still very good. Please do not blame it.
Supplement to replies from netizens:
Whether Excel is a managed resource doesn't matter at all. I think this is something of different levels. The key is that our program interacts with excel by calling com, our com should not be an unmanaged resource.
Another example is the file upload and package download common in the web. These files are managed resources or unmanaged resources, but nothing can be done, we cannot talk about release or non-release issues. The only difference is that excel operations are exclusive.
Our program calls com, com to execute operations with excel. According to normal code specifications, these operations can be released normally.
The kill program is like an excel program that is suddenly terminated and may produce fragments. Serious excel files may also be damaged. What's more, the excel process cannot be killed at all, however, it will cause exceptions in your program and cause unexpected losses.
For example, if a normal user opens an excel file, performs some operations, and closes the excel file, we do not need third-party software to release any memory.
Do not place a piece of things at different levels; otherwise, it will make yourself messy.
I don't know if I am clear enough, but I still have a problem with my understanding. Please point out that we will discuss it together.