開発者向けのプロジェクトおよびVisual Studioソリューションを構築するためのイベントモデル

この短い記事が役立ちます：

• MS Visual Studioのプロジェクトとソリューションを構築するイベントモデルを理解する。
• VSPackageのdevenv.exeモードのコマンドラインサポートを取得する方法を理解します（元々提供されていなかった場合）。
• MSBuildツールから同様のイベントモデルをエミュレートし、メインプラグインにブロードキャストする方法を理解します。
• 優先サブスクリプションで作業する方法を学びます。
• Visual Studio / MSBuild Toolsでイベントを処理するときに構築コンテキストを取得するためのオプションを見つけます。
• MSBuildプロパティとMSBuildプロパティ関数の評価について学習します。
• 異種システムコンポーネントの抽象化レイヤーでモジュール間相互作用に関する一般情報を取得します。

あらすじ

多くの場合、特定のプロセスの自動化に対処する必要があるため、ソリューションの一部が遅かれ早かれVisual Studioに触れたことは驚くことではありません。



実際、この記事、またはメモは、2年前にC ++の1つのプロジェクトで作業したときの副産物でしかなかった、長く使用されているプラ​​グインの結果です。 ただし、Habrahabrでの私のデビューは、おそらくこれからでしょう。



最近、DevDivの男が同様のニーズ（プラグインが元々解決することを意図していたもの）で私に対処しました。 高度にカスタマイズされた自動化という彼の問題を解決する試みにおいて、ソリューションとVSとMSBuildの相互作用のいくつかの側面を強調することが依然として不可欠であることが明らかになりました。 結局のところ、この資料はもともと入手可能ではなく、まだパブリックドメインにないようです。

警告

始める前に、資料はVisual Studioユーザー向けではなく、開発者向け（Visual Studio環境自体の1つまたは別の拡張機能を提案する）ことに注意してください。 そして、そもそも、誰かが自分の開発のために同様のタスクに直面した場合に、これらのコンポーネントのソリューションと相互作用のいくつかの側面を強調するために呼び出されます。 これは段階的な説明ではありませんが、最低限の原則と作業スキームを理解するのに役立つことを目的としています。 たとえば、devenv.exe、msbuild.exeとの相互作用は、優先サブスクリプションで動作し、上記のリストに示されているすべてのものです。

問題について

私たち両方にとっての最初の必要性は、スタジオのイベントモデル内でSolution-Contextを使用したことであり、現在も使用中です。

もちろん、Visual Studioで作業した人は、プロジェクトレベルでのビルド前/ビルド後のイベントについて知っておく必要があります。 ただし、特にこれらのプロジェクトが数十個ある場合など、ソリューション全体のプロジェクト管理のニーズを完全に満たすわけではありません。これは主にC ++プロジェクトで一般的です。



この問題を解決するにはいくつかの方法があります 。 たとえば、前述のものは、ソリューションから他のすべてが依存するプロジェクトがあるときに、ソリューションからの移行を実行します。

では、なぜMSはIDEの同様のコンテキストを強調していないのですか？

実際、すべてが.sln形式と同じです。これは、プロジェクトファイルやより柔軟でエレガントな有効なxmlドキュメントではなく、ハンターのメモを表します。

互換性？ ただし、おそらく、VS2010で大きな変更が発生した場合でも、それを壊す必要がありました。



ソリューションコンテキストを使用します。 イベントを上位レベルに上げることはできません 1つのコンテキストでmsbuildデータなどを管理する問題を解決する必要があります。ロードされたタイムラインにこれ​​を追加するのを急いでいる人はいません。

MS Visual Studioのプロジェクトおよびソリューションのイベント処理（VS2010、VS2012、VS2013、VS2015）

まず、EnvDTEオプションを見てみましょう。 このタスクの主な焦点はBuildEventsで 、これはOnBuildBegin 、 OnBuildProjConfigBeginなどの基本的なイベントに手頃な価格のサブスクリプションを提供します。 つまり、公開イベントとして実装されます。



ただし、この場合、すべてのDTEリスナーに通知されたときに動作が遅すぎます。 パッケージでできるだけ早く状況を制御する必要があります。



幸いなことに、VSはそのような処理を優先し、それらはすべてそのような処理で実行されます。



一般的に、これは同じオブザーバークラシックであり、特定のサービスのAdviseメソッドを通じて実装されます。 しかし、まず最初に。



まず、 Microsoft.VisualStudio.Shell.Interopに注意を向ける必要があります 。 VSおよびソリューションレベルのその他の基本的な「ビルドイベント」、つまりIVsUpdateSolutionEventsの操作を支援するのは彼です。

• IVsUpdateSolutionEvents
• IVsUpdateSolutionEvents2
• IVsUpdateSolutionEvents3
• IVsUpdateSolutionEvents4

前述のニーズに対応するには、 VS2010まで利用可能な基本的なIVsUpdateSolutionEvents2のみを考慮するだけで十分です。 実際、 IVsUpdateSolutionEvents4はビルドコンテキストの操作に適していますが、VS2012以前でのみ使用できます。



注 ：完全な作業のためには、IVsSolutionEventsも必要になる可能性が最も高いですが、この点はこの記事ではカバーしていません。 それでも誰かが必要な場合は、このレイヤーをサービスするための基本的なテクニックを示します。



そのため、IVsUpdateSolutionEvents2インターフェースの次の基本事項を実装する必要があります。

//         build-action //       int UpdateSolution_Begin(ref int pfCancelUpdate);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 //      .. Cancel / Abort -     int UpdateSolution_Cancel();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 //      . //  ,        ,    Cancel/Abort, ..: // * Begin -> Done // * Begin -> Cancel -> Done int UpdateSolution_Done(int fSucceeded, int fModified, int fCancelCommand);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの方法はすべて、ソリューションコンテキストレベルの実装に主に適しています。

私たちが提供したプロジェクトについて：

 int UpdateProjectCfg_Begin(IVsHierarchy pHierProj, IVsCfg pCfgProj, IVsCfg pCfgSln, uint dwAction, ref int pfCancel); int UpdateProjectCfg_Done(IVsHierarchy pHierProj, IVsCfg pCfgProj, IVsCfg pCfgSln, uint dwAction, int fSuccess, int fCancel);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、構成をビルドする必要があるすべてのユーザーに対して呼び出されます。 pHierProjの引数に注意してください。これは、制御がどこから来ても参照できる柔軟な方法です。



パッケージの基本的な実装は、VSがIVsUpdateSolutionEventsで動作する準備ができていることを意味しません。 上記のように、リスナー（このインターフェイスを実装する）を登録する必要があります。

 public sealed class vsSolutionBuildEventPackage: Package, IVsSolutionEvents, IVsUpdateSolutionEvents2 { ... public int UpdateSolution_Begin(ref int pfCancelUpdate) { return VSConstants.S_OK; } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Adviseメソッドでこれを行う必要があるため、IVsUpdateSolutionEvents2にはAdviseUpdateSolutionEventsが提供されます。



登録例：

 /// http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivssolutionbuildmanager2.aspx private IVsSolutionBuildManager2 sbm; /// IVsSolutionBuildManager2 / IVsSolutionBuildManager /// http://msdn.microsoft.com/en-us/library/bb141335.aspx private uint _sbmCookie; ... sbm = (IVsSolutionBuildManager2)ServiceProvider.GlobalProvider.GetService(typeof(SVsSolutionBuildManager)); sbm.AdviseUpdateSolutionEvents(this, out _sbmCookie);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SVsSolutionBuildManagerサービスには他の方法でアクセスできることに注意してください。 便利なものを使用してください。



上の例のsbmは、GCから保護するためのクラスの一部である必要があります。



これで最前線で聴く準備ができました。 私たちが一番最初ではないことを理解することも重要ですが、これは必要ありません。

コマンドラインモードをサポート

誰かがプラグインでdevenv.exe（より正確には、devenv.com、コンソールモードでの処理を扱っているので）で作業する必要があったことは驚くことではありません。 ただし、 VSPackagesには、このモードで少なくとも何らかの形で機能する機能はありません。 したがって、コンソールでソリューションをビルドしようとすると、プラグインは単に非アクティブのままになります。

 devenv "D:\App1\App1.sln" /Rebuild Debug
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この質問はQ / Aギャラリーで最初に私に尋ねられ、率直に言って、私は以前にそのようなニーズや欲求がありませんでした（msbuild.exeで作業でき、さらに自動化サーバーには引き続き提供されるためそのすべてのない限られた環境）。



しかし、私たちが見るように、私たちそれぞれのニーズは異なります。特にこれがVSの一部である場合、障害をサポートする必要があります。



後で、CIサーバーのサポートのフレームワークで、成功したソリューションで同様の問題に対処しました。 つまり、VSPackageでプロジェクトとソリューションのイベントモデル全体を処理できます 。 誰が主張する：

 "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv" "D:\App1.sln" /Rebuild Debug "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv" "D:\App1.sln" verbosity:diagnostic /Build Release
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[？]

しかし...

• ソリューションには、イベントをブロードキャストするためのアドインラッパーの使用が含まれます。
• コマンドラインモードを提供するのはアドインです。または、VSはこのモードで動作する準備ができています。
• これらはまったく同じモデルであるため、VSPackageについては、古き良きIVsUpdateSolutionEvents2を実装し、ある時点で登録するだけの簡単な方法はありません。

 void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、メインライブラリにリダイレクトします。例：

 ... public int UpdateSolution_Begin(ref int pfCancelUpdate) { return library.Event.onPre(ref pfCancelUpdate); } public int UpdateProjectCfg_Begin(IVsHierarchy pHierProj, IVsCfg pCfgProj, IVsCfg pCfgSln, uint dwAction, ref int pfCancel) { return library.Event.onProjectPre(pHierProj, pCfgProj, pCfgSln, dwAction, ref pfCancel); } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、誰もが長い間知っているように、アドインはVisual Studio 2013で非推奨になりました 。 つまり、このようなトリックはVS2010、VS2012、VS2013で機能します。 計画されているVS2015では、このようなゲームは機能しません。



これについてはすでにMS Connect Issue＃1075033で書いていますが、 興味のある人に別れを告げることができます。 VS2015は既にRCにあり、タスクは単純に閉じられています。



どうぞ

MSBuildツールから同様のイベントモデルをエミュレートする

そもそも、MSBuildツールは最も強力なツールであり、上記の問題を誰も知らないはずです。 ソリューションレベルの$（構成）と$（プラットフォーム）を簡単に処理できます。ターゲットなどで作業できます。ただし、ソリューションは同じである必要があり、VS IDEとCI /特別ビルドサーバーでのビルドの作業の違いに気付かないはずです。 したがって、msbuildツールのフレームワークで上記のイベントを使用する機会を検討します。



DTE2コンテキストも、イベントの登録サービスも利用できません。VSと通信するものはありませんが、他に何を待っていましたか 。 はい、もちろん、たとえば、 GetActiveObjectを使用して同じDTE2コンテキストを取得できます。

 HRESULT GetActiveObject( _In_ REFCLSID rclsid, _Reserved_ void *pvReserved, _Out_ IUnknown **ppunk );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[？]

つまり たとえば次のように：

 (EnvDTE80.DTE2)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.10.0");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これらはすべて、IDEスタジオの実行中のインスタンスがある場合にのみ機能します。これは、CIなどの限られた環境では不可能です。



したがって、開発したトランスレータをロガーとして登録することにより、msbuild.exeの制御を取得することを提案します。 これを行うには、 Microsoft.Build.Frameworkと連携する必要があります 。



実際、基礎となるIEventSourceは、すべての基本的なニーズを提供できます。

 public class EventManager: Logger { ... public override void Initialize(IEventSource evt) { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、知っておく必要がある機能がいくつかあります。

• IEventSource.BuildStartedは動作しません（以下の注を参照） すぐに機能するか、処理する必要があるプロジェクトのデータを取得するために、待機する必要があります。 VSでは-ログインコンテキストはIVsSolutionEventsで処理されます。
• したがって、PREイベントにIEventSource.ProjectStartedを使用することは可能です。また、プロジェクトレベルのイベントに使用する必要があります。

実際には、ハンドラー-ProjectStartedEventHandlerは引数としてProjectStartedEventArgsも送信します。たとえば、次のように、 .slnファイルを追跡して処理することができます。

 evt.ProjectStarted += (object sender, ProjectStartedEventArgs e) { e.ProjectFile; // should be .sln ! ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションは、処理のために.slnを受け取るまで待機している可能性があり、プロジェクトファイルを通過する前でなければなりません。



これに対する苦痛は始まったばかりです、なぜなら 本格的な作業には、たとえば、新しいmsbuildプロパティの評価、ビルドの中断など、msbuildエンジンにアクセスするためのプロジェクトの読み込みなど、.slnデータが必要になります。



残念ながら、.slnファイルを操作するには、通常のものは表示されません。より正確には、好みに合わせて選択します。

• または、古いものを使用します 廃止されたMicrosoft.Build.BuildEngine.Projectとしてマークされ ます 。 同時に、Microsoft.Build.BuildEngineを使用していない場合は、これが追加されることを考慮してください。 プロジェクトの不要な参照。
• または、内部メソッド-Microsoft.Buildでリフレクションを使用します。 BuildEngine.Shared 、たとえば：
  
  -> void ParseProject（string firstLine）
  
  -> void ParseFirstProjectLine（string firstLine、ProjectInSolution proj）
  
  -> crackProjectLine-> PROJECTNAME + RELATIVEPATH
• または、同じParseProjectの例に従って、独自の小さなパーサーを作成します。

選択肢は豊富ではありませんが、.slnは長い間理解できない形で...



注：



上記の「IEventSource.BuildStartedは動作しません」というフレーズは完全に真実ではありません...必要なデータを取得するには実際には早すぎますが、両刃の剣です。 ここでは、同様の実装で発生する可能性のある問題について説明しました。 したがって、マルチスレッドアセンブリ/ m：2+ （使用する2つ以上の同時プロセス）の場合、これは非常に好ましくない結果を引き起こし、最初のイベントの処理前にmsbuildコレクターによってすべてのターゲットが決定されたCSCエラー（CS2001）の特殊なケース、実行時の対応する変更は、新しい変更に影響しなくなりました。 ただし、このカバレッジは、建設プロセスなどを妨げるタスクの一部にすぎません。



したがって、最も柔軟な方法をお勧めします。必要なすべてのデータを事前に準備して、IEventSource.BuildStartedを使用します。 この方法については、 この資料で説明しましたが、MITの簡単なslnパーサーを見つけるか、メインライブラリの一部としてパーサーを見ることができます。



どうぞ

プロジェクトでは、msbuild（MSBuild Property Functions）などのプロパティと機能を評価する必要がありますが、 それらがない場合はどうでしょうか...



これが必要な場合は、これを使用するには、msbuildエンジンを準備し、最初に開始する必要があります。 分離された環境で作業するため、msbuild.exeから開始されたプロパティを転送することも必要です。



.NET 4.0を使用している場合、これを手動で行う必要があります。 Configuration、Platform、SolutionDirなどを定義する必要があります。 ハンドラー用。 ただし、.NET 4.5プラットフォームの場合、 ProjectStartedEventArgs.GlobalPropertiesは使用可能です。



サンドボックスが完全に初期化された後、最終的にプロジェクトイベントを処理できます。 ただし、msbuildを使用し、ターゲットを使用します。 したがって、 TargetStartedにサブスクライブする必要があります。



ブロードキャストの場合、受信したTargetNameのPreBuildEventとPostBuildEventに満足します。次に例を示します。

 protected void onTargetStarted(object sender, TargetStartedEventArgs e) { switch(e.TargetName) { case "PreBuildEvent": { ... return; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ここでは、すべてがスムーズではありません。 実際には、現在TargetStartedEventArgsで処理されているプロジェクトを参照することはできませんが、 ProjectInstanceIdを取得できるBuildEventContextを取得できます。 ProjectIdを覚えておいてから、BuildEventContextが利用可能な場所であればどこでも参照できます。たとえば、次のようになります。

 projects[e.ProjectId] = new Project() { Name = properties["ProjectName"], File = e.ProjectFile, Properties = properties };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、隔離された環境でVSPackageのイベントモデルを完全にブロードキャストし、そのまま動作することができます。

 "C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe" "app.sln" /l:"<>.dll" /m:12 /t:Rebuild /p:Configuration=<cfg> /p:Platform=<platform>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビルドのコンテキストを取得する

実際、強調したい問題や機能がいくつかあります。 しかし、一般的に、これは私たちのプロジェクトにとってあまりにも具体的であり、あなたの場合、そのようなものはまったく必要ないかもしれませんので、スキップすることができます 。



プラグインはビルドイベントで機能するため、すべてのプラグインが開始されたビルドのタイプを取得するために必要なものを推測するのは難しくありません。 しかし、VSの場合、これはそれほど単純ではありません 。



優先サブスクリプションに取り組んでいるということは既にご存知であり、次のようなものは使用できません。

 _buildEvents.OnBuildBegin += (vsBuildScope Scope, vsBuildAction Action) => { buildType = (BuildType)Action; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

手遅れだから。



ただし、質問と回答で書いたように、古いバージョンとの互換性を計画していない場合にのみ、 IVsUpdateSolutionEvents4を使用してみてください。



当時、選択はVS IDEからのコマンドをインターセプトすることでした。例：

 _cmdEvents.BeforeExecute += (string guid, int id, object customIn, object customOut, ref bool cancelDefault) => { if(GuidList.VSStd97CmdID == guid || GuidList.VSStd2KCmdID == guid) { _c.updateContext((BuildType)id); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はそれがあまり好きではありません。IVsUpdateSolutionEvents4を使用する方が良いですが、バージョン互換性と優先処理を維持するための唯一の有効なオプションです。 そして、誰も他の決定を喜ばせようとしません。

モジュール間相互作用

さて、ここでは、実際、目立ったものは何もありません。すべては平凡ですが、記事の枠組みの中には小さな説明があります。



既にお気づきのように、コンポーネントは用途が広く、イベント処理モデルも異なります。 プラグインを例として使用すると、次のようになります。





表示されているもののシートはここにあります 。



仕事のハイライト：

• すべての必要なコンポーネントが実装できるように、プロジェクトレベルで共通のパブリックインターフェイスを選択します。 これはShell.Interopが行うことであり、EnvDTEなども同様です。
• プログラムのメインコアの場所を決定します。 統合データ処理を担当する人。
• ライブラリローダーはどこかで定義します。 外部プロバイダーなどのようにすることもできます。
• 各コンポーネントは、それぞれ独立して、使用される場所への接続方法を決定し、一般に、必要に応じて、処理されたデータの転送と変換のみを処理する必要があります。 （外部ライブラリの操作方法の例を示す必要はないと思います。私のソースまたは一般的にどこでも見つけることができますが、これは記事の範囲外です）。

ここには重要なポイントがあります。 私たちのプラグインはもともとそのようなボリュームで使用されることを意図していなかったため、システムのコアはVSPackageにあります。



はい、個別のコンポーネントに分割しない方が便利ですが、なぜ悪いのですか？ 実際、上の図の私のVSPackageは、EnvDTEとEnvDTE80（さらにエキゾチックな接続を持っている）に強く依存している必要があります。 これはすべて、継続的インテグレーションサーバーでは可能です。 まず、標準のmsbuildツールなどが提供されます。 つまり、軽量の自己完結型コンポーネントと透過的なインターフェイスを忘れないでください。 私は分離に急いでいません このすべての時間、そして今のところそれは価値がありません、結局のところ、それはもともとVSPackageソリューションでした。

MSBuildプロパティとMSBuildプロパティ関数へのアクセスと評価

最後に考慮したいのは、プロパティの評価です。 一般に、プロパティへのアクセスは、次のようないくつかの方法で発生します。

• Microsoft.Build.BuildEngineから
• またはMicrosoft.Build.Evaluationを使用

他の人と同様。



最も柔軟なオプションは、Microsoft.Build.Evaluationを使用することです。 msbuildエンジンを使用して見積もりを取得し、プロジェクトを操作する最も簡単な方法は次のとおりです。

 public virtual string evaluate(string unevaluated, string projectName = null) { ... lock(_lock) { try { ... project.SetProperty(container, Scripts.Tokens.characters(_wrapProperty(ref unevaluated))); return project.GetProperty(container).EvaluatedValue; } finally { project.RemoveProperty(project.GetProperty(container)); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、既に理解できたように、ソリューションコンテキストでは、プロジェクトのデータを操作する方法を決定する必要があります。 私は個人的に追加を実装しました。 構文拡張 。



つまり、最初にアナライザーのツールを使用して解析する必要があります。次に、元のmsbuildエンジンが既に対応している準備済みのデータを送信します。

おわりに

実際、これはHabrahabrに関する最初のメモです。 最後ではないことを願っています-_-。



この資料では、実際のソリューションの例を使用して、実行する必要があるもの、存在するソリューションオプション、VSでビルドのイベントモデルを操作するときに発生する問題と機能、および関連するコンポーネント、devenvおよびMSBuildツールを理解するための重要なポイントについて説明します 。



ソースで実装の詳細を確認したり、追加したりすることができます。 質問がある場合は、コメントの情報を後で。



エラーと不正確さについて書き、それらがあれば修正します... それはマークダウンなしで非常に不便でした。

更新しました。

コメンテーターに次のことを伝えたいと思っています。

この資料では 、これらの要素を使用する方法、および説明されている状況で要素を使用する際の問題を解決する方法について説明しています。 VS開発者が既存のソリューションに精通し、開発で得た知識を適用できるようにするために- なんとか、彼自身のもの... 残念ながら、それらは失敗しました 。



エンドユーザー向けにこれらの開発を使用して問題を解決する方法、 および一般に、どのような方法でも提示されなかった、または詳細に説明されなかった抽象的な問題を解決しようとする方法を専ら議論 します-私たちは、主題分野に精通せずに解決するために解決します。



形成された聴衆の排他性を考慮して、この記事でコメントを続けるために、私はそれが適切であるとは思いません。

ただし 、このトピックについてまだサポートが必要な場合は、空き時間があるので、おそらくアドバイスできます。 G +の連絡先。

upd2。 プロジェクトのターゲットとマップ。

さまざまな状況のためにIVsUpdateSolutionEvents2 / IVsUpdateSolutionEventsを使用したいが使用できない場合は、この資料をサポートする一方で、わずかなボーナスがあります。



「ソリューションレベル」のイベントの問題（簡単にするために、このような定式化を引き続き参照します）を私に連絡した人と議論し、示されたインターフェイスを実装する代わりにターゲットを操作する可能性も考えました。 彼は明らかに取り除くための余分なリンクでした。 まあ、いくつかの同等を達成してみてください。



さらに、そのようなものが好きな場合-MSBuild：ソリューションビルドの拡張 （ただし、VSIDEではなくmsbuild.exeからビルドする場合にのみ同様のオプションが機能します）

• VS IDEは、ビルド時に.slnファイルをまったく考慮しません。 彼女は、忙しい環境からEnvDTEなどで最終目標を設定します。
• .slnファイルはmsbuild.exeによってのみ考慮されます-つまり ビルドする前に、.metaproj（デフォルトでメモリ内）が自動的に生成されます。これには、すべてのプロジェクトの共通のターゲット（存在する場合）を含め、ビルドの対象と時期が含まれます。 例：

 ... <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportAfter\*" Condition="'$(ImportByWildcardBeforeSolution)' != 'false' and exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportAfter')" /> <Import Project="D:\tmp\p\after.Sample.sln.targets" Condition="exists('D:\tmp\p\after.Sample.sln.targets')" /> <Target Name="Build" /> <Target Name="Rebuild" /> <Target Name="Clean" /> <Target Name="Publish" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• この場合、.metaprojはVS IDEとは見なされません。 彼はすでに独自の目標を設定しています。
• また、何がいつ何が起こるのかもまったくわかりません。 プロジェクトは、事前に定義されたVS目標を使用して個別に構築されます。

つまり VS IDEからのビルド操作で一般的なターゲットを操作するには、プロジェクトファイル（VSを変更/拡張せずに）を使用できますが、いくつかの制限があります。



それぞれ、一般的なソリューションの状況、またはエンドユーザーがソリューションで持つプロジェクトについてまったくわからない場合を考慮します。



このような制限として、プロジェクトマップを検討できます（少なくとも2つのオプションがありますが、これだけが多少安定していることが示されているため、ボーナスはそれだけです）。

• gist.github.com/3F/a77129e3978841241927

 ... <Target Name="_Build" BeforeTargets="Build" DependsOnTargets="ProjectsMap"> <CallTarget Targets="_BuildPRE" Condition="$(ScopeDetectFirst)" /> <CallTarget Targets="_BuildPOST" Condition="$(ScopeDetectLast)" /> </Target> <Target Name="_BuildPRE"> <!-- ... --> </Target> <Target Name="_BuildPOST"> <!-- ... --> </Target> ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、同様のマップを形成するとき、どのような場合にいつそれを行うべきかがわかります（ProjectsMap、それぞれScopeDetectFirstおよびScopeDetectLastの検出器で形成されます） 、すなわち：

• たとえば、次のように、すべてのプロジェクトに共通の.targetsファイルを自動的に追加します（たとえば、 NuGetイベントなどを使用）。

   <Import Project="..\<SolutionFile>.targets" />
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• さらに、プロジェクトマップの形式の制限により、次の実行（クリーン、ビルド、リビルドなどの目標）を達成できます。
• • 「最初のプロジェクトの前」
  • 「最後のプロジェクトの終了後」

すべてまたはほとんどの場合に安全です（アセンブリの順序を変更したり、ソリューションから一部のプロジェクトを削除したり、すべてが正常に機能するはずです）。 しかし！このオプションには、初期化段階や新しいプロジェクトを追加するときのインポートサービスという形で多くの不都合があります。これは不便ですが、IVsUpdateSolutionEventsのオプションです。



さらに、ヘッダーでプロジェクトのアンロード（IDEによりユーザーが一時的にソリューションからプロジェクトをアンロードできる場合）の潜在的な問題に注意しましたが、ほとんどの場合、これは有効なオプションです。このアンロードは一時的なものであり、エラーは何らかの形で有効であるため、許可できます（さらに、必要に応じて問題を解決できます）。



利便性に関しては、議論の余地があります... VSPackageは製品の追加リンクでもあり、オプションとして、そのようなものを検討するかもしれません...

しかし 信頼性に関しては、VSPackageでIVsUpdateSolutionEventsを実装することを選択します！ なぜなら このような最小値は標準化されているため、異なるバージョンで予測可能です。

upd3。

• マルチスレッドおよびアセンブリプロセスに介入する機能に合わせて調整されたmsbuildイベントに関する小さなメモ、CSCエラー（CS2001）エラーの例。上を見る
• 宴会の継続。本格的なMSBuildプラグインの開発に関する詳細な部分。ただし、明らかな理由により、ここでは公開しませんでした。ここでCodeProjectを読んでください。あなたが学びます：
  
  
  • 事前に何も知られていないプロジェクトや決定に対応する能力+柔軟な相互作用。
  • MSBuild Tool , ..
• , EnvDTE.CommandEvents , . SO .

関連リンク

• VSPackage — visualstudiogallery.msdn.microsoft.com/0d1dbfd7-ed8a-40af-ae39-281bfeca2334
• Github: github.com/3F/vsSolutionBuildEvent
• Visual Studio: Solution-wide pre-build event? — stackoverflow.com/q/2295454
• Map of projects — gist.github.com/3F/a77129e3978841241927
• Current type of the build action from Visual Studio — Microsoft.VisualStudio.Shell.Interop — stackoverflow.com/a/27081247
• IVsUpdateSolutionEvents2 — msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivsupdatesolutionevents2.aspx
• IVsUpdateSolutionEvents4 — msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivsupdatesolutionevents4.aspx
• Microsoft.VisualStudio.Shell.Interop — msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.Shell.Interop.aspx
• Microsoft.Build.Evaluation msdn.microsoft.com/en-us/library/microsoft.build.evaluation
• EnvDTE msdn.microsoft.com/en-us/library/envdte.aspx
• MSBuild: Extending the solution build — sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
• VSPackages — msdn.microsoft.com/en-us/library/bb166424.aspx
• MS Connect Issue #1075033 — connect.microsoft.com/VisualStudio/Feedback/Details/1075033
• MSBuild Plugin: www.codeproject.com/Articles/1092265/MSBuild-Plugin-The-managing-of-most-processes-at-r