回答編集履歴
2
追記\(指摘・推測\)
answer
CHANGED
|
@@ -10,3 +10,52 @@
|
|
|
10
10
|
気づかずにリリース漏れしていることを客観的に確認しやすい方法が一つ考えられます。面倒なのですが調査が難航しているなら（かつ充分問題がしぼりこめているなら）やってみる価値があるかも知れません。
|
|
11
11
|
|
|
12
12
|
その方法とはExcelに対する全ての操作をC#とまったく同じことをするようなVBAで記述し、その動作を確認することです。その際Excelの全てのCOMオブジェクトはテストコードのサブルーチンのローカル変数にし、グローバル変数には一切COMオブジェクトを格納しないことです。このようにして作成したテストサブルーチンを実行してサブルーチンから呼び出し元へ戻ると全てのCOMオブジェクトは(VBAの自動リリース機能によって)完全にリリースされます。その場合に現象がおきないのであればC#プログラムでのリリース漏れの可能性が高いと思います。逆にVBAのテストサブルーチンを実行しても同様の現象になるのであればリリース漏れの可能性は低いと思います。
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
追記：2016/11/29 00:01
|
|
17
|
+
コードを絞り込まれたようなのでそれをベースに自分もC#でCOM操作のコードを書いてみました。以下説明文に(RC=?)と書いている部分がありますが参照カウンターのことと思ってください。
|
|
18
|
+
|
|
19
|
+
1. リファレンスカウンターの確認方法
|
|
20
|
+
完全ではないかも知れませんが、Marshal.ReleaseComObjectの戻り値がリリース後のCOMオブジェクトの参照カウンターを表しています。これを利用し、リリース後の参照カウンターが0になるかどうかを確認するというデバッグが可能のようです。このリファレンスカウンターがサーバー側にある本当のカウンターかどうかははっきりわかりませんが、いずれにせよそれが0になるかを確認することは有効なデバッグになると思います。
|
|
21
|
+
下の方に「リリースし、かつ結果の参照カウンターをデバッグプリントする」ユーティリティーメソッドReleaseComを書いておきます。
|
|
22
|
+
|
|
23
|
+
2. **finally節のバグ**
|
|
24
|
+
質問コードにあるfinally節の処理に問題があると思います。Marshal.ReleaseComObjectにnullを渡すと例外が発生するからです。try本体で何かの例外が発生したり、処理のルートによって一部のCOMオブジェクト格納用の変数がnullのままになっているとfinally節の途中で例外が発生し、それ以降のリリースが行われないので**リリース漏れ**の危険があります。
|
|
25
|
+
これを回避するには下の方に書いたReleaseComメソッドのようにnullを渡したときに余計なことをしないユーティリティーメソッドを用いると簡単です。
|
|
26
|
+
|
|
27
|
+
3. バグがどうかはっきりわからなかったもの
|
|
28
|
+
Book.Sheets[index]というコードはリリース漏れの原因になっているような気がしましたがはっきりしません。このコードを実行するとExcel側では次のことが起こるはずです。
|
|
29
|
+
(1)WorkbookのSheetsプロパティーを返す。結果はWorksheetsオブジェクト(RC=1)
|
|
30
|
+
(2)Worksheetsのitemメソッドを実行。結果はWorksheetオブジェクト(RC=1)
|
|
31
|
+
質問のコードでは(1)をリリースしていないように見えます。でも実際に実行してみると(1)をリリースしてもしなくても違いが見えませんでした。ここはどういう仕組みになっているのか自分にもわかりませんが、自分なら安全側に考えて、
|
|
32
|
+
sheets = Book.Sheets;
|
|
33
|
+
sheet = sheets[index];
|
|
34
|
+
...
|
|
35
|
+
ReleaseCom(sheet, "Sheet");
|
|
36
|
+
ReleaseCom(sheets, "Sheets");
|
|
37
|
+
と書きます。（自信なし）
|
|
38
|
+
|
|
39
|
+
4. リリースの場所
|
|
40
|
+
質問のコードではメソッドの引数に渡されるxlApp, xlBookをメソッドの中でリリースしています。調べてみるとこれは奇妙な実装に見えてきました。COMオブジェクトを引数に渡しても参照カウンターは上がりません。ゆえにこのメソッドでリリースし、呼び出し元でもリリースすると「リリース過多」となりRC=-1になってしまいます。MSDNをざっと読むとRC=-1のオブジェクトに対して何かのメソッド呼び出しやプロパティー参照をするとunmanagedコードの中で危険なことが起こるように見えました。
|
|
41
|
+
よってリリース対象は「そのメソッドの中でプロパティー参照やメソッド参照を通じて新たに取得したCOMオブジェクトだけ」にするのが適切だと思います。
|
|
42
|
+
|
|
43
|
+
```C#
|
|
44
|
+
Excel.WorkBook xlBook = ...;
|
|
45
|
+
...
|
|
46
|
+
ReleaseCom(xlBook, "book"); //<=このように使う
|
|
47
|
+
|
|
48
|
+
...
|
|
49
|
+
public static void ReleaseCom(object o, string msg) {
|
|
50
|
+
if (o != null) {
|
|
51
|
+
int rc = Marshal.ReleaseComObject(o);
|
|
52
|
+
log("released rc={0} {1}", rc, msg);
|
|
53
|
+
} else {
|
|
54
|
+
log("not released {0}", msg);
|
|
55
|
+
}
|
|
56
|
+
}
|
|
57
|
+
|
|
58
|
+
public static void log(string format, params object[] args) {
|
|
59
|
+
Debug.WriteLine(string.Format(format, args));
|
|
60
|
+
}
|
|
61
|
+
```
|
1
追記（リリース漏れ検証方法）
answer
CHANGED
|
@@ -2,4 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
[C#からExcel操作 Excelを閉じる際にVBAプロジェクトパスワード確認画面が表示されてしまう](https://teratail.com/questions/55566)
|
|
4
4
|
|
|
5
|
-
上の回答には「リリース漏れ問題を撲滅する必要がある」と書きましたが、逆を言えば「**リリース問題さえ無くせばオブジェクトは解放できるはず**」と思います。
|
|
5
|
+
上の回答には「リリース漏れ問題を撲滅する必要がある」と書きましたが、逆を言えば「**リリース問題さえ無くせばオブジェクトは解放できるはず**」と思います。
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
追記：2016/11/28 21:17
|
|
10
|
+
気づかずにリリース漏れしていることを客観的に確認しやすい方法が一つ考えられます。面倒なのですが調査が難航しているなら（かつ充分問題がしぼりこめているなら）やってみる価値があるかも知れません。
|
|
11
|
+
|
|
12
|
+
その方法とはExcelに対する全ての操作をC#とまったく同じことをするようなVBAで記述し、その動作を確認することです。その際Excelの全てのCOMオブジェクトはテストコードのサブルーチンのローカル変数にし、グローバル変数には一切COMオブジェクトを格納しないことです。このようにして作成したテストサブルーチンを実行してサブルーチンから呼び出し元へ戻ると全てのCOMオブジェクトは(VBAの自動リリース機能によって)完全にリリースされます。その場合に現象がおきないのであればC#プログラムでのリリース漏れの可能性が高いと思います。逆にVBAのテストサブルーチンを実行しても同様の現象になるのであればリリース漏れの可能性は低いと思います。
|