これまで、Excel VBAでExcelでの開発を行っていたのですが、
今後、勉強がてらVisual C# 2005で開発したいと思っています。
ExcelアドインではなくDocumentLevelのソリューション、業務システムのエンドユーザー向けツール開発がメインです。
(複数のExcelシートとデータベースのデータをインテグレーションして、
Excel形式のレポートを作成するようなものが多いです)
MSDNのサンプルコードなどを見ると、COMを使ってVBAと同じようなことはできそうな感じではあるのですが、
VBAでしかできないこと・VBAの方がよっぽど簡単なことや、
その他、注意すべき点などあれば教えてください。
実際にC#でExcelでの開発を行っている(いた)方からの経験に基づくご回答を期待しています。
よろしくお願いします。
ExcelVBAでできることは、COMで実現できます。
まったく同じといってよいです。
VBAから複数Excelシートの処理やDBアクセス(ADOのCOMオブジェクトをVBAから呼び出せる)もできるので、同じ機能を実装するだけならVBAで作ったほうが簡単な場合も多いです。
C#などでアプリケーション化することで、
・ユーザインターフェイスでExcelっぽさが無くせる(Excelが起動しないで処理できる)
・クライアント/サーバ構成での実装ができる(各処理PCからデータだけ送って、処理はサーバでやらせるのでExcelライセンスが一つでいいとか、WEB化できてクライアントインストールが不要にできるとか)
・Excelシート自体をユーザが開かないのでVBAを壊したりするリスクがない(ちゃんと保護してあればExcelシートでも大丈夫ですが)
などメリットはあると思います。
注意点としては、
C#でExcel機能を使ったプログラムを作る場合、
利用するExcelのバージョン違いを考慮しないといけません。
Excel2003(Ver.11)だけ考慮してつくったアプリだと、それ以外のExcelが入った環境ではエラーになります。
Excelのバージョン対応が必要です。
あと、.NET Framework2.0を別途インストールするなどの手間が必要になる点があります。
モノによってはVBAで作ったほうが簡単にできそうだと思いますが
C#をやっておけば、Excelを絡めないアプリにも今後応用ができるので、本人の仕事の幅が広がるという大きなメリットはあるかもしれません。
VS2003で多少開発しましたが、COM経由で行う場合
あまりメリットが感じられません。
・インテリセンスが不十分
・引数の省略ができないので冗長になる(Office系は数が多いので)
http://support.microsoft.com/kb/305814/ja
・解放に気を付けないと、簡単にゾンビが発生する
http://jeanne.wankuma.com/tips/programing/releasecom.html
など。
VSTOを使うなどしないと.Netぽくは組めないと思います。
ありがとうございます。
今日、試しに簡単なプログラムを書いてみたのですが、Missing.Valueの多さにちょっと閉口しました。インテリセンスで補完できるので楽っちゃ楽なんですが。そのうえ、提示していただいたサンプルコードのように、あらゆるステートメントにTry-Catch-Finallyで括らなければならないとは。。 VSTOは、このあたりは改善されているのでしょうか? VS2008ではDocument Level、Application Level両方の開発がサポートされているので、興味があります。ただ、サンプルコードがほとんど無いのと、Deployがめんどくさそうだという印象があります。
ありがとうございます。
単純に開発効率だけ考えるとVBAのほうが良さそうですね。
>本人の仕事の幅が広がるという大きなメリット
そうなんですよ。.NET開発できるようになっていた方が、キャリア的にいいですよね。確かにVBAだけでも、結構使える業務システムをつくれるのは知っているのですが、一般には下に見られているように思います。