none
Ecxelのプロセス停止方法について RRS feed

  • 質問

  • VB2010で処理した数値データなどをExcelファイルに出力する以下のようなプログラム(主要箇所を記述)を作成しています。
     
    Dim ExcelApp As Object
    Dim ExcelBook As Object
    Dim ExcelSheet11 As Object


    'Excelファイルのオープン
     
    ExcelApp = CreateObject("Excel.Application")
     
    ExcelBook = ExcelApp.Workbooks.Open("E:\IDACS_Data.xls")
     
    ExcelSheet11 = ExcelBook.Worksheets("data1")
     

     

     
    'セルへの処理結果代入
     
    ExcelSheet11.cells(Line, 1) = 変数1
     
    ExcelSheet11.cells(Line, 2) = 変数2
     

     

     
    'Excelの作業終了処理
     
    ExcelApp.ActiveWorkbook.Close(True)
     
    ExcelApp.Quit()
     
    ExcelSheet11 = Nothing
     
    ExcelBook = Nothing
     
    ExcelApp = Nothing
     
    です。
     
    WindowsのタスクマネージャでExcelのプロセス実行状態を見ていると、ExcelApp = CreateObject("Excel.Application") を実行するタイミングでExcelが表れます。
     
    その後、データなどの処理とExcelへの書き込み処理を行って、Excelの作業終了処理の ExcelApp = Nothing を実行してもプロセスからExcelが消えません。
     
    作成しているプログラム全体を停止したタイミングでタスクマネージャのプロセスからExcelが消えます。
     
    現在は、1ファイルのExcelファイル処理を実施していますが、今後、複数のExcelファイル処理を実施するためにExcelファイル処理の開始終了ごとにExcelプロセスの開始終了するようなプログラムを考えています。
     
    Excelのプロセスを停止する命令をプログラムに設定すればよいと思い、いろいろな情報をWebで探していますが、見つけられません。
     
    どなたかExcelファイル終了後にタスクマネージャのプロセスを終了する方法を教えてください。
     
    よろしくお願いします。

    2011年9月23日 11:41

回答

  • 私の回答も言葉足らずのことがあるかとは思いますが、ReleaseComObjectだけを紹介したのでそれが必須ではないかと捉えられたのであれば、私ももう少し気を付けて回答するように努力したいと思います。ただ、最初にReleaseComObjectを試していただき、それで解決するのであればそれで良いと思っていたのは事実です。

    「Excel を起動または終了する」には

    その後に System.Runtime.InteropServices.Marshal クラスの ReleaseComObject メソッドを使用して、COM オブジェクトを解放しなければなりません。

    と必須としか解釈できない記述があります。それを挙げられたtrapemiyaさんもきっとそういう思いだと受け取るのが当然では? 別にtrapemiyaさん個人を責めているわけではありません。この手の質問に対して「とりあえずReleaseComObjectを呼んどけ」という風潮があり、それが対処療法なのか正式な手順なのかが不明確なまま広まっていて、しかし私個人としてはGCで管理されているのだからReleaseComObjectは対処療法なのではという疑問を持っている、と言いたかっただけです。

    繰り返しになりますが私としては

    1. Workbooksのような途中で生成されるオブジェクトもすべて変数に保持して、参照とは逆順にNothingでクリアしていく方法
      (C#の場合はnull代入ではなくブロックスコープで変数の有効期間を制御する) 
    2. 1.で改善しなかった場合は適当なタイミングでGC.Collectを呼ぶ方法
    3. 1.2.で改善しなかった場合はNothingではなくReleaseComObjectしていく方法

    の順で試していくのが適当なのかな、と考えています。2.3.はどちらが先かは状況次第で。

    ちなみにMarshal.ReleaseComObjectは危険な場合があるということもあるそうです。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 4:38
  • 以下が参考になると思います。

    Excel を起動または終了する
    http://jeanne.wankuma.com/tips/csharp/excel/execute.html

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月23日 11:55
    モデレータ
  • 「なんらかのタイミング」というのが GC のタイミングなのではないかと思われます。(GC(ガベージ コレクション)についてはご存じですよね。)
    試しに一連の処理の最後に GC を実行させると Excel は毎回終了しないでしょうか。KB のサンプル コードでも GC を実行しています。

    Visual Basic .NET からオートメーションを使用して Office マクロを実行する方法
    http://support.microsoft.com/kb/306682/ja

    ただし、すべての COM オブジェクトをローカル変数に保持しておいて、漏れなく ReleaseComObject してあげれば本来は GC は必要ではなくて、GC を実行しないといけないということは解放忘れがあるということです。
    例えば元のコードにある次の部分、
    ExcelBook = <strong>ExcelApp.Workbooks</strong>.Open("E:\IDACS_Data.xls")
    

    太字のところに Workbooks オブジェクトへの参照が隠れています。これもローカル変数に保持しておいて最後に ReleaseComObject しないといけません。
    ExcelBooks = ExcelApp.Workbooks<br/>ExcelBook = ExcelBooks.Open("E:\IDACS_Data.xls")
    

    このように保持しておいて、最後に ReleaseComObject すべきではないかと思います。
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月24日 15:39
  • この手の回答で必ずと言っていいほどMarshal.ReleaseComObject()が挙げられるんですが、これって本当に必須なのでしょうか?

    GCのリファレンスカウントに連動してIUnknown::Release()されるものだと思うのですが…。だれか検証とかしてる人いないかなぁ…

    別に必須ではありませんし、RCW が参照カウンタを管理してファイナライザで Release してくれます。ですので明示的に回収せずともそのうち GC に片付けられます。

    問題になるのはアウトプロセスサーバを使用後即座に終了させたいという場合ぐらいでしょう(つまり、今回の質問のケースです)。この場合なら、Marshal.ReleaseComObject なり明示的な GC.Collect なりが必要になります。GC.Collect は本来関係ないマネージオブジェクトまで掃除の対象になってしまうので、Marshal.ReleaseComObject で解放していくのもアリでしょう。

    // 「アウトプロセスサーバを即座に終了させたい」が要求としてどうなのかは私の知るところではありませんが。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月25日 12:15
  • Excel の Application オブジェクトだけでなく、trapemiya さんがご紹介されたサイトの以下のように

    http://jeanne.wankuma.com/tips/csharp/programming/releasecom.html

    全ての Excel オブジェクトを変数に取って Marshal.ReleaseComObject してください。

    セルを複数扱う場合も全て解放しなければなりません。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 2:26
  • この手の回答で必ずと言っていいほどMarshal.ReleaseComObject()が挙げられるんですが、これって本当に必須なのでしょうか?

    GCのリファレンスカウントに連動してIUnknown::Release()されるものだと思うのですが…。だれか検証とかしてる人いないかなぁ…

    Hongliangさんが既に回答されている通りだと思いますが、以下にこの手の回答でよく紹介されている文書を紹介しておきます。

    .NET アプリケーションのパフォーマンスとスケーラビリティの向上 - 第 7 章 「相互運用パフォーマンスの向上」
    http://msdn.microsoft.com/ja-jp/library/ff647812.aspx

    における、「Marshal.ReleaseComObject」の部分です。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 2:40
    モデレータ
  • RCWはGCで管理されますから、Excelのプロセスがすぐに消えなくても気にしないという選択肢もあると思いますし、GC.Collect()で強制的に終了させる方法もあると思います。ただし、GC.Collect()はよく言われているようにパフォーマンスの問題がありますので、第一選択肢ではないと思います。よって、第一選択肢はReleaseComObject()であろうと思っていますし、今回の場合を含め、多くの場合それで問題ないと思っています。

    ある処理を行うにはいろいろなやり方があります。例えばデータベースからデータを読んでくるときにストアドプロシージャで行うのか、SQL CLRで行うのか、VB側でSQL文を組み立ててしまうかなどです。これらの方法を全てケアして回答するのは現実的ではないと思います。私の回答も言葉足らずのことがあるかとは思いますが、ReleaseComObjectだけを紹介したのでそれが必須ではないかと捉えられたのであれば、私ももう少し気を付けて回答するように努力したいと思います。ただ、最初にReleaseComObjectを試していただき、それで解決するのであればそれで良いと思っていたのは事実です。それでもダメであれば、以下のページにあるように、GC.Collect()を試してもらおうと思っていました。第一選択肢ではないので、あまり積極的に紹介したくはないのですが、ちゃんとトラブルシューティングに載っていますので。

    (参考)
    Visual Studio .NET クライアントで自動化した Office アプリケーションが終了しない
    http://support.microsoft.com/default.aspx?scid=kb;ja;317109

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年9月26日 3:46
    モデレータ

すべての返信

  • 以下が参考になると思います。

    Excel を起動または終了する
    http://jeanne.wankuma.com/tips/csharp/excel/execute.html

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月23日 11:55
    モデレータ
  • trapemiya 様

    ご回答いただきありがとうございます。

    ご回答いただいたサイトを参考に“System.Threading.Thread.Sleep(1000)"と“”System.Runtime.InteropServices.Marshal.ReleaseComObject(ExcelApp)”を追加して実行しました。

    しかし、“”System.Runtime.InteropServices.Marshal.ReleaseComObject(ExcelApp)”を実行した時点で、タスクマネージャのプロセスからExcelは解放しません。

    ただ、何度がExcelファイル処理を実行するとそのたびにタスクマネージャのプロセスにExcelは追加しますが、Excelを終了する際のなんかのタイミングで一度にタスクマネージャのプロセスから解放されます。

    私が希望していた内容の命令文でしたが実行と同時に解放されないのは、ほかに問題があるのでしょうか。

     

    2011年9月23日 23:42
  • しかし、“”System.Runtime.InteropServices.Marshal.ReleaseComObject(ExcelApp)”を実行した時点で、タスクマネージャのプロセスからExcelは解放しません。

    ただ、何度がExcelファイル処理を実行するとそのたびにタスクマネージャのプロセスにExcelは追加しますが、Excelを終了する際のなんかのタイミングで一度にタスクマネージャのプロセスから解放されます。

    私が希望していた内容の命令文でしたが実行と同時に解放されないのは、ほかに問題があるのでしょうか。


    動きからすると GC が関係していそうに思えます。
    2011年9月24日 2:08
  • GCが関係していそう。

    とは、どういうことが考えられるのでしょうか。

    2011年9月24日 11:17
  • 「なんらかのタイミング」というのが GC のタイミングなのではないかと思われます。(GC(ガベージ コレクション)についてはご存じですよね。)
    試しに一連の処理の最後に GC を実行させると Excel は毎回終了しないでしょうか。KB のサンプル コードでも GC を実行しています。

    Visual Basic .NET からオートメーションを使用して Office マクロを実行する方法
    http://support.microsoft.com/kb/306682/ja

    ただし、すべての COM オブジェクトをローカル変数に保持しておいて、漏れなく ReleaseComObject してあげれば本来は GC は必要ではなくて、GC を実行しないといけないということは解放忘れがあるということです。
    例えば元のコードにある次の部分、
    ExcelBook = <strong>ExcelApp.Workbooks</strong>.Open("E:\IDACS_Data.xls")
    

    太字のところに Workbooks オブジェクトへの参照が隠れています。これもローカル変数に保持しておいて最後に ReleaseComObject しないといけません。
    ExcelBooks = ExcelApp.Workbooks<br/>ExcelBook = ExcelBooks.Open("E:\IDACS_Data.xls")
    

    このように保持しておいて、最後に ReleaseComObject すべきではないかと思います。
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月24日 15:39
  • GCについて、Webで検索して確認しました。

    Exceファイルのオープンを以下のように変更してみましたが、改善されませんでした。

    ’ExcelBook = ExcelApp.Workbooks.Open(E:\IDACS_Data.xls"))   <= コメントに変更
            Dim ExcelBook_Test As Object
            ExcelBook_Test = ExcelApp.Workbooks
            ExcelBook = ExcelBook_Test.Open(E:\IDACS_Data.xls")

    もう一つの方法、『Visual Basic .NET からオートメーションを使用して Office マクロを実行する方法』をいままでトライしていましたが、実行すると【Form1.Designer.vb】が開いて、ビルドエラーとなり、数か所のソース上で『クラス”Workbook.Class"への参照は、そのアセンブリがNo-PIAモードを使用してリンクされている場所には許可されません。』が表示されます。

    また、『Windows フォームデザイナーが必要です』とのコメント行があります。まだ、なんか設定する必要があるのでしょうか。

    サンプルソースと使用しているVBのバージョンが違うのでしょうか。

    当方が使用しているVBは、VB2010を使用しています。

     

    2011年9月25日 4:20
  • はじめに、一定時間後に Excel が終了するという現象によって、私がどうして GC を連想したかはご理解いただけましたでしょうか?
    この点をご理解いただけてないと、以降の話のポイントもご理解いただけないのではないかと思います。

    次に KB のサンプル コードの話ですが、ここでの趣旨はサンプルをマネすることではなくて、一連の処理の最後に GC を走らせていることを示したかっただけです。
    同じように、mori mori さんのコードでも一連の処理の最後に GC を実行すると何か変化があるのではないかと推測しました。

    オープンの処理については、オブジェクトをいちいちローカル変数に取らずに "."(ピリオド)を連ねて記述した場合に、実は COM オブジェクトの参照が発生してしまっていて、ReleaseComObject を呼び出そうにも呼び出せないケースがある、という話の一例として挙げただけです。
    mori mori さんのコードにある同じような記述をすべて見直した方が良いのではないかと思います。
    (ただローカル変数に保持するだけではなくて、すべて ReleaseComObject で解放してあげてくださいね。)

    現在のコードのままで一気に片づけてしまおうとするのではなくて、まずは Excel を起動するだけ、次にワークシートを開くまで、といった具合に少しずつ実装していきながら、毎回確実に Excel を終了できることを確認する、といった具合に地道に進むのがいいと思うのですが、いかがでしょうか。
    2011年9月25日 9:31
  • この手の回答で必ずと言っていいほどMarshal.ReleaseComObject()が挙げられるんですが、これって本当に必須なのでしょうか?

    GCのリファレンスカウントに連動してIUnknown::Release()されるものだと思うのですが…。だれか検証とかしてる人いないかなぁ…

    2011年9月25日 11:46
  • この手の回答で必ずと言っていいほどMarshal.ReleaseComObject()が挙げられるんですが、これって本当に必須なのでしょうか?

    GCのリファレンスカウントに連動してIUnknown::Release()されるものだと思うのですが…。だれか検証とかしてる人いないかなぁ…

    別に必須ではありませんし、RCW が参照カウンタを管理してファイナライザで Release してくれます。ですので明示的に回収せずともそのうち GC に片付けられます。

    問題になるのはアウトプロセスサーバを使用後即座に終了させたいという場合ぐらいでしょう(つまり、今回の質問のケースです)。この場合なら、Marshal.ReleaseComObject なり明示的な GC.Collect なりが必要になります。GC.Collect は本来関係ないマネージオブジェクトまで掃除の対象になってしまうので、Marshal.ReleaseComObject で解放していくのもアリでしょう。

    // 「アウトプロセスサーバを即座に終了させたい」が要求としてどうなのかは私の知るところではありませんが。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月25日 12:15
  • VBの初心者にとってGCについては、私なりに理解したつもりです。

    また、KBのサンプルコードは初心者にとっては、マネするしかないと思います。と、言ってもエラーが発生したところはWebなどの情報を探してみていますが、やはり初心者です。専門的な用語があり、よくわからに状態となり、このサイトで教えてもらっている状態です。

    VBでExcelファイルを操作するのはいろいろな本を探していますが、詳しく解説している本を見つけらせず初心者にとってWebからサンプルコードなどを探してマネをするようにして作成するしかない状態です。

    わかる範囲で地道に作成してみます。

    2011年9月25日 14:32
  • 当方が思っている処理とは、Excelの作業を終了するようなソースコードを作成したつもりですが、タスクマネージャのプロセスにExcelが動作しているような状態のため、どうしたらすぐに停止するようにできるのかと思い質問していました。

    2011年9月25日 14:42
  • Excel の Application オブジェクトだけでなく、trapemiya さんがご紹介されたサイトの以下のように

    http://jeanne.wankuma.com/tips/csharp/programming/releasecom.html

    全ての Excel オブジェクトを変数に取って Marshal.ReleaseComObject してください。

    セルを複数扱う場合も全て解放しなければなりません。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 2:26
  • この手の回答で必ずと言っていいほどMarshal.ReleaseComObject()が挙げられるんですが、これって本当に必須なのでしょうか?

    GCのリファレンスカウントに連動してIUnknown::Release()されるものだと思うのですが…。だれか検証とかしてる人いないかなぁ…

    Hongliangさんが既に回答されている通りだと思いますが、以下にこの手の回答でよく紹介されている文書を紹介しておきます。

    .NET アプリケーションのパフォーマンスとスケーラビリティの向上 - 第 7 章 「相互運用パフォーマンスの向上」
    http://msdn.microsoft.com/ja-jp/library/ff647812.aspx

    における、「Marshal.ReleaseComObject」の部分です。

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 2:40
    モデレータ
  • つまりtrapemiyaさんはその説明を読んだ上で、最初のコメントでは、「Excel を起動または終了する」を紹介し無条件に Marshal.ReleaseComObject() を呼び出すことを提案したんですか?
    2011年9月26日 2:51
  • RCWはGCで管理されますから、Excelのプロセスがすぐに消えなくても気にしないという選択肢もあると思いますし、GC.Collect()で強制的に終了させる方法もあると思います。ただし、GC.Collect()はよく言われているようにパフォーマンスの問題がありますので、第一選択肢ではないと思います。よって、第一選択肢はReleaseComObject()であろうと思っていますし、今回の場合を含め、多くの場合それで問題ないと思っています。

    ある処理を行うにはいろいろなやり方があります。例えばデータベースからデータを読んでくるときにストアドプロシージャで行うのか、SQL CLRで行うのか、VB側でSQL文を組み立ててしまうかなどです。これらの方法を全てケアして回答するのは現実的ではないと思います。私の回答も言葉足らずのことがあるかとは思いますが、ReleaseComObjectだけを紹介したのでそれが必須ではないかと捉えられたのであれば、私ももう少し気を付けて回答するように努力したいと思います。ただ、最初にReleaseComObjectを試していただき、それで解決するのであればそれで良いと思っていたのは事実です。それでもダメであれば、以下のページにあるように、GC.Collect()を試してもらおうと思っていました。第一選択肢ではないので、あまり積極的に紹介したくはないのですが、ちゃんとトラブルシューティングに載っていますので。

    (参考)
    Visual Studio .NET クライアントで自動化した Office アプリケーションが終了しない
    http://support.microsoft.com/default.aspx?scid=kb;ja;317109

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年9月26日 3:46
    モデレータ
  • 私の回答も言葉足らずのことがあるかとは思いますが、ReleaseComObjectだけを紹介したのでそれが必須ではないかと捉えられたのであれば、私ももう少し気を付けて回答するように努力したいと思います。ただ、最初にReleaseComObjectを試していただき、それで解決するのであればそれで良いと思っていたのは事実です。

    「Excel を起動または終了する」には

    その後に System.Runtime.InteropServices.Marshal クラスの ReleaseComObject メソッドを使用して、COM オブジェクトを解放しなければなりません。

    と必須としか解釈できない記述があります。それを挙げられたtrapemiyaさんもきっとそういう思いだと受け取るのが当然では? 別にtrapemiyaさん個人を責めているわけではありません。この手の質問に対して「とりあえずReleaseComObjectを呼んどけ」という風潮があり、それが対処療法なのか正式な手順なのかが不明確なまま広まっていて、しかし私個人としてはGCで管理されているのだからReleaseComObjectは対処療法なのではという疑問を持っている、と言いたかっただけです。

    繰り返しになりますが私としては

    1. Workbooksのような途中で生成されるオブジェクトもすべて変数に保持して、参照とは逆順にNothingでクリアしていく方法
      (C#の場合はnull代入ではなくブロックスコープで変数の有効期間を制御する) 
    2. 1.で改善しなかった場合は適当なタイミングでGC.Collectを呼ぶ方法
    3. 1.2.で改善しなかった場合はNothingではなくReleaseComObjectしていく方法

    の順で試していくのが適当なのかな、と考えています。2.3.はどちらが先かは状況次第で。

    ちなみにMarshal.ReleaseComObjectは危険な場合があるということもあるそうです。

    • 回答としてマーク 山本春海 2011年10月19日 8:22
    2011年9月26日 4:38
  • 「Excel を起動または終了する」には
    その後に System.Runtime.InteropServices.Marshal クラスの ReleaseComObject メソッドを使用して、COM オブジェクトを解放しなければなりません。

    と必須としか解釈できない記述があります。それを挙げられたtrapemiyaさんもきっとそういう思いだと受け取るのが当然では?

    あ~、すみません、そこでしたか。正直、「Excel を起動または終了する」に目を通してから回答したわけではありませんので、その言い回しには気が付いていませんでした。昔、何度も読んているじゃんぬねっとさんのページで、検索したままURLを張り付けただけです。回答する前に一度目を通さなければなりませんね。反省します。ただし、目を通しても気が回らなかったかもしれませんが(^^;

    この手の質問に対して「とりあえずReleaseComObjectを呼んどけ」という風潮があり、それが対処療法なのか正式な手順なのかが不明確なまま広まっていて、しかし私個人としてはGCで管理されているのだからReleaseComObjectは対処療法なのではという疑問を持っている、と言いたかっただけです。

    この手の質問ではExcelのプロセスが落ちないので、すぐに落ちる方法を探されているのがほとんどだと思います。よって、GC任せにしないので、ReleaseComObjectが紹介されているケースが多いです。ReleaseComObjectは対処法ではなくて、COMオブジェクトが管理している参照カウントを減少させるので、目的を達成するための正式な手続きの一つだと思います。しかし、Excelを扱う場合、関連するCOMオブジェクトの数が多くなり、非常に見通しの悪いコードになりがちです。これとバーターにかけた時、GC任せでもいいかなと思います。つまり、しばらくExcelのプロセスが残っていても気にしないということです。
     

    1. Workbooksのような途中で生成されるオブジェクトもすべて変数に保持して、参照とは逆順にNothingでクリアしていく方法
      (C#の場合はnull代入ではなくブロックスコープで変数の有効期間を制御する) 
    2. 1.で改善しなかった場合は適当なタイミングでGC.Collectを呼ぶ方法
    3. 1.2.で改善しなかった場合はNothingではなくReleaseComObjectしていく方法

    の順で試していくのが適当なのかな、と考えています。2.3.はどちらが先かは状況次第で。

    今はパソコンにもメモリが結構積まれているのでそれほど気にならないかもしれませんが、.NET 1.1の頃はExcelのプロセスが残っていることをずいぶん気にした記憶があります。時代の移り変わりとともにGC任せが主流になってもおかしくないですし、GC.Collectのパフォーマンスも許容できる状況が増えていくのかもしれませんね。

    ちなみにMarshal.ReleaseComObjectは危険な場合があるということもあるそうです。

    VS2010の問題のようですから今回の件とは直接問題ないようですが、勉強になりました。ありがとうございます。
    おそらく、VS2010でRCW -> CCW -> マネージド っていう流れが存在するようになったのがダメなんですよね? でも、これだとGCでもダメなような気がしますが、RCWの仕組みが変わって、RCWのファイナライザでうまくやるようになったのかな? あ~、そうか、単にRCWを使うのをやめたのかな?

     


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/
    2011年9月26日 6:31
    モデレータ