A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Component-Levels below:

Component Levels · microsoft/ConcordExtensibilitySamples Wiki · GitHub

In Concord, each component has a numeric value associated with it called the component level. This level tells the Dispatcher a few things:

  1. When remote debugging, will this component load on the target computer or the Visual Studio computer? Components above 100,000 are IDE components and only load in the Visual Studio process.
  2. The order components will be called in when making broadcast requests or sending events. Request calls are made on higher component levels before lower component levels (requests are top down). Event calls are made on lower level components before higher level components (events are bottom up).
  3. The priority of a component when a non-broadcast request call is made. If there are multiple matching implementations for a method call, the Dispatcher will route the call to the highest level component. If the component calls the same method again, the Dispatcher will route the call to the next highest component. Note: Some calls are "callbacks" and like events, these are routed from the bottom up.

There are two general rules to follow when selecting a component level:

  1. Select a level higher (larger number) than dependent components. For example, if the target process had an interpreter, and this interpreter was implemented in managed code, then a debug monitor which is built to add a debugging experience for the interpreter must have a higher component level than the Managed DM.
  2. Follow the advice in the following charts:

IDE Component Levels (Values > 100,000):

Component Component Level AD7 AL 1,000,000,000 Disassembly Provider 9,998,000 Stack Query – Components that wish to query the call stack 9,997,000 Stack Provider 9,996,000 Stack Filter - level where stacks can be filtered and annotated 9,995,000 Breakpoint Manager 9,994,000 IDE Expression Evaluation 9,992,000 Symbol Stack Walkers – stack walkers that need access to symbols 9,991,000 IDE SymbolProvider - Components which provide symbol information to rest of the debugger. The symbol path should not be used below this level. 1,999,000

Target Computer Component Levels (Values < 99,999):

Component Component Level Monitor Symbol Provider – Symbol providers when the symbolic state is built on the target computer (ex: interpreter, dynamically compiled/emitted code) 75,000 Breakpoint Condition Processor - This level is for processing breakpoint conditions such as condition expressions and hit counts. Below this point all physical breakpoint events will be visible regardless of whether or not they have false conditions. 70,000 Monitor Task Provider – This is the level for task data mining in the target process 65,500 Monitor Expression Evaluator 65,000 Monitor Coordination – Components which arbitrate between the various monitors for stepping, breakpoints by native address, stack walk, etc. 60,000 Monitor Stack Walkers 55,000 Custom Debug Monitor – Reserved for third party debug monitors which wish to make use of services provided by the standard debug monitors. 40,500 Runtime Debug Monitor - Provides data inspection and execution control for managed/native/script code 40,000 Base Debug Monitor 10,000 Base Debug Monitor Services – provides utility services to base debug monitors (ex: process creation) as well as pre-debugging services (ex: process enumeration) 1,000

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4