VSTOおよびCAB：Microsoft Wordでの.NETアプリケーション統合

VSTOは、Visual Studio Tools for Officeの略です。 これらのツールにより、すでにハリネズミと簡単にクロスできます-Microsoft Office環境でCLRによって実行される.NETアプリケーションを記述します。 特に、プログラマーは、メインストリームのMicrosoft Office製品ファミリのほぼすべてに対して、プラグイン（プラグイン）および「カスタマイズされた」ドキュメントテンプレートを作成することができます。



この記事では、アプリケーションによってMicrosoft Wordがシェルとして認識されるWindows Formsプロジェクトのインフラストラクチャを提供します。 この記事では、Composite UI Application Blockを使用するいくつかの興味深い点、特にフレームワーク拡張サービスでのWordドメインモデルインフラストラクチャの接続、およびVSTOツールを使用したいくつかの事実と開発機能を明らかにします。

挑戦する

文書を書き、編集者と絶えず作業する数十人の人がいるとします。 Sharepointやその他のポータルは何らかの理由で適切ではないため、独自のビジネスロジックの実装が必要です。 タスクを複雑にしましょう-人々はコンピューターの話題から非常に遠く離れた場所で働いており、Microsoft Officeスイートのみをよく知っています。 さらに複雑です-オフィスは貧弱で、Microsoft Officeには2003バージョンの人々の大部分がいます。 あちこちで、ビッグボスとメインボスは2007年です。 マシン群は多様です-2000番目のWindowsからWindows Vistaまで。

解決策

1つの解決策は、Microsoft Officeのプラグインです。 COM、裸のOffice相互運用機能、または同じ相互運用機能を介して作成できますが、VSTOツールで巧妙にラップされています。 これらの資金を使用します。 ユーザーはWordを起動し、VSTOランタイムは.NETアセンブリを取得し、Microsoft Wordコントロールを何らかの形で補完して、ユーザーがタスクに必要なビジネスロジックを実行できるようにします。

そして、なぜこれすべてですか？

（これは、それがどのように終了するかを見つけるのを待つことができない人です）。 出力では、Visual Studioソリューションをレイアウトします。これにより、Microsoft Wordでアプリケーションプラグインを作成することができます。 その過程で、このソリューションで使用されるほぼすべてを説明します。

仕事に必要なもの

1. Microsoft Word 2003 SP3
2. VSTO 2005 SE
3. VSTO 2005 SEランタイム
4. キャブ
5. Visual Studio 2005または2008

CABを選ぶ理由

単純なWindowsフォームロジックからMicrosoft Wordに関連する機能を明示的に分離するため。 簡単に言えば、プラグインはCABモジュールになり、必要に応じて、このロジックを他のCABアプリケーションに簡単に接続できます。 簡単に言えば、CABを使用するとグルーコードの量が最小限に抑えられます。



ソリューションにCABを含めた理由は2つあります。 1つ目は、このフレームワークの説明をここですでに行ったことです。そして今、本格的な動作例を示したいと思います。 2番目の理由はより一般的です-私はCABが好きです、それは世界とその中の物事を簡単にします:)

VSTOの詳細

一般的に、VSTOはWord用のプラグインを作成できるだけではありません。 これは強力なシステムであり、現在はすでに3番目のバージョンにあります。 VSTOは、自動化およびプログラミングのOfficeベースのソリューションの世界における開発者へのゲートウェイです。 簡単に言えば、.NET開発者はOfficeアプリケーションのドメインモデルにアクセスし、必要なことを何でも行います。



これらのソリューションはすべて、2つのタイプに分類できます。

1. ドキュメントレベルのカスタマイズ
2. アプリケーションレベルのカスタマイズ

これらは独立したレベルです。 最初は、Microsoft Officeアプリケーション用のドキュメントテンプレートを作成します。 Excelテンプレートを取得し、さまざまなユーザーコントロール（ボタン、グリッド）で多様化し、ロジックを追加できます-たとえば、ボタンクリックのイベントで、ユーザーによって収集されたデータがWebサービスを介してサーバーに送信され、そこで処理されます。 このレベルでは、開発者にはアクションペイン（2003バージョン）があり、コントロールを接続できます。さらに、2007バージョンではさらに多くのことができます。



アプリケーションレベルのカスタマイズとは、拡張モジュール（いわゆるアドイン）がMicrosoft Officeアプリケーション環境に接続されることを意味します。 実際、私は最初に彼について話し始めました。 この拡張モジュールは、ビジネスアプリケーションの機関車であり、Microsoft Officeの.NETプラットフォームのすべての機能を接続できます。 第2レベルのソリューションを正確に示します。



VSTOの機能に興味がある人は、多くがmsdnにあります。

擬似タスク

上記のすべてを説明する小さな例を作成しましょう。 ユーザーがMicrosoft Word文書からテキストを選択し、ユーザー要素のウィンドウでこの選択されたテキストを取得できるという要件があります（私は愚かな例を知っていますが、もっと複雑にしたくはありませんが、それほど複雑ではないものを見つけるのは難しいです）。



より詳細に。 ユーザーがMicrosoft Wordを起動します。 起動後、ツールバーの中で、ユーザーはTP-拡張ツールバー（つまり、拡張機能）にアクセスできます。 その上にボタンがあり、クリックすると、「テキストを取得」ボタンと複数行のテキストボックスコントロールが表示されたウィンドウが表示されます。 ユーザーが「テキストを取得」ボタンをクリックすると、ドキュメントで選択されたテキストがテキストボックスにコピーされます。 誰もが幸せです。



例が人生にほとんど役に立たないことは明らかです。 しかし、もし誰かがそれを必要とするなら、作成されているインフラストラクチャはその上に「筋肉」を構築することを非常に簡単にします。

ソリューションを作成する

スタジオにVSTOをインストールした後、新しいソリューションを作成すると、Officeプロジェクトが利用可能になります。







名前には注意してください-同時に名前のルート名前空間になり、プロジェクトのアンロードを通じてハンドルによってのみ名前を変更することが可能になります。



出力は、2つのプロジェクトを含むソリューションです。





実際、WordCABはアドインです。 2つ目-同様に重要なのは、拡張モジュールの展開プロジェクトです。 なぜそれが重要なのですか？



実際、ユーザーのワークステーションに拡張モジュールをインストールするのは非常に時間がかかります。 ライブラリを適切なフォルダーにコピーするだけではありません。 モジュールを正常に動作させるには、レジストリに一連のキーを登録する必要があります。 さらに深く掘り下げると、拡張モジュールがCOMライブラリとしてMicrosoft Officeに接続されていることがわかります。 気にする人は、必要なすべてのレジストリキーを展開プロジェクトで表示できます（右クリック、[表示]、[レジストリ]）。



ThisAddInクラスには、モジュールへのアクセスポイントがあります。

public partial class ThisAddIn

{

private void ThisAddIn_Startup( object sender, System. EventArgs e)

{

new AddInApplication().Run();

}



private void ThisAddIn_Shutdown( object sender, System. EventArgs e)

{

}



#region VSTO generated code



/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

private void InternalStartup()

{

this .Startup += new System.EventHandler(ThisAddIn_Startup);

this .Shutdown += new System.EventHandler(ThisAddIn_Shutdown);

}



#endregion

}



* This source code was highlighted with Source Code Highlighter .

ThisAddIn_Startup



コードをThisAddIn_Startup



ます。 より正確には、CABアプリケーションを起動します。

cabアプリケーションとは何ですか？

これはそのようなクラスです。 起動ポイントRun()



メソッド、およびいくつかのフレームワークインフラストラクチャ-特に、メインユースケース「アプリケーション」（つまり、メイン、ルートWorkItem）へのアクセスと、アプリケーションに追加されたシステムサービスをオーバーライドする機能があります。デフォルトで。 このクラスは基本的な形式で既に実装されており、プログラマはそれをパラメータ化する必要があります-ルートのユースケースのタイプとメインフォームのタイプを指定します：

internal sealed class AddInApplication : WindowsFormsApplication<AddInWorkItem, object >

{

protected override void Start()

{

}

}



* This source code was highlighted with Source Code Highlighter .

メインフォーム（シェルフォーム）のタイプとして、オブジェクトが指定されます。 なんで？ アプリケーションはMicrosoft Wordで実行されるため、メインフォームを作成する必要はありません。 ただし、Microsoft Wordフォームは、従来の機能がないメインフォームです。



プレイが進むにつれて、Microsoft Wordの拡張モジュールのアプリケーションモデルを少し明らかにすることになりました。

Wordアドインアプリケーションモデル

したがって、ユーザーはドキュメントを操作します。 さらに、時間単位で、彼は1つのドキュメントのみで作業できます。 したがって、拡張モジュールには明確なコンテキスト（現在開いているドキュメント）があります。 （ところで、Microsoft Word VSTOモデルでは、このドキュメントはGlobals.ThisAddIn.Application.ActiveDocument



として指定されています）。 ここから（結論）結論（または単純化）-モーダルモードでカスタムビジネス要素を表示するのが理にかなっています。そうしないと、コンテキストが壊れます。 単一のドキュメントに対して開いているコントロールは、このドキュメントがアクティブな間のみ存在する必要があります。



例-ユーザーがドキュメントを開き、カードを開きました（モーダルモードではありません）。 私は別の文書に切り替えましたが、カードは前のものに残っていました-文脈の違反と知覚の完全性。 もちろん、このような動作は制御できます（場合によっては必要な場合もあります）が、コントロールのモダリティと現在のアクティブドキュメントへの緊密なバインドにより、作業が楽になります。

モーダルワークスペース

CABのユーザーコントロールは、特別ないわゆるワークスペースに表示されます。 上記の動作に従って、コントロールをモーダルモードで表示する必要があります。 ネイティブのCAB WindowWorkspaceは少しオーキーで見苦しいため、簡単なコードを作成しました。画面が2つあるため、コードは提供しません。 コードを含むソリューションをダウンロードすることで創造性を楽しむことができます（記事へのリンクは記事の最後にあります）。



モーダルワークスペースの登録は、メインユースケースAddInWorkitem



のInitializeServices()



メソッドで行われます。

Workspaces.Add(( new SimpleModalWorkspace() ), WorkspaceNames.MainWorkspace);



* This source code was highlighted with Source Code Highlighter .

合計：識別子キーWorkspaceNames.MainWorkspace



モーダルワークWorkspaceNames.MainWorkspace



登録されました。 これで、主な使用例へのリンクがあるどこからでもアクセスできます。上記で指定したキーを使用して、 Workspaces



コレクションからIWorkspace



インターフェイスを要求します。 すべてがオレンジのようなものです！ （c）x / f「ターミネーター2」

Microsoft Word Control Factory

それは、Wordツールバーとそのボタンについてです。 VSTOでは、これらはCOMオブジェクト（ Microsoft.Office.Core



名前空間のCommandBar



とCommandBarButton



ラッパーです。 正直に言うと、ひどくバグの多いもの、特にアニメーション。 VSTOフォーラムでショックトローリングをして初めて、すべての微妙さと詳細を理解することができました。



アイデアとは-プログラマとビジネスモジュールの開発者をCOMラッパーで作業する必要性から守ることです。 これを行うために、私たち（つまり私）はMisrosoft WordモデルをCABフレームワークのいわゆる拡張ポイント（UiExtensionSite）のメカニズムに統合します。



拡張サイトのメカニズムは、機能的な接続詞の追加で構成されています。 簡単に言えば、コードは従属要素の関係を視覚化する必要があります。 私たちの場合、これらの関係は次のとおりです。

1. ツールバーは、Microsoft Wordのツールバーの配列に挿入されます
2. ボタンがツールバーのボタンのコレクションに挿入されます
3. ボタンには何も挿入されません（コンボボックスは存在しますが、コンボボックスの場合は考慮されません）。したがって、これはターミナルオブジェクトです。

合計で、互いに従属する3つのエンティティが得られました。

1. IWordCommandBarContainer
   
   
   
   -Microsoft Word IWordCommandBarContainer
   
   
   
   コンテナー
2. IWordCommandBar
   
   
   
   ツールバーのボタンコンテナー
3. IWordButton
   
   
   
   ボタン

ところで、Wordコントロールの定義に加えて、特定のインターフェイスタイプIWordCommandBar



とIWordButton



はCommandBarButton



それぞれ上記のCommandBar



とCommandBarButton



アダプターです。



フレームワークが何を、どこで、そして最も重要なこととして、それを挿入する方法を理解するために、ユーザーコントロール用のアダプターファクトリを登録する必要があります。 この場合、ツールバー（ツールバーのコレクション）とボタン（ツールバーのボタンのコレクション）を挿入できます。 したがって、 IWordCommandBarContainer



およびIWordCommandBarContainer



のアダプターファクトリを登録します。 次に、ユーザーが拡張ロケーションを受け取ると、フレームワークはこの拡張ロケーションに従属要素を追加するためのクラスのインスタンスを探し、それらを目的に使用します-要素を追加します。 さて、気にしないために、これらのインスタンスはファクトリーによって生成されます：

public class CommandBarUIAdapterFactory : IUIElementAdapterFactory

{

public IUIElementAdapter GetAdapter( object uiElement)

{

if ( uiElement is IWordCommandBarContainer ) //

return new CommandBarUIAdapter(( IWordCommandBarContainer )uiElement);

if ( uiElement is IWordCommandBar ) //

return new CommandBarButtonUIAdapter(( IWordCommandBar )uiElement);



throw new ArgumentException( "uiElement" );

}



public bool Supports( object uiElement)

{

return ( uiElement is IWordCommandBarContainer ) || ( uiElement is IWordCommandBar );

}

}



* This source code was highlighted with Source Code Highlighter .

そして、ここにツールバーコレクションの実装があります（新しいものを追加する機能があります！）

internal class BarCollection : IWordCommandBarContainer

{

#region IWordCommandBarContainer Members



public void AddBar(IWordCommandBar bar)

{

CommandBar commandBar = null ;

//todo: ,

try

{

commandBar = Globals.ThisAddIn.Application.CommandBars[bar.Id];

}

catch ( ArgumentException ) { }



if ( commandBar == null )

commandBar = Globals.ThisAddIn.Application.CommandBars.Add(bar.Id, ( object )MsoBarPosition.msoBarTop, _null, true );



commandBar.Visible = true ;

}



private object _null = System.Reflection.Missing.Value;



#endregion

}



* This source code was highlighted with Source Code Highlighter .

ツールバーのボタンも同様です。 ご自由にコードをご覧ください。



ちなみに、ボタンとツールバー自体のファクトリを作成する必要がありました（ IWordUIElementFactory



参照）。 事実は、CABモジュールがIWordCommandBar



およびIWordButton



です。 これらのインターフェイスの特定の種類はVSTO Word-AddInアセンブリにあり、 Microsoft.Office.Core



関連付けられていMicrosoft.Office.Core



。 したがって、モジュール（Officeへのリンクがない）が指定された要素のインスタンスを受け取るために、ファクトリーが作成されます。 彼女はメインのWorkItemに登録します。



ツールバーの工場および拡張サイトの登録：

Services.AddNew<WordUIElementFactory, IWordUIElementFactory>();

IUIElementAdapterFactoryCatalog factoryService = base .Services.Get<IUIElementAdapterFactoryCatalog>();

factoryService.RegisterFactory( new CommandBarUIAdapterFactory());



UIExtensionSites.RegisterSite(UIExtensionSiteNames.WordBarsSite, new BarCollection());



* This source code was highlighted with Source Code Highlighter .

混乱している場合は、ごめんなさい:)私自身は、0.5リットルがなければ理解できないことを理解しています。 （席に着くと、多くが明らかになります。）

CABモジュール

これは通常のビルドです。 ModuleInit



クラスが必要です。 このクラスには、 AddInWorkitem



主な使用例へのリンクがあり、その結果、上で書いたすべての良いものへのアクセスがあります。



CABモジュールのタスクは、主要な前例にロードし、ツールバーを挿入し、その上にボタンを挿入し、ボタンハンドラーを記述することです。



出来上がり：

UIExtensionSite site = _rootWorkItem.UIExtensionSites[UIExtensionSiteNames.WordBarsSite];

IWordCommandBar mainBar = site.Add<IWordCommandBar>(_factory.CreateBar( "AddInToolbar" ));



IWordButton btn = _factory.CreateButton(mainBar, CommandNames.OpenForm, ToolStripItemDisplayStyle.ImageAndText, " " ,

" Custom Control" , Resources.OpenForm, false );



mainBar.AddButton(btn);

btn.Click += new EventHandler<WordButtonClickArgs>(ButtonClick);



* This source code was highlighted with Source Code Highlighter .

ボタンハンドラーは、「テキストを取得」ボタンとテキストフィールドを持つカスタムウィンドウを作成し、それを前述の作業領域に表示します（特別なWindowSmartPartInfo



表示WindowSmartPartInfo



）（思い出すように、キーWorkspaceNames.MainWorkspace



下のユースケースで登録しました）：

private void ButtonClick( object sender, WordButtonClickArgs e)

{

object smartPart = _rootWorkItem.SmartParts.AddNew<SampleSmartPart>();

WindowSmartPartInfo info = new WindowSmartPartInfo();

info.FormStartPosition = FormStartPosition.CenterScreen;

info.MaximizeBox = false ;

info.MinimizeBox = false ;

info.Resizable = false ;

info.Title = "Custom Control" ;

info.ShowInTaskbar = false ;

_rootWorkItem.Workspaces[WorkspaceNames.MainWorkspace].Show(smartPart, info);

}



* This source code was highlighted with Source Code Highlighter .

モジュールのロード

ここで私はフェイントニーを作りました。 通常、モジュールは特別な宣言的なロード形式（いわゆるProfileCatalog）を通じてフレームワークにロードされます。 通常、これは必要なすべてを接続するのに適した方法です。 しかし、ソビエトの厳しい現実を考えると、プログラマがモジュールを接続する非宣言的ロジックを必要とする可能性はゼロではありません。 これを行うために、ロードされたモジュールmodule- IModuleEnumerator



特別な列挙を再定義します。 私はそれを非常に単純にしました-実行可能なアセンブリフォルダーを探し、その中のCustomModule.dllというモジュールを探します。 検索してロードします。 まあ、または見つからない場合はロードしません：

public class CustomModuleEnumerator : IModuleEnumerator

{

#region Constants

private const string ModuleName = "CustomModule.dll" ;

#endregion



#region IModuleEnumerator Members



public IModuleInfo[] EnumerateModules()

{

List <IModuleInfo> result = new List <IModuleInfo>();



string path = GetModulePath(ModuleName);

if ( File .Exists(path) )

result.Add( new ModuleInfo(ModuleName));

return result.ToArray();

}



#endregion



#region Private Methods

private string GetModulePath( string assemblyFile)

{

if ( !Path.IsPathRooted(assemblyFile) )

assemblyFile = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, assemblyFile);



return assemblyFile;

}

#endregion

}



* This source code was highlighted with Source Code Highlighter .

これでこのサービスは非常にシンプルになりましたが、もちろん、必要に応じてはげたものを装備することもできます。 たとえば、データベースからモジュールをロードします:)



このサービスは、CABアプリケーションクラスでリロードする必要があります。

protected override void AddServices()

{

base .AddServices();



RootWorkItem.Services.Remove<IModuleEnumerator>();

RootWorkItem.Services.AddOnDemand<CustomModuleEnumerator, IModuleEnumerator>();

}



* This source code was highlighted with Source Code Highlighter .

医者、疲れた。 どうしたの？

元の擬似例で考えられていたことが判明しました：



MicrosoftのツールバーはMicrosoftのツールバーにあり、アイコンが付いたボタンがハングします。ボタンをクリックすると、ユーザーコントロールがテキストフィールドにポップアップし、ボタンを使用してドキュメントで選択されたテキストを駆動できます:)些細なことですが、オブジェクト間の接続がどれほど重要でないかに注意してください！ 適切に処理されたフレームは、完全なコード保守性を備えていることに注意してください。

注意！ 落とし穴！

セキュリティ

サンプルをコンパイルして実行しても、何も開始されません。 さらに、サードパーティのモジュール（この場合はCustomModule.dll）を起動するための十分な権限がないことを伝えるメッセージが表示されます。 問題は、デフォルトでは、VSTOアプリケーションが（開発モードで！）実行可能アセンブリとそれが依存するすべてのアセンブリにのみ、完全な信頼権を与えることです。 WordCAB.dllへ。 サードパーティのライブラリコードの使用を有効にするには、次の手順を実行します。

C:\Windows\Microsoft.NET\Framework\v2.0.50727>caspol -u -ag All_Code -url "D:\Projects\WordCAB\bin\Debug\*" FullTrust

Microsoft (R) .NET Framework CasPol 2.0.50727.3053

Copyright (c) Microsoft Corporation. All rights reserved.



The operation you are performing will alter security policy.

Are you sure you want to perform this operation? (yes/no)

yes

Added union code group with "-url" membership condition to the User level.

Success







"D:\Projects\WordCAB\bin\Debug\*"



代わりに、アドインを起動するフォルダーを指定する必要があります。 アスタリスクを忘れないでください。

アドインは読み込みを停止しました！

モジュールで未処理の例外が発生すると、Wordが次にロードされるときにそのモジュールの実行がブロックされることがあります。 [ヘルプ]-> [バージョン情報]-> [無効なアイテム]に移動し、拡張機能がリストにあるかどうかを確認します。 ある場合は、そこから削除します。 次のRun-Debugで表示されます。

お手入れ方法

拡張機能の削除はそれほど簡単ではありません。 Microsoft WordツールバーのCOM-AddInsボタンを引き出します。 これを行うには、[ツール]-> [カスタマイズ]-> [ツール]->（ドラッグアンドドロップ）COM-AddInsに移動します。 それをクリックして、拡張機能のチェックを外します。 アンロードされます。 逆にリロードするには、Dawを元に戻します。 別の方法は、コントロールパネルに移動し、プログラムから削除することです。

Word 2007はどうですか？

アドインは、最後のタブのリボンに見事にロードされます。



まだ小さな落とし穴がたくさんあります。 しかし、ここで私はすでに多くのことを書いているので、誰も最後まで読むかどうかはわかりません:)

コードの入手先

github.com/head-thrash/VSTO-CAB

結論

一般に、VSTO、Microsoft Office 2003、.NET Framework 2.0を使用して決定を下すことができます。 この記事では、機能を強化できる基本的なソリューションを紹介しました。 誰がしたい-あなたの健康を使用しています。 質問に答えて、不正確な点がある場合は修正します。 ご清聴ありがとうございました！