このスレッドが古いことは承知していますが、私はドミノ API と、ドミノ COM API を介した一般的なノーツ LotusScript オブジェクトについて多くの作業を行ってきました。
Domino API の問題は、COM を介したメモリ管理がひどいことであり (C# や VB などで API を使用している場合)、メモリ リークが発生し、最終的に API 全体と Notes クライアントがクラッシュします (クライアントを開いていないと、API がクラッシュした後にコンピューターを再起動するか、「nsd -kill」を呼び出さない限りクライアントを起動できません)。楽しい。
P/Invoke を介して C# 内で Notes C API を使用すると、API が恐ろしいメモリ リークやクラッシュを引き起こさないように、メモリ リソースをより適切に管理できることがわかりました。P/Invoke を使用して、notes.dll から Notes C API にアクセスする部分的なラッパーを C# で作成しました。私の使用は、Domino 環境内での作業とは関係ありませんが、Notes アセンブリを使用して NSF ファイルにアクセスし、C# 環境内で DXL 情報を抽出するために使用します。明らかに、notes.dll と C API にアクセスするには、Notes クライアントをインストールする必要があります。しかし、ノーツ C API の私の C# ラッパーはうまく機能し、ノーツ クライアントのインストール時に提供されるドミノ COM API よりも安定しています。
Notes C API から C# で実装した (必要なだけの) クラスは次のとおりです。
NotesSession (NotesRuntime として) NotesDatabase NotesNote NotesItem NotesDXLExporter NotesNoteCollection
C API から C# への変換を処理するためのその他の暫定的なクラス、列挙型、および構造体。
これまでに実装したクラスは、Notes C API で必要としていた目的を果たしてきました。それらは確実に拡張できますが、API 全体を C# P/Invoke ラッパー内にカプセル化しようとはしませんでした。また、Notes 文書内に格納される可能性のある OLE 埋め込みオブジェクトを処理し、Windows IStorage オブジェクトを使用してそれらの OLE オブジェクトから格納されたデータを取得するためのハンドラも作成する必要がありました。
注: 後でいくつかのサンプルを提供できます (独自の理由により、名前空間の名前を変更し、コードを一般化する必要があります)。 IBM/Lotus によって (ダウンロード可能な NSF として) 提供されます。C 定義とクラス参照を使用して、それらを C# P/Invoke 呼び出しに変換し、より使いやすい C# クラスにラップすることができました。これにより、LotusScript クラス呼び出しのように動作しますが、C# 内では、実装されたクラスがメモリを管理および破棄します。 C# プログラムから何十万ものドキュメントにアクセスした後でも、全体がクラッシュすることはありません。:)