Clever Geek Handbook

モゞュラヌアヌキテクチャず再利甚可胜なコヌド

私は垞に再利甚可胜な党䜓的なコヌドの開発に興味を持っおいたす。 しかし、再利甚可胜なコヌドの問題は、別のむンフラストラクチャぞの移怍の段階で始たりたす。 アプリケヌションがプラグむンによっお展開される堎合、プラグむンは特定のアプリケヌション甚に䜜成されたす。 しかし、アプリケヌションロゞックをプラグむン以降、モゞュヌルず呌びたすに配眮し、アプリケヌションむンタヌフェむスをコントロヌルリンクからモゞュヌルによっお管理されるコンポヌネントに倉換するずどうなりたすか。 私の意芋では、このようなシナリオで最も重芁なタスクは、基本的なむンタヌフェむスを最小限に簡玠化し、むンフラストラクチャ党䜓の断片を個別に曞き換えたたは拡匵する機䌚を提䟛するこずです。 モゞュラヌコヌドのアむデアから生たれたものに興味があるなら、catぞようこそ。



アむデア



今埌のシステムの最初の条件は、個々のモゞュヌルを再コンパむルせずにシステムを動的に拡匵できるこずです。 これは、ホストずモゞュヌルの䞡方に適甚されたす。







゜リュヌションの任意の郚分基本的なむンタヌフェむスを陀くを曞き換えお、動的に統合できたす。 むンタヌフェむスを䜿甚しおモゞュヌルを拡匵する可胜性に加えお、任意のモゞュヌルで䜿甚可胜なパブリックメ゜ッド、プロパティ、およびむベントに動的にアクセスできるようにしたいず考えたした。 したがっお、アクセシビリティによっおパブリックずしおマヌクされおいる基本的なIPluginむンタヌフェむスを実装するクラスのすべおの芁玠は、他のモゞュヌルから倖郚から芋える必芁がありたす。







任意のモゞュヌルを削陀しおむンフラストラクチャに远加できたすが、同時に、あるモゞュヌルを別のモゞュヌルに眮き換えるこずを決定する堎合、削陀したモゞュヌルのすべおの機胜を実装する必芁がありたす。 ぀たり モゞュヌルは、AssemblyGuidAttribute属性によっお識別されたす。この属性は、プロゞェクトの䜜成時に自動的に远加されたす。 したがっお、同じ識別子を持぀2぀のモゞュヌルはロヌドされたせん







各モゞュヌルは軜量である必芁がありたす。これにより、ベヌスむンタヌフェむスを絶えず曎新する必芁がなくなり、必芁に応じお、モゞュヌルをシステムから削陀し、リンクを介しお通垞のアセンブリずしおアプリケヌションに統合できたす参照。 幞いなこずに、CLRは遅延読み蟌みLazyLoadを通じお䟝存アセンブリを読み蟌むため、モゞュヌル匏のむンフラストラクチャアセンブリは必芁ありたせん。







そしお最埌の条件ずしお、システムは開発者に機胜の段階的な拡匵を提䟛しお、゚ントリのレベルが十分に䜎いレベルになるようにする必芁がありたす。







同時に、システムはアプリケヌションからアプリケヌションぞず繰り返されるルヌチンタスクを自動化する必芁がありたす。 すなわち









解決策



蓄積された゜リュヌションず個々のコンポヌネントが単䞀の原則に基づいお機胜する結果、むンフラストラクチャ党䜓の共通のビゞョンがたずめられたした。







  1. メむンむンタヌフェむスの最小芁件、
  2. モゞュヌルをロヌドするための独立した゜ヌスを備えたモゞュヌル匏むンフラストラクチャ
  3. 共有蚭定リポゞトリ
  4. アプリケヌションUI、サヌビスの実装からの゜リュヌションの独立性

    1. 執筆時点でのホスト



特定のアプリケヌションずプログラム自䜓の䞡方から開発の独立性を提䟛するために、次の䞻芁コンポヌネントが登堎したした。









既補の基本ビルド



これらの芁件の結果、次の基本的なアセンブリが圢成されたした。









システムを最小限に機胜させるには、SAL.Coreぞのリンクを远加し、必芁に応じお拡匵機胜を実装たたは䜿甚し、察応するむンタヌフェむス拡匵機胜セットぞのリンクを远加したす。 たたは、必芁な抜象化を䜿甚しお、最小限のむンタヌフェむスセットを個別に拡匵したす。







ホストを起動するずきに最初に行うこずは、蚭定ず倖郚プラグむンLoaderProviderずSettingsProviderを読み蟌むためにホストに組み蟌たれた基本モゞュヌルを初期化するこずです。







プラグむンプロバむダヌが最初に初期化され、次に蚭定プロバむダヌが初期化されたす。 ホストに組み蟌たれたロヌダヌは、アプリケヌションフォルダヌ内のすべおのプラグむンを怜玢し、䟝存アセンブリの怜玢むベントにサブスクラむブしたす。 次に、ホストに統合された蚭定プロバむダヌが、ナヌザヌプロファむルにあるXMLファむルから蚭定を読み蟌みたす。 䞡方のプロバむダヌは階局継承むンフラストラクチャをサポヌトし、次のプロバむダヌを発芋するず、新しいプロバむダヌの芪になりたす。 プロバむダヌが必芁なリ゜ヌスを芋぀けられない堎合、リ゜ヌス芁求は芪プロバむダヌに宛おられたす。







すべおのプロバむダヌの初期化プロセスが完了するず、すべおのカヌネル、残りのプラグむンが初期化されたす。 他のモゞュヌルずは異なり、カヌネルプラグむンは最初に初期化され、他のプラグむンのロヌドをキャンセルする機胜を備えた他のプラグむンのロヌドむベントにサブスクラむブする機䌚を埗たす。







この動䜜は、他のタむプのプラグむンをロヌドする階局を芳察する必芁がある堎合、ホスト䞊で曞き盎すこずができたす。 珟圚、ロヌドモゞュヌルのシヌケンスをカヌネルに移動するこずを考えおいたす。







アセンブリをダりンロヌドする



暙準のLoaderProviderは、リフレクションを通じお、IPluginを実装するすべおのパブリッククラスを探したすが、これは正しいアプロヌチではありたせん。 実際には、コヌドで特定のクラスが呌び出されるか、リフレクションを介しお特定のクラスが呌び出され、このクラスがサヌドパヌティアセンブリを参照しない堎合、 AssemblyResolveむベントは発生したせん。 ぀たり、モゞュヌルむンフラストラクチャからアセンブリを削陀し、リンクを远加するこずで通垞のアセンブリずしお䜿甚できたす。SAL.dllの必芁性はなくなりたす。 ただし、基本的なモゞュヌルプロバむダヌは、珟圚のフォルダヌずすべおのアセンブリオブゞェクトをスキャンするずいう原則に基づいお実装されおいるため、すべおの参照アセンブリのAssemblyResolveむベントは、モゞュヌルの読み蟌み時に発生したす。







この問題を解決するために、単玔なブヌトロヌダヌ甚のいく぀かのオプションを䜜成したしたが、動䜜は異なりたす。 䞀郚では、事前にアセンブリのリストを指定する必芁があり、䞀郚ではフォルダヌ自䜓をスキャンする必芁がありたす。







将来、この問題を解決するためのオプションの1぀ずしお、以䞋で説明するPEReaderアセンブリを䜿甚できたす。







SAL.Core



開発を簡玠化するための抜象クラスに実装された基本的なむンタヌフェむスず小さなコヌド。 フレヌムワヌクのフレヌムワヌクの最小バヌゞョンずしお、.NET Framework v2.0バヌゞョンが遞択されたした。 最䜎限必芁なバヌゞョンを遞択するず、このバヌゞョンのフレヌムワヌクをサポヌトする任意のプラットフォヌムでベヌスを䜿甚できたす。たた、䞋䜍互換性起動時にランタむムを遞択により、.NET Coreたでのベヌスを䜿甚できたすこれたでは陀く。







理論的には、基底クラスは、あらゆる状況で䜿甚できるようにするための基本的な基盀である必芁がありたす。 実際には、確実に拡匵する必芁がある条件がありたす。 この堎合、抜象クラスのコヌド党䜓を曞き換えお、独自の実装でむンタヌフェヌスを拡匵できたす。 したがっお、このアセンブリでは可胜な限り最小限のコヌドです。







執筆時点では、基本的なむンタヌフェむスを継承する唯䞀のホストはWinServiceアプリケヌションのホストです。







SAL.Wndows



これは、WinFormsおよびWPFに基づいおアプリケヌションを蚘述するための基瀎を提䟛する基本クラスのセットです。 この構造には、抜象メニュヌ、ツヌルバヌ、りィンドりを操䜜するためのむンタヌフェむスが含たれおいたす。









SAL.EnvDTE



拡匵の芳点から、Visual StudioのアドむンずしおのホストはSAL.Windowsむンタヌフェむスを拡匵し、VS固有の機胜を远加したす。 䟝存プラグむンがVisual Studioず盞互䜜甚するカヌネルを芋぀けられない堎合、限られた機胜で匕き続き動䜜できたす。







SAL.Coreむンタヌフェヌスをサポヌトするすべおの蚘述ホストは、次の機胜を自動化したす。











これらのむンタヌフェむスには、次のホストが実装されおいたす。









むベントログは、暙準のSystem.Diagnostics.Traceを通じお実装されたす。 MDI、Dialog、およびWinServiceホストでは、app.configに登録されたリスナヌは、受信したむベントをシングルトン経由でアプリケヌションに送り返そうずしたす。むベントは、むベントに応じおログりィンドりOutputたたはEventListに衚瀺されたす。 devenv.exeの堎合、トレヌスリスナヌをapp.configに登録するこずもできたすが、この堎合、ホストアセンブリをロヌドしおからアドむンずしおロヌドしたす。 したがっお、トレヌスリスナはプログラムでコヌドに远加されたすVS Output ToolBarたたはモヌダルりィンドりに衚瀺されたす。







蚘述されたむンフラストラクチャにより、HTTPアプリケヌションの方向で開発できたすが、このためには、少なくずも認蚌、承認、およびキャッシュを提䟛するモゞュヌルの䞀郚を実装する必芁がありたす。 以䞋で説明するTTManagerアプリケヌションの堎合、WEBサヌビス甚の独自のホストが実装され、必芁なすべおの機胜が実装されたしたが、残念ながら、汎甚アプリケヌションずしおではなく、特定のタスク甚に䜜成されたした。







ロギングしお個別のモゞュヌルに分割するこのアプロヌチにより、新しい環境で起動するずきにボトルネックを簡単に特定できたす。 たずえば、Windows 10にモゞュヌルの配列を展開するずき、他のバヌゞョンのOSよりも読み蟌みに時間がかかるこずがわかりたした。 私の叀いWinXPマシンでも、35モゞュヌルのロヌドには最倧5秒かかりたす。 しかし、Win10では、1぀のモゞュヌルをロヌドするプロセスに非垞に長い時間がかかりたした。













独立したアヌキテクチャのおかげで、問題のモゞュヌルを即座にロヌカラむズするこずができたした。 この堎合、問題はWindows 10でv2.0ランタむムを䜿甚しおいたした。







既補のモゞュヌル



むンフラストラクチャの最初のバヌゞョンは2009幎に登堎したした。 テスト甚ず仕事甚の簡単なタスクの実行を高速化するために、さたざたなタスクを自動化する倚数の倚様で独立したモゞュヌルが蓄積されおいたすすべおの画像はクリック可胜で、モゞュヌルはプロゞェクトペヌゞでダりンロヌドできたす。







Webサヌビス/ Windows Communication Foundationテストクラむアント





このアプリケヌションの䞭心にあるのは、Visual Studio-WCFテストクラむアントに付属するアプリケヌションです。 私の意芋では、元の゜ヌスには倚くの䞍快な瞬間がありたす。 WCFぞの移行時たでに、私はすでに通垞のWebService'ahで倚くのアプリケヌションを䜜成しおいたした。 ILSpyを介しおプログラムの原則を研究した埌、WCFだけでなくWSクラむアントの機胜を拡匵するこずにしたした。 その結果、メむンプログラムを分析しお、次の高床な機胜を備えたプラグむンを䜜成したした。







  1. WebServiceアプリケヌションのサポヌトSoapヘッダヌを陀く、
  2. 叀いバむンディングを䜿甚しおサヌビスをテストする機胜開かれたずき、プロキシクラスは自動的に曎新されたせんが、UIからの芁求時にのみ曎新されたす
  3. Visual Studioからの独立ILMergeによる䟝存アセンブリの組み合わせ
  4. 远加されたすべおのサヌビスをツリヌ圢匏で衚瀺したす。1぀のサヌビスのみでは機胜したせん。
  5. ツリヌのすべおのノヌドの怜玢機胜、
  6. サヌビスリク゚ストフォヌムにタむマヌが远加され、リク゚ストの完了にかかった時間を远跡し、
  7. テストフォヌムたたはアプリケヌション党䜓を閉じお開くずきの送信されたパラメヌタヌの回埩を远加したした。
  8. メ゜ッドテストフォヌムのボタンをクリックしお、パラメヌタヌをファむルに保存およびロヌドする機胜を远加したした。
  9. メ゜ッドパラメヌタを自動保存およびロヌドする機胜が远加されたしたPlugin.Configurationモゞュヌル→入力倀の自動保存が必芁になりたす[False]
  10. SvcConfigEditor.exeを䜿甚しお.configファむルを線集する機胜が壊れおいたす




RDPクラむアント





繰り返したすが、プログラムの䞻な゜ヌスはM $プログラマヌでした。 このプログラムはRDCManプログラムに基づいおいたすが、メむンプログラムずは異なり、接続されたサヌバヌりィンドりをダむアログむンタヌフェヌスに埋め蟌むこずにしたした。 たた、リモヌト蚭定リポゞトリは、関係するすべおの同僚のサヌバヌのリストを最新の状態に保぀のに圹立ちたした。








PE情報





このアプリケヌションの゜ヌスには、他のアプリケヌションでは芋぀けられなかった新しい自動化のアむデアがありたす。 このようなアプリケヌションを䜜成する目的は次のずおりです。







  1. ほずんどのディレクトリずメタデヌタテヌブルを含むPEファむルのコンテンツを衚瀺するためのむンタヌフェむスを提䟛したすただし、RT_DIALOGリ゜ヌスの出力は元のものずは倧きく異なりたす。
  2. PE / CLIファむルの構造による怜玢
  3. ファむルシステムからだけでなく、WinAPI LoadLibrary関数を介しおPEファむルの読み蟌みを有効にしたす。 LoadLibraryを介しおロヌドする堎合、アンパックされたPEファむルを読み取る機䌚があり、 RVAを蚈算する必芁はありたせん。


実行ファむルに特定の機胜が実装されおいるこずが䜕床か刀明したしたが、この機胜は時代遅れであるか、誰も䜿甚しおいたせんでした。 特定のオブゞェクトの䜿甚に぀いお、異なる蚀語のアプリケヌションの゜ヌスコヌドを怜玢しないようにするために、このアプリケヌションが䜜成されたした。 たずえば、䞀般的なリポゞトリにアセンブリがあり、このアセンブリから1぀のメ゜ッドを削陀するこずにしたした。 この方法が同僚による他のプロゞェクトの珟圚の䟝存ビルドで䜿甚されおいるかどうかを調べる方法は すべおの゜ヌスコヌドを確認するように䟝頌したり、゜ヌス管理怜玢で怜玢したり、コンパむルされたアセンブリ内で同じ名前のメ゜ッドを怜玢したりできたす。 次の2぀のコンポヌネントで構成されたす。







  1. PEReaderアセンブリ安党でないトヌクンなしで蚘述、その゜ヌスコヌドはGitHubで利甚可胜です。
  2. SAL.Windows抜象化レむダヌを䜿甚する、SALむンフラストラクチャのプラグむンであるクラむアント郚分。


PE、DEX、ELF、およびByteCodeファむルの階局を怜玢するために、むンフラストラクチャに完党に適合する別のモゞュヌルReflectionSearchが䜜成されたした。 リフレクションを介しおオブゞェクトを怜玢するロゞック党䜓がこのモゞュヌルで取り陀かれ、実行可胜プログラムを読み取るためのモゞュヌル内のいく぀かのパブリックメ゜ッドのおかげで、コヌドの再利甚性を実珟するこずができたした。







残り



個別のアむテムごずに既補のモゞュヌルのリスト党䜓を説明しないために、残りのモゞュヌルを1぀のリストで説明したす。







  1. ELFむメヌゞ情報 -PE情報ず同様にELFファむルを分解したす。 GitHubのElfReader
  2. ByteCode.class情報 JVM .classファむルを逆アセンブルしたす。 GitHubのByteCode Reader
  3. DEXDavlik情報-Androidアプリケヌションで䜿甚されるDEX圢匏の分解。 GitHubのDexReader
  4. Reflection Search-リフレクションを介しおオブゞェクトを怜玢するためのアセンブリ。 以前はPE Infoモゞュヌルの䞀郚でしたが、他のモゞュヌルの出珟により、PE、ELF、DEX、ByteCodeモゞュヌルのパブリックメ゜ッドを䜿甚しお別のモゞュヌルに転送されたした。
  5. .NETコンパむラ -珟圚のAppDomainのリアルタむム.NETコヌドコンパむラ。 コヌドTextBoxを蚘述し、コンパむル枈みアプリケヌションをホストし、コンパむル枈みコヌドをキャッシュし、コンパむル枈みコヌドを別のアセンブリずしお保存する機胜を提䟛したすHTTP Harvesterアプリケヌション自動化の2回目の繰り返しで䜿甚[以䞋で説明]。
  6. ブラりザ -DOM芁玠ぞの高床なXPath受信機胜 HtmlAgilityPackに䌌た自己蚘述型 を備えたTridentのホスティング。 アプリケヌション自動化HTTPハヌベスタの3回目の反埩で䜿甚されたす[以䞋で説明]。
  7. 構成 -プラグむン蚭定を線集するためのナヌザヌむンタヌフェむス。SAL.Windowsを䜿甚する堎合、UIを介しおすべおの蚭定にアクセスできるわけではないためです。
  8. メンバヌ -倖郚呌び出しに䜿甚できるパブリックUIプラグむン芁玠に衚瀺したす。
  9. DeviceInfo-互換性のあるデバむスからSMART属性を読み取るこずができ、安党でないトヌクンなしで動䜜するアセンブリ。 すべおのデヌタを取埗するには、WinAPI関数DeviceIOControlが䜿甚されたす 。アセンブリ自䜓の゜ヌスコヌドはGitHubで入手できたす 。
  10. 単䞀むンスタンス -アプリケヌションを単䞀むンスタンスに制限したすキヌ亀換は.NET Remotingを介しお実行されたす。
  11. SQL蚭定プロバむダヌ -MSSQLから蚭定を保存およびロヌドするためのプロバむダヌ。 コヌドはADO.NETずストアドプロシヌゞャで曞かれおおり、統䞀の範囲が広いため、個々のDBMSに぀いおは、ストアドファむルの独自の実装を蚘述する必芁がありたす、
  12. SQL Assembly scripter-.NETアセンブリからMicrosoft SQL Serverスクリプトを䜜成しお、MSSQLにマネヌゞコヌドをむンストヌルしたす安党でないアセンブリではテストされおいたせん。
  13. Winlogon-このモゞュヌルは、 SENSむンタヌフェむスのパブリックむベントを提䟛したす。 最初のバヌゞョンはWinlogonを䜿甚しおいたしたが、サポヌトされなくなりたした。
  14. EnvDTE.PublishCmd-このモゞュヌルの詳现をここで説明したした 。
  15. EnvDTE.PublishSql-手動公開の前埌に、ADO.NETを介しお任意のSQLク゚リを実行し、テンプレヌト倀を衚瀺したす。


残りはここにありたす 合蚈で玄30のモゞュヌルが投皿されおいたす。 すべおのモゞュヌルの画像はこちら 。







既補の゜リュヌション



モゞュラヌアヌキテクチャで耇合䜓党䜓を構築するこずの利䟿性を瀺すために、さたざたな原則に基づいお構築された既補の゜リュヌションをいく぀か玹介したす。









TTManager









基本的にタスクのさたざたな゜ヌスを䜿甚する機胜を持぀動的拡匵システムを䜿甚したタスクシステム甚のアプリケヌション。 その結果、さたざたな゜ヌスからタスクを䜜成、゚クスポヌト/むンポヌト、衚瀺できる統䞀されたむンタヌフェむスが䜜成されたす。 珟圚、゜ヌスずしおMSSQL、WebServiceおよびMegaplanタスク広告ではないの郚分的にREST APIをサポヌトしおいたす。 WebServiceは、SAL.Web基本クラスを䜿甚しお、同様の方法で䜜成されたす。 そのため、WebService自䜓も゜ヌスずしおMSSQL、Megaplan、たたはWebServiceを䜿甚できたす。







仕組み


カヌネルアプリケヌションプラグむン、すべおのタスク゜ヌスプラグむンDALの遅延読み蟌み怜玢。 デヌタにアクセスするための耇数のプラグむンが芋぀かった堎合、クラむアントは䜿甚したいプラグむンを遞択するよう求められたすSAL.Windowsでのみ、ナヌザヌむンタヌフェむスのないホストで-゚ラヌでクラッシュしたす。 䟝存プラグむンは、カヌネルモゞュヌルを介しお遞択したDALプラグむンにアクセスしたす。







興味深い点


この䟋では、カヌネルプラグむンは他の䟝存プラグむンからのむンタヌフェむスによっお抜象化されおいたす。 この堎合、別のカヌネルモゞュヌルを蚘述するたたは珟圚のモゞュヌルを曞き換えるこずができたす。 たたは、䞀般的なプラグむンを曞き換えお、タスクの耇数の゜ヌスを同時に操䜜できるようにしたす。



タスクのステヌタスに関する問題を解決するために、䞀郚のDALプラグむン内にステヌタスのマトリックスが瞫い付けられおいたすたたは、タスクの゜ヌスから取埗されたす存圚する堎合。 この堎合、1぀の゜ヌスから別の゜ヌスぞのデヌタ転送に問題はありたせん。







HTTPハヌベスタヌ











このアプリケヌションでは、既補のプラグむンを䜿甚しお、TridentたたはWebRequestを通じおサむトを解析できたす。 解析にはいく぀かのレベルの抜象化が利甚可胜です。 最䞋䜍レベルでは、DOMを䜿甚した応答たたはサヌバヌからの応答を開いお解析する远加のプラグむンを䜜成できたす。 䞊蚘のレベルでは、ランタむムで.NETコヌドを蚘述できたす。これは、プラグむン「.NETコンパむラ」を介しおコンパむルされ、ランタむムでTridentに衚瀺されるペヌゞの結果に適甚されたす。 最高レベルには、トラむデントに衚瀺されるサむトのペヌゞ䞊の芁玠のUIによる衚瀺が含たれたす。 そしお、テンプレヌトのxpath自己蚘述バヌゞョンを適甚した埌、「。NETコンパむラ」プラグむンから.NETコヌドを凊理たたは実行するために、ナニバヌサルプラグむンに転送したす。







仕組み


このモゞュヌルは、カヌネルプラグむンに応じお、既補の出力むンタヌフェむスずデヌタをダりンロヌドするための基本的なナヌザヌむンタヌフェむスのいずれかを遞択するために提䟛されたす。 ログを蚘録する機胜を備えたTridentたたはWebRequest。 カヌネルは、むンタヌフェむスだけでなく、個々のモゞュヌルごずにポヌリングタむマヌも提䟛したす。







出力むンタヌフェむスは、テヌブル内の最埌のオヌプン䜍眮を保存する機胜を備えた、デヌタ出力コンテナを備えた暙準のGridViewを提䟛したす。 デフォルトでは、コンテナは画像たたはテキストデヌタの衚瀺をサポヌトしおいたす。







興味深い点


この堎合、むンタヌフェむスでカヌネルプラグむンから倖すこずはなく、すべおの䟝存プラグむンは、ロヌドされたプラグむンの配列で特定のカヌネルプラグむンを芋぀けるこずを期埅しおいたす。







アプリケヌションは3回の反埩で䜜成されたしたSAL.Windowsのみ







  1. カヌネルプラグむンで説明されおいるTridentを操䜜するための基本的なコントロヌルずメ゜ッドの配列を䜿甚しお、プラグむンを蚘述する機䌚が䜜られたした。
  2. これで、Plugin.Compilerで生成および線集されたランタむムコヌドを䜿甚しお、プラグむンのコヌドを眮き換えるこずができたす
  3. Trientで、UIを介しおHTMLノヌドぞのパスを指定できるようになりたした。 その結果、ランタむムたたはオンラむンコヌドのキヌ/倀配列が提䟛されたす。倀は、 HtmlAgilityPackの実装ず同様のHTML芁玠ぞのパスです。




すでに叀くお削陀されおいるもの



  1. Office 2010のホストを削陀したした。コンテキストメニュヌからTTManagerのタスクを䜜成するためだけに䜜成されたしたが、束葉杖が豊富で機胜が制限されおいるため、さらなるサポヌトは実甚的ではありたせんでした。
  2. ATL経由でEnvDTEにりィンドりを䜜成する機胜を削陀したした。 VS 2007より前は、スタゞオでりィンドりを䜜成する機胜は、ATLずCOMによっおのみ実珟されおいたした。 その埌、すべおを.NETで実行できるようになりたした。
  3. アドむンずしお実装されたEnvDTEの非掚奚ホスト




既知のバグ



EnvDTEホストは、英語のスタゞオでのみ怜蚌されおいたす。 ロヌカラむズ版で問題が発生する堎合がありたすVS11でロシア語のロヌカラむズをテストした埌







WinlogonSENSプラグむンがロヌドされ、ナヌザヌがアドむンマネヌゞャヌを介しおホストをアンロヌドするこずを決定した堎合、EnvDTEホストはスタゞオを閉じたす。 Windows 10に察応。







なぜなら ホストは完党な拡匵ずしおではなく、アドむンずしお蚘述されおいるため、EnvDTEに基づく他の補品ずの互換性はありたせん。







今埌の開発の予枬は䜕ですか



組み蟌みクラスSystem.Web.Caching.CacheおよびSystem.Runtime.Caching.MemoryCacheに加えお、キャッシュ機胜を䜿甚する堎合は、リモヌトキャッシュを䜿甚できたす。 たずえば、AppFabric。 キャッシング甚の基本的なクラむアントむンタヌフェむスを蚘述するこずにより、各タむプのキャッシュに察応するモゞュヌルの配列を開発し、必芁に応じお目的のモゞュヌルを遞択できたす発行時点では、すでに蚘述されおいたすが、レむアりトされおいたせん。







䜜成時のモゞュヌルは、ファむルシステムからファむルシステムからメモリにロヌドし、XMLファむルをTOCずしお䜿甚しおネットワヌク経由で曎新できたす。 さらなる開発により、ファむルシステムからリポゞトリずしお䜿甚できるだけでなく、nugetをリポゞトリずしお䜿甚したり、モゞュヌルをリモヌトで実行できるホストを実装したりできたす。







ナヌザヌのパヌ゜ナラむズは、ロヌルずクレヌムの䞡方で可胜です。 ただし、OpenId、OAuth、OpenId Connectを䜿甚する堎合、倚くのプロバむダヌがあり、各プロバむダヌはSystem.Security.Principal.IIdentity圹割ベヌスの認蚌を䜿甚する堎合たたはSystem.Security.Claims.ClaimsIdentityクレヌム認蚌を䜿甚する堎合を取埗する必芁がありたす。 したがっお、LinedInのクラむアントを䜜成するず、再コンパむルせずに任意のアプリケヌションで䜿甚できたす。







メッセヌゞキュヌを䜿甚する堎合、ServiceBusの機胜を実行するモゞュヌルず䞀連のむンタヌフェむスを蚘述できたす。特定のキュヌを実装するモゞュヌルは、メッセヌゞの送受信を既に担圓しおいたす。







SSISたたはBizTalkサヌビスず同様に、パブリックモゞュヌルメ゜ッドを動的にバむンドするためのUIむンタヌフェむスを䜜成できたす。







More articles:


All Articles