NDepend

Improve your .NET code quality with NDepend

Business Complexity vs. Implementation Complexity

It is good software design practice to make sure that methods can be entirely viewed in the code editor that typically shows 30 to 45 lines at a time. The root of this principle is easy to grasp: scrolling up and down over a too large method impedes code readability.

Refactoring a too large method or a too large class implies to create several code elements smaller in terms of number of textual lines. But ultimately the code behavior didn’t change. In other words the business complexity remained the same but the refactor session reduced the implementation complexity (at least we hope so).

Software complexity is a subjective measure relative to the human cognition capabilities. Something is complex when it requires effort to be understood by a human. Software complexity is a 2 dimensional measure. To understand a piece of code one must understand both:

What this piece of code is doing at runtime, the behavior of the code, this is the business complexity.
How the actual implementation solves the business needs at runtime, this is the implementation complexity.

The whole point of software design, SOLID principles, code maintainability, patterns… is to avoid adding implementation complexity to the business complexity. But from where implementation complexity comes from? There are 5 main sources of implementation complexity:

Too Large Code

We already mentioned this one. It is easy to limit implementation complexity by abiding by simple code rules that check thresholds on code metrics like methods number of lines of code and method complexity, or classes with too many methods. The Single Responsibility Principle (SRP) also contribute to smaller implementations: less responsibilities for a class necessarily means less code.

Lack of Abstractions

An abstraction such as an abstract method, an interface or even a delegate, is the minimum required knowledged to invoke an implementation at runtime without knowing it at design time. In other words an abstraction hides implementation detail. Abstraction represents a great weapon to reduce the implementation complexity because polymorphism can replace quantity of if/else/switch/case. Concretely code like that:

void DrawShape(Shape shape) {
   switch(shape.Kind) {
      case ShapeKind.Circle: DrawCircle(shape); break;
      case ShapeKind.Rectangle: DrawRectangle(shape); break;
   }
}

void DrawShape(Shape shape) {

switch(shape.Kind) {

case ShapeKind.Circle: DrawCircle(shape); break;

case ShapeKind.Rectangle: DrawRectangle(shape); break;

}

Can be replaced with code like that:

void DrawShape(IShape shape) {
   shape.Draw();
}

void DrawShape(IShape shape) {

shape.Draw();

}

Abstraction also reduces implementation complexity because it frees the developer mind of implementation details.

The S in SOLID is the SRP (mentioned above) and is not related to abstraction. But the OLID principles are all about using abstractions wisely:

The Open-Close Principle (OCP) explains that an abstraction must remain stable with time, and thus must be designed carefully.
The Liskov Substitution Principle (LSP) explains that the quantity of knowledge presented by an abstraction must be enough to use it in all situations.
The Interface Segregation Principle (ISP) explains that an interface must be cohesive: methods that consume the interface typically use most of its members.
The Dependency Inversion Principle (DIP) explains that most dependencies in a system must point toward abstractions and not toward implementations.

How do we check for good usage of abstractions? There is no magic stick like thresholds to limit too large code elements. However the Abstractness vs. Instability graph and metrics and the Level metric are a good start to identify code areas that need more abstractions. They are both described in this post about Dependency Inversion Principle.

State Mutability at Runtime

A common source of implementation complexity is mutable states. The human brain is not properly wired to anticipate what is really happening at runtime in a program. While reviewing a class, it is hard to imagine how many instances will simultaneously exists at runtime and how the states of each these instances will evolve over time. This is actually THE major source of problems when dealing with a multi-threaded program.

If a class is immutable (if the states of all its instances objects don’t change at runtime once the constructor is called) its runtime behavior immediately becomes much easier to grasp and as a bonus, one doesn’t need to synchronize access to immutable objects. See here a post explaining in-depth immutable class.

A method is a pure function if it produces outputs from its inputs without modifying any state. Like immutable classes, pure functions are also a good mean to reduce implementation complexity.

Some code rules exists to enforce state mutability like Structure should be Immutable or Fields should be marked as ReadOnly when possible. Being immutable for a class or pure for a method is such an essential property that dedicated C# keywords for that would be welcome, like readonly for fields. Here is a proposal for C# support of the immutable keyword. By now some ImmutableAttribute or PureAttribute can be used to tag such elements and some code rule can check for Types tagged with ImmutableAttribute must be immutable or Methods tagged with PureAttribute must be pure

Over Coupling

When trying to re-engineer/understand/refactor a large piece of code (I mean something made of dozens of classes like a big namespaces or an assembly), the difficulty is directly proportional to the amount of coupling between considered code elements. Both dependency graphs below shows dependencies between 36 classes: but the left contains 64 edges and the right one contains 133 edges: which one would you prefer to deal with?

One key strategy to control coupling is to layer components and make sure that there is no dependency cycles. This can be checked on namespaces for example with the code rule Avoid namespaces dependency cycles. Using abstractions is also a good way to limit over coupling. If an interface has N implementations then relying only on one interface is virtually like depending on the N underlying classes.

Lack of Unit Tests

Software testing is a large topic I won’t cover here. But one key benefit of writing tests (apart enforcing business rules and detecting regressions early) is to ensure that the code is testable. Being testable for code means less coupling, more abstractions and overall simple code. Ultimately if the code is easily testable we can safely assume that its implementation complexity is kept low. Here also many code rules like Code should be tested can help enforce high testability.

One Measure for All

There are more sources of implementation complexity but those 5 ones are certainly the bigger culprits. To reduce this unnecessary complexity one must be able to measure it. But how to unify too large code, bad design, poorly tested code and more in a single metric?

As we saw most of these aspects can be enforced with code rules. A code rule produces issues and for each issue the code rule can estimate the cost to fix an issue and the annual cost to let an issue unfixed. A famous analogy with the financial field says that:

The estimated cost to fix code smells is the Technical-Debt: a measure of the implementation complexity.
The estimated annual cost to let code smells unfixed is the Annual Interest of the Debt: a measure of the business operation cost induced by poorly written and poorly tested code.

These estimations can be expressed in developer-time and ultimately in money cost which can be used by management to take the right decisions.

Answers to arguments against 100% coverage

I’ve been enthusiast about 100% coverage for more than a decade. The large code base of NDepend we are working on will reach soon 90% overall coverage. Most classes tested are being 100% covered.

In the heatmap below small rectangles are methods. Grapes of rectangles are classes namespaces and assemblies. By importing code coverage in this heat-map we can see at a glance that most classes are green: they are 100% covered. This heatmap also shows in red and orange areas with room for improvements. Areas in gray represent untestable code tagged with System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute.

Not everybody agrees with 100% coverage and the same points against used to popup again and again so I take a chance to address them one by one.

I don’t waste my time writing tests to cover trivial code

Often the example of trivial code proposed is property getter and setter. Indeed writing tests to cover such get/set methods doesn’t bring any value. But such trivial code is meant to be used by real code, isn’t it?

For example suppose we have a Contact class with a property like Contact.FirstName, this properties is meant to be used. The module that builds an invoice and that prints the contact name on it certainly uses it. And if the build invoice module is well tested, Contact.FirstName must get called implicitly at test time.

So if some trivial code is not covered by tests, the idea is not to write dumb tests to cover it, the idea is to question yourself why the trivial code is not already implicitly covered by tests that exercise real code. And certainly you’ll find room for improvements in the tests suite in charge of testing the real code, that depends upon the trivial uncovered code. A future post will go through benefit of 100% coverage but as this point suggests, one key benefit is that a hole in 100% covered code is always an indicator of something interesting to improve.

90% coverage is enough

Often teams get satisfied with 90% or 95% coverage. For the scale of a large code base such score is outstanding. But for the scale of a class or a component 100% must be the goal.

The key is testability. We all have experienced some easy to test code and some hard to test code. The maintainability is hard to measure but the testability is something concrete. And good testability leads to good maintainability. In other words if a component can be fully tested seamlessly it means this component will be easy to maintain.

On the other hand, in the real world we often end up with a component that contains a small portion that is hard to test. And we get satisfied with 90 or 95% coverage. But this is sweeping dust under the carpet: this small portion of code is not testable because it is not well designed and as a consequence it is bug-prone. Hence we end up not testing the most sensitive part of the code that likely concentrates most of the problems!

If after having wrote a test suite you end up with a few if/else blocks that are hard to test, do a favor to yourself: refactor to reach seamless full testability.

What matters is what gets asserted in tests, not the amount of coverage

Suppose you have a 1.000 lines of code linear method: it only contains a linear list of processing with no if/then/switch/case… Suppose you have a test with zero assertions invoking this method. You end up with 1.000 lines of code 100% covered but not tested at all.

This fictitious situation often proposed as 100% coverage counter argument doesn’t reflect the reality. In the real world if one works hard to get a complex class 100% covered, I cannot imagine that the tests don’t contain an healthy amount of assertions. No matter if TDD Test First Design approach is used or if tests get written at the same time as code tested : writing tests leads to think more and to think better. One doesn’t write a test without having a few points in mind to assert.

But there is more. Why only tests should contain assertions? The code itself is well suited to contain assertions. For more than a decade we stuff the NDepend code base with assertions. Everything that can be asserted gets asserted. We end up with more than 26K assertions. A good half of those comes from non-nullable references. C#8 nullable reference will relieve all those assertions. But will remain all other assertions about non-empty strings, special string formats, non-zero counter, IDictionary.ContainsKey(), non-zero denominator of a division, !object.IsDisposed, loop invariant…. And all those assertions are checked at test time and fail tests when violated. Ultimately most tests end up with a 1/10 ratio between the number of assertions in test checked, and the number of assertions in code checked.

We still rely on the good old System.Diagnostics.Debug.Assert() but this is an implementation detail. Any assertion library can be used from the code itself (including a custom one, or the Code.Contracts library that would have deserved more love). The only thing that matters is to tune assertions to fail a test upon violation, typically by sending an exception. A related topic is if those assertions must be checked or not at production time. This is another interesting debate with pros and cons.

Some code just cannot be tested

Indeed there are some API call that just cannot be tested like calls to System.Windows.MessageBox. Such calls need to be mocked. This way the code is well splitted between 100% covered code and code tagged with System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute. Dependency Injection can be used to inject untestable implementation in tested code.

Again testability is a central characteristic of code. Partitioning code according to its testability makes sense.

However, there are situations where such untestable API tend to prolifer. Then your choice is to either mock everything or accept to live with non-tested code. But being in this situation is the sign that such API is immature because not test-prone. Thus something radical must be done about that: get rid of it, contribute to it (if OSS), fork it…

UI Code is untestable

Since testing code has become a popular practice, UI code has always been treated as an awkward case: there are some frameworks dedicated to UI testing but such practice remains tedious and increases test maintenance. This is not satisfying.

As for any code, UI code must be written with testability in mind. UI code can contain UI logic but should not contain business logic. For example the UI class shouldn’t contain the implementation of a IsContactReadOnly() method (business logic) but can call such method declared in a non-UI testable class, to decide if a Contact First Name textbox should be readonly or editable (UI logic). Ideally UI code looks like an empty shell as much as possible.

Nowadays web development outperforms desktop developments. The backend spits HTML CSS and Javascript textual content. This content seen as data represents some easily testable material. However when possible, it is preferable to test the IsContactReadOnly() business logic directly from the backend code, than to test it indirectly, for example by checking if an HTML textbox is readonly or editable. Hopefully modern web platforms like ASP.NET Core propose testing strategies.

Desktop UI is a different beast to test and there is no magic. To test our UI specific code we’ve invested in an architecture where the UI code can be piloted, both from the main-form code and from tests. Such architecture relies massively on some mediator classes: any UI portion can pilot any other UI portion through these mediators. These mediators are used at production runtime, and tests supersede them to pilot the UI at testime. Tests dedicated to UI testing have few assertions, but such tests are not useless: they execute all the assertions stuffed in our UI code. At the end of the day some of our UI classes remain not fully covered but closed to. Small portions left untested doesn’t contain error-prone code but untestable UI peculiarities, like complex designer code or some DPI related code that can only be tested manually. The experience proved that this approach saved us from regression bugs many times.

100% coverage is a sensitive topic. In the NDepend team we are 100% coverage driven. In a future post we’ll detail the benefits of being 100% coverage driven. But I wanted to detail first the non-trivial reasons that make 100% coverage worth in most situations.

Static Analysis and Dependency Injection

For quite some years now, we (the NDepend team) got some demand about resolving Dependency Injection, see this page on our User Voices. Lately we’ve been considering such support carefully but came to the conclusion that it’d be awkward. On the other hand we have alway been prioritizing features development based on user feedback and need. So our conclusions are not definitive yet. I write this post to not only expose our point of view, but eventually trigger more productive discussions.

Static Analysis

First let’s underline that NDepend is a static analyzer. It gathers 100% of its data from the code itself, and also parses more data like code coverage. Static analysis is in opposition with dynamic analysis that gathers data from runtime execution.

Static analysis deals with classes, methods and design measures like lines of code or complexity. It is design-time analysis.
Dynamic analysis deals with objects and runtime measures like performance or memory consumption. It is run-time analysis

Dependency Injection (DI)

Recently I explained the basis of Dependency Injection (DI) and how it relates to DIP in the post SOLID Design: The Dependency Inversion Principle (DIP). DI is all about depending on interfaces instead of depending on classes. Here is simple DI sample code, ClientCode() depends on IDbConnection and not on SqlConnection. The power of DI is that now ClientCode() can run on other RDMS than SQL Server, like Oracle or SQLLite. ClientCode() can now also be unit-tested seamlessly by mocking the interface IDbConnection.

static void DICode() {
   IDbConnection dbConnection = new SqlConnection();
   ClientCode(dbConnection);
}
static void ClientCode(IDbConnection dbConnection) { // Client code has no idea what's behind IDbConnection
   dbConnection.Open();
}

static void DICode() {

IDbConnection dbConnection = new SqlConnection();

ClientCode(dbConnection);

}

static void ClientCode(IDbConnection dbConnection) { // Client code has no idea what's behind IDbConnection

dbConnection.Open();

}

Stable Dependency Principle (SDP)

DI is an application of the Stable Dependency Principle (SDP), which is not part of the SOLID principles, but is much related with the Dependency Inversion Principle (DIP).

SDP states: The dependency should be in the direction of the stability. Stability is a measure of the likeliness of change. The more likely it will change, the less it is stable.

The Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) articles explain how interfaces must be carefully thought out. As a result an interface is a stable code element, that is less likely to change than the the classes that implement it. Following the SDP, it is better design to rely on interfaces than to rely on concrete classes.

The Users need: supporting DI through Static Analysis

In this context, users want NDepend to be able to parse DI code like that.

   // Autofac DI
   var builder = new ContainerBuilder();
   builder.RegisterInstance(new SqlConnection()).As<IDbConnection>();
   
   // UnityContainer DI
   IUnityContainer container = new UnityContainer();
   container.RegisterType<IDbConnection, SqlConnection>();
   
   // NInject DI
   public class Bindings : NinjectModule {
      public override void Load() {
         Bind<IDbConnection>().To<SqlConnection>();
      }
   }

// Autofac DI

var builder = new ContainerBuilder();

builder.RegisterInstance(new SqlConnection()).As<IDbConnection>();

// UnityContainer DI

IUnityContainer container = new UnityContainer();

container.RegisterType<IDbConnection, SqlConnection>();

// NInject DI

public class Bindings : NinjectModule {

public override void Load() {

Bind<IDbConnection>().To<SqlConnection>();

}

Concretely users want NDepend to bind all calls to an IDbConnection member with a call to the corresponding SqlConnection member . For example a dependency toward SqlConnection.Open() should be created for any method calling IDbConnection.Open().

But why would this be useful? Here is a user feedback:

We have layered architecture: Foundation, Feature, Project. Following current NDepend report, everything follows right dependencies. Project depends on Feature and Foundation. Feature depends on Foundation. However due to some of DI registrations, we have complex dependencies (…) there is dependency from Foundation to Project in reality. Interface is declared in Foundation, but implementation is in Project and registered via DI. It means that Foundation projects, that are core and stable part of solution, depend on Project level, which is not so stable and reliable.

In reality is highlighted in bold, because the user really meant at run-time. At run-time Foundation depends on Project, the same way that at run-time ClientCode() depends on SqlConnection. But at design-time Foundation doesn’t depend on Project, the same way that at design-time ClientCode() doesn’t depends on SqlConnection. At design-time ClientCode() only knows about IDbConnection.

From this, one implies that not only at design time, but also at runtime dependencies should go from Project towards Foundation. In other words, one feels that implementing an adapter into Project and injecting it into a Foundation component “is not so stable and reliable”, but that’s not how those principles are meant and described.

As a matter of fact, being able to inject Project adapters into Foundation components (where the Project adapter implements one of Foundation’s interfaces) is the core of the Dependency Inversion Principle (DIP). Without it, it is impossible to create flexible systems. This can be unreliable, but only if one doesn’t follow the Liskov Substitution Principle (LSP), when Foundation interfaces are not well thought-out, like for example when ICollection<T> forces the Array class to implement ICollection<T>.Add() which obviously cannot be supported.

Conclusion

Hence it looks like this feature need results from a confusion between design-time dependencies and run-time dependencies. The purpose of design is to reduce the cost of change, anything else is not design. Managing design-time dependencies is at the heart of design. All SOLID principles and all principles surrounding SOLID like the Stable Dependency Principle (SDP) are about design-time dependencies.

Moreover adding DI support would be a never-ending story—and I guess it cannot be done right without information collected at run-time. DI Containers are very complex beasts internally, their behavior often changes from one major version to the next, and there are dozens of DI Containers in .NET (Autofac, UnityContainer, NInject, StructureMap, MEF, SimpleInjector, Castle.Windsor, LightInject, Prism, Spring.net … just to name a few).

Again all our developments are driven by users-need, but on this particular need we’re not sure it’d make sense. We let the discussion open on this post and on the User Voices page. Whether you agree or disagree with our positions, feel free to comment.

SOLID Design: The Dependency Inversion Principle (DIP)

After having covered the Open-Close Principle (OCP), the Liskov Substitution Principle (LSP), the Single Responsibility Principle (SRP) and the Interface Segregation Principle (ISP) let’s talk about the Dependency Inversion Principle (DIP) which is the D in the SOLID acronym. The DIP definition is:

a. High-level modules should not depend on low-level modules. Both should depend on abstractions.
b. Abstractions should not depend on details (concrete implementation). Details should depend on abstractions.

The DIP has been introduced in the 90s by Robert C Martin. Here is the original article.

A Dependency is a Risk

As all SOLID principles DIP is about system maintainability and reusability. Inevitably some parts of the system will evolve and will be modified. We want a design that is resilient to changes. To avoid that a change breaks too much, we must:

first identify parts of the code that are changes-prone.
second avoid dependencies on those changes-prone code portion.

The Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) articles explains that interfaces must be carefully thought out. Both principles are 2 faces of the same coin:

ISP is the client perspective: If an interface is too fat probably the client sees some behaviors it doesn’t care for.
LSP is the implementer perspective: If an interface is too fat probably a class that implements it won’t implement all its behaviors. Some behavior will end up throwing something like a NotSupportedException.

Efforts put in applying ISP and LSP result in interfaces stability. As a consequence these well-designed interfaces are less subject to changes than concrete classes that implement them.

Also having stable interfaces results in improved reusability. I am pretty confident that the interface IDisposable will never change. My classes can safely implement it and this interface is re-used all over the world.

In this context, the DIP states that depending on interfaces is less risky than depending on concrete implementations. DIP is about transforming this code:

static void ClientCode(SqlConnection sqlConnection) {
   sqlConnection.Open();
}

static void ClientCode(SqlConnection sqlConnection) {

sqlConnection.Open();

}

into this code:

static void ClientCode(IDbConnection dbConnection) {
   dbConnection.Open();
}

static void ClientCode(IDbConnection dbConnection) {

dbConnection.Open();

}

DIP is about removing dependencies from high-level code (like the ClientCode() method) to low-level code, low-level code being implementation details like the SqlConnection class. For that we create interfaces like IDbConnection. Then both high-level code and low-level code depend on these interfaces. The key is that SqlConnection is not visible anymore from the ClientCode(). This way the client code won’t be impacted by implementation changes, like when replacing the SQL Server RDBMS implementation with MySql for example.

Let’s underline that this minimal code sample doesn’t do justice to the word Inversion in the DIP acronym. The inversion is about interfaces introduced (to be consumed by high-level code) and implementation details: implementation details depends on the interfaces, not the opposite, here is the inversion.

DIP and Dependency Injection (DI)

The acronym DI is used for Dependency Injection and since it is almost the same as the DIP acronym this provokes confusion. The I is used for Inversion or Injection which might add up confusion. Hopefully DI and DIP are very much related.

DIP states that classes that implement interfaces are not visible to the client code.
DI is about binding classes behind the interfaces consumed by client code.

DI means that some code, external to client code, configures which classes will be used at runtime by the client code. This is simple DI:

static void DICode() {
   IDbConnection dbConnection = new SqlConnection();
   ClientCode(dbConnection);
}
static void ClientCode(IDbConnection dbConnection) { // Client code has no idea what's behind IDbConnection
   dbConnection.Open();
}

static void DICode() {

IDbConnection dbConnection = new SqlConnection();

ClientCode(dbConnection);

}

static void ClientCode(IDbConnection dbConnection) { // Client code has no idea what's behind IDbConnection

dbConnection.Open();

}

Many .NET DI frameworks exist to offer flexibility in binding classes behind interfaces. Those frameworks are based on reflection and thus, they offer some kind of magic. The syntax looks like:

   // Autofac DI
   var builder = new ContainerBuilder();
   builder.RegisterInstance(new SqlConnection()).As<IDbConnection>();
   
   // UnityContainer DI
   IUnityContainer container = new UnityContainer();
   container.RegisterType<IDbConnection, SqlConnection>();
   
   // NInject DI
   public class Bindings : NinjectModule {
      public override void Load() {
         Bind<IDbConnection>().To<SqlConnection>();
      }
   }

// Autofac DI

var builder = new ContainerBuilder();

builder.RegisterInstance(new SqlConnection()).As<IDbConnection>();

// UnityContainer DI

IUnityContainer container = new UnityContainer();

container.RegisterType<IDbConnection, SqlConnection>();

// NInject DI

public class Bindings : NinjectModule {

public override void Load() {

Bind<IDbConnection>().To<SqlConnection>();

}

And then comes what is called a Service Locator. The client can use the locator to create instances of the concrete type without knowing it. It is like invoking a constructor on an interface:

IDbConnection dbConnection = Locator.Resolve<IDbConnection>();

1	IDbConnection dbConnection = Locator.Resolve<IDbConnection>();

Thus while DIP is about maintainable and reusable design, DI is about flexible design. Both are very much related. Let’s notice that the flexibility obtained from DI is especially useful for testing purposes. Being DIP compliant improves the testability of the code:

class MockConnection : IDbConnection {
   void Open() { ... }
   ...
}
[Test]
public void MyTest() {
   IDbConnection dbConnection = new MockConnection(); // Abstract the test from the database layer
   var result = ClientCode(dbConnection);
   Assert.ThingsOn(result);
}
static Result ClientCode(IDbConnection dbConnection) {
   dbConnection.Open();
   // ... do interesting stuff
   return result;
}

class MockConnection : IDbConnection {

void Open() { ... }

...

}

[Test]

public void MyTest() {

IDbConnection dbConnection = new MockConnection(); // Abstract the test from the database layer

var result = ClientCode(dbConnection);

Assert.ThingsOn(result);

}

static Result ClientCode(IDbConnection dbConnection) {

dbConnection.Open();

// ... do interesting stuff

return result;

}

DIP and Inversion of Control (IoC)

The Inversion word is used both in DIP and IoC acronyms. This provokes confusion. Remember that the word Inversion in the DIP acronym is about implementation details depending on interfaces, not the opposite. The Inversion word in the IoC acronym is about calls to Library transformed into callbacks from Framework.

IoC is what differentiates a Framework from a Library. A library is typically a collection of functions and classes. On the other hands a framework also offers reusable classes but massively relies on callbacks. For example UI frameworks offers many callback points through graphical events:

class MyForm : FrameworkForm {
   private Button m_Button = new Button();
   public MyForm() {
      m_Button.OnClick += m_ButtonOnClick;
   }
   private void m_ButtonOnClick(Sender sender) { ... }
}

class MyForm : FrameworkForm {

private Button m_Button = new Button();

public MyForm() {

m_Button.OnClick += m_ButtonOnClick;

}

private void m_ButtonOnClick(Sender sender) { ... }

}

The method m_ButtonOnClick() bound to the Button.OnClick event is a callback method. Instead of client code calling a framework method, the framework is responsible for calling back client code. This is an inversion in the control flow.

We can see that IoC is not related to DIP. However we can see Dependency Injection has a specialization of IoC: DI is an IoC used specifically to manage dependencies.

DIP and the Level metric

Several code metrics can be used to measure, and thus constraint, the usage of DIP. One of these metric is the Level metric. The Level metric is defined as followed:

From this diagram we can infer that:

The Level metric is not defined for components involved in a dependency cycle. As a consequence null values can help tracking component dependency cycles.
The Level metric is defined for any dependency graph. Thus a Level metric can be defined for various granularity: methods, types, namespaces, assemblies.

DIP mostly states that types with Level 0 must be interfaces and enumerations (note that interfaces using others interfaces have a Level value higher than 0). If we say that a component is a group of types (like a namespace or an assembly) the DIP states that components with Level 0 must contain mostly interfaces and enumerations. With a quick code query like this one you can have a glance at types Level and check if most of low level types are interfaces:

from t in JustMyCode.Types
where t.Level != null
orderby t.Level ascending
select new { t, t.Level }

from t in JustMyCode.Types

where t.Level != null

orderby t.Level ascending

select new { t, t.Level }

The Level metric can also be used to track classes with high Level values: it is a good indication that some interfaces must be introduced to break the long chain of concrete code calls:

The class Program has a Level of 8 and if we look at the dependency graphs of types used from Program we can certainly see opportunities to introduce abstractions to be more DIP compliant:

DIP and the Abstractness vs. Instability Graph

Robert C. Martin not only coined the DIP but also proposed some code metrics to measure the DIP compliance. See these metrics definitions here. From these metrics an intriguing Abstractness vs. Instability diagram can be plotted. Here we plotted the 3 assemblies of the OSS eShopOnWeb application. This diagram has been obtained from an NDepend report:

The Abstractness metric is normalized : it takes its values in the range [0,1]. It measures the interfaces / classes ratio (1 means the assembly contains only interfaces and enumerations).
The Instability metric is normalized and measures the assembly’s resilience to change. In this context, being stable means that a lot of code depends on you (which is wrong for a concrete class and fine for an interface) and being unstable means the opposite: not much code depends on you (which is fine for a concrete class and wrong for an interface, a poorly used interface is potentially a waste of design efforts).

This diagram shows a balance between the two metrics and defines some green/orange/red zones:

A dot in the red Zone of Pain means that the assembly is mostly concrete and used a lot. This is a pain because all those concrete classes will likely undergo a lot of changes and each change will potentially impact a lot of code. An example of a class living in the Zone of Pain would be the String class. It is massively used but it is concrete: if a change should occur today in the String class the entire world would be impacted. Hopefully we can count on the String implementation to be both performance-wise and bug-free.
A dot in the red Zone of Uselessness means that the assembly contains mostly interfaces and enumerations and is not much used. This makes these abstractions useless.
The Green zone revolves around the Main Sequence line. This line represents the right balance between both metrics. Containing mostly interfaces and being used a lot is fine. Containing mostly classes and not being used much is fine. And then comes all intermediate well balanced values between these 2 extremes represented by the Main Sequence line. The Distance from Main Sequence metric can be normalized and measures this balance. A value close to 0 means that the dot is near the line, in the green zone, and that the DIP is respected.

Conclusion

As the Open-Close Principle (OCP), the Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) the DIP is a key principle to wisely harness the OOP abstraction and polymorphism concepts in order to improve the maintainability, the reusability and the testability of your code. No principle is an island (except maybe the Single Responsibility Principle (SRP)) and they must be applied hands-in-hands.

This article concludes this SOLID posts serie. Being aware of SOLID principles is not enough: they must be kept in mind during every design decision. But they also must be constrained by the KISS principle, Keep It Simple Stupid, because as we explained in the post Are SOLID principles Cargo Cult? it is easy to write entangled code in the name of SOLID principles. Then one can learn from experience. With years, identifying the right abstractions and partitioning properly the business needs in well balanced classes is becoming natural.

SOLID Design: The Interface Segregation Principle (ISP)

After having covered The Open-Close Principle (OCP), The Liskov Substitution Principle (LSP) and the Single Responsibility Principle (SRP) let’s talk about the Interface Segregation Principle (ISP) which is the I in the SOLID acronym. The ISP definition is:

Client should not be forced to depend on methods it does not use.

It is all about interface, the common abstractions available in most OOP language such as C#, VB.NET or Java. A more complete and actionable explanation of ISP is:

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.

Roles and Responsibilities

When a class implements several shrunken role interfaces, it has several roles which might lead to think that such class has several responsibilities: it would then violate the Single Responsibility Services.

But a role is a finer-grained concept than a responsibility. An example of a role is the IDisposable interface:

public interface IDisposable {
   void Dispose();
}

public interface IDisposable {

void Dispose();

}

This interface has a single method but it is implemented by a wide variety of classes: DB or network connections that need to be closed gracefully, UI elements that need to deallocate some bitmaps in memory… The only thing the IDisposable interface says to clients is that instances of IDisposable class needs a graceful shutdown.

Hence IDisposable represents a technical detail that the client needs to be aware of. It is much finer-grained concept than a responsibility.

A small interface is not necessarily a good abstraction

A single method interface often makes sense, an IExecutor that Execute(), an IVisitor that Visit(), an IParent that exposes Children { get; }. Often, such minimalist interface should be generic. For example the interface ICloneable available since the .NET Framework v1.1 is nowadays considered as a code smell: when using it the client needs to downcast the cloned Object reference returned to do anything useful with the cloned instance.

public interface ICloneable { 
   object Clone(); 
}

public interface ICloneable {

object Clone();

}

ICloneable has another major drawback: it doesn’t inform the client if the clone operation is deep or shallow. This problem is even more serious than the Object reference downcasting one: it is a real design problem. As we can see a minimalist interface is not necessarily a good abstraction. In this example, the lack of information means ambiguity for the client. This would have been better design:

public interface IDeepCloneable<T> { 
   T DeepClone(); 
}
public interface IShallowCloneable<T> { 
   T ShallowClone();
}

public interface IDeepCloneable<T> {

T DeepClone();

}

public interface IShallowCloneable<T> {

T ShallowClone();

}

A fat interface is not necessarily a design flaw

A rule like Avoid too large interfaces can certainly pinpoint most of the ISP violations. A threshold of 10 methods is proposed by default to define a too large interface.

However, as always with code metrics and static analysis, such rule can also spit some false positives. For example this fat interface is valid:

In such case the SuppressMessageAttribute can be used with a proper justification. Such justification embeds in the code itself the design decisions. It makes the source code more understandable and more maintainable:

[SuppressMessage("NDepend", "ND1200:AvoidInterfacesTooBig", Justification="This interface is fat because it needs to support all primitive types"]
public interface IConvertible {
   ...

[SuppressMessage("NDepend", "ND1200:AvoidInterfacesTooBig", Justification="This interface is fat because it needs to support all primitive types"]

public interface IConvertible {

...

ISP and the Liskov Substitution Principle (LSP)

ISP and LSP are like 2 faces of the same coin:

ISP is the client perspective: If an interface is too fat probably the client sees some behaviors it doesn’t care for.
LSP is the implementer perspective: If an interface is too fat probably a class that implements it won’t implement all its behaviors. Some behavior will end up throwing something like a NotSupportedException.

Remember the ICollection<T> interface already discussed in the LSP article. This interface forces all its implementers to implement an Add() method. From the Array class perspective, implementing ICollection<T> is a violation of the LSP because array doesn’t support element adding:

The same way many clients will only need a read-only view of consumed collections. ICollection<T> also violates the ISP: it forces those clients to be coupled with Add() / Insert() / Remove() methods they don’t need. The introduction of IReadOnlyCollection<T> solved both ISP and LSP violations.

This example also shows that ISP doesn’t necessarily mean that a class should implement several lightweight interfaces. It is fine to nest interfaces like russian-nesting-dolls. ICollection<T> is a bit fat, it does a lot, read, add, insert, remove, count… But this interface is well-adapted both for classes that are read/write collections and for clients that work on read/write collection. It makes more sense to nest both read/write behaviors into ICollection<T> than to decompose both behaviors into IReadOnlyCollection<T> and an hypothetical IWriteOnlyCollection<T> interface.

Btw, maybe you noticed that ICollection<T> actually doesn’t implement IReadOnlyCollection<T>. In an ideal world it should implement it but IReadOnlyCollection<T> was introduced several years after ICollection<T> and backward compatibility must be preserved: for example this class would have been broken if ICollection<T> was implementing IReadOnlyCollection<T>, because of the explicit interface implementation usage on ICollection<T>.Count:

class MyCollection<T> : ICollection<T> {
   int ICollection<T>.Count { get { return 0; } }
   // ...
}

class MyCollection<T> : ICollection<T> {

int ICollection<T>.Count { get { return 0; } }

// ...

}

Conclusion

ISP is about preventing inadvertent coupling between a client and some behaviors he/she won’t need. Being coupled with something unneeded is a problem:

In the best case it is a waste: this forces the client to consume precious brain-cycles to consider something he/she doesn’t need.
In the worst case it is error-prone: the client ends-up misusing the extra behaviors, like attempting to add an element to an array through ICollection<T>.Add().

As for all SOLID principles, ISP is better applied if you practice test-first, or at least, if you write tests and code at the same time. ISP is about the client perspective and writing tests transforms you for a while into a client of your code.

Out of curiosity I wrote this code query that can be re-used to attempt to measure compliance with the ISP.

from @interface in Application.Types.Where(t => t.IsInterface && t.Methods.Any() && t.IsInternal)
let tUsers = @interface.TypesUsingMe.Where(t => !t.IsAbstract && !t.Implement(@interface))
where tUsers.Any()
let nbMethodsUsed = tUsers.Sum(t => @interface.Methods.UsedBy(t).Count())
let maximumUsage = tUsers.Count() * @interface.Methods.Count()
select new { 
   @interface, 
   score = (double) nbMethodsUsed /  (double) maximumUsage,
   tUsers,
   interfaceMethods = @interface.Methods
}

from @interface in Application.Types.Where(t => t.IsInterface && t.Methods.Any() && t.IsInternal)

let tUsers = @interface.TypesUsingMe.Where(t => !t.IsAbstract && !t.Implement(@interface))

where tUsers.Any()

let nbMethodsUsed = tUsers.Sum(t => @interface.Methods.UsedBy(t).Count())

let maximumUsage = tUsers.Count() * @interface.Methods.Count()

select new {

@interface,

score = (double) nbMethodsUsed / (double) maximumUsage,

tUsers,

interfaceMethods = @interface.Methods

}

This query estimates the ratio of usage of the methods of an interface over the maximum usage (maximum usage being when all types consuming an interface call all methods of the interface). Some work would be needed to transform this experimental query into a formal rule. For example the query needs to be smart about methods overloaded that can arguably be considered as a single method.

Nevertheless here are the raw results for non-public interfaces of the .NET framework implementation. Only non-public interfaces are considered because we need to also analyze some real clients of the interface:

927 types	score	tUsers	interfaceMethods	Full Name
IExceptionData	0.33	3 types	1 method	Microsoft.Build.Tasks.Xsd.IExceptionData
IDtcNetworkAccessConfig	0.077	2 types	13 methods	Microsoft.Tools.ServiceModel.WsatConfig .IDtcNetworkAccessConfig
INetFirewallOpenPort	0.6	1 type	15 methods	Microsoft.Tools.ServiceModel.WsatConfig .INetFirewallOpenPort
INetFirewallOpenPortsCollection	0.6	1 type	5 methods	Microsoft.Tools.ServiceModel.WsatConfig .INetFirewallOpenPortsCollection
INetFirewallProfile	0.071	1 type	14 methods	Microsoft.Tools.ServiceModel.WsatConfig .INetFirewallProfile
INetFirewallPolicy	0.5	1 type	2 methods	Microsoft.Tools.ServiceModel.WsatConfig .INetFirewallPolicy
INetFirewallMgr	0.2	1 type	5 methods	Microsoft.Tools.ServiceModel.WsatConfig .INetFirewallMgr
IDtdInfo	0.056	23 types	7 methods	System.Xml.IDtdInfo
IDtdAttributeListInfo	0.33	3 types	6 methods	System.Xml.IDtdAttributeListInfo
IDtdAttributeInfo	0.39	4 types	7 methods	System.Xml.IDtdAttributeInfo
IDtdDefaultAttributeInfo	0.11	9 types	4 methods	System.Xml.IDtdDefaultAttributeInfo
IDtdEntityInfo	0.19	6 types	12 methods	System.Xml.IDtdEntityInfo
IDtdParser	0.58	3 types	4 methods	System.Xml.IDtdParser
IDtdParserAdapter	0.21	5 types	32 methods	System.Xml.IDtdParserAdapter
IDtdParserAdapterWithValidation	0.75	2 types	2 methods	System.Xml .IDtdParserAdapterWithValidation
IDtdParserAdapterV1	1	1 type	3 methods	System.Xml.IDtdParserAdapterV1
IValidationEventHandling	0.3	10 types	2 methods	System.Xml.IValidationEventHandling
IRemovableWriter	0.5	1 type	2 methods	System.Xml.IRemovableWriter
INameScope	1	2 types	2 methods	System.Xml.Serialization.INameScope
IXamlBuildProviderExtension	0.5	2 types	2 methods	System.Xaml.Hosting .IXamlBuildProviderExtension
IXamlBuildProviderExtensionFactory	1	1 type	1 method	System.Xaml.Hosting .IXamlBuildProviderExtensionFactory
IAddLineInfo	0.5	2 types	1 method	MS.Internal.Xaml.Runtime.IAddLineInfo
ICheckIfInitialized	0.5	2 types	1 method	MS.Internal.Xaml.Context .ICheckIfInitialized
IServiceDescriptionBuilder	1	1 type	1 method	System.ServiceModel.Description .IServiceDescriptionBuilder
IExternalDataExchange	0.33	3 types	1 method	System.ServiceModel.Activities .IExternalDataExchange
IWDEProgramNode	0	1 type	1 method	System.Workflow.Runtime.DebugEngine .IWDEProgramNode
IWDEProgramPublisher	1	1 type	2 methods	System.Workflow.Runtime.DebugEngine .IWDEProgramPublisher
ISupportWorkflowChanges	1	1 type	3 methods	System.Workflow.ComponentModel .ISupportWorkflowChanges
ISupportAlternateFlow	1	11 types	1 method	System.Workflow.ComponentModel .ISupportAlternateFlow
IDependencyObjectAccessor	0.3	10 types	4 methods	System.Workflow.ComponentModel .IDependencyObjectAccessor
IWorkflowCoreRuntime	0.1	20 types	31 methods	System.Workflow.ComponentModel .IWorkflowCoreRuntime
ITimerService	0.5	2 types	2 methods	System.Workflow.ComponentModel .ITimerService
IWorkflowDesignerMessageSink	0.23	4 types	32 methods	System.Workflow.ComponentModel.Design .IWorkflowDesignerMessageSink
IPropertyValueProvider	1	2 types	1 method	System.Workflow.ComponentModel.Design .IPropertyValueProvider
IOleServiceProvider	0.5	2 types	1 method	System.Workflow.ComponentModel.Compiler .IOleServiceProvider
IWorkflowBuildHostProperties	0.5	1 type	2 methods	System.Workflow.ComponentModel.Compiler .IWorkflowBuildHostProperties
IWorkflowCompilerError	0	1 type	6 methods	System.Workflow.ComponentModel.Compiler .IWorkflowCompilerError
IWorkflowCompilerErrorLogger	1	1 type	2 methods	System.Workflow.ComponentModel.Compiler .IWorkflowCompilerErrorLogger
ISymUnmanagedReader	0.12	1 type	17 methods	System.Workflow.ComponentModel.Compiler .ISymUnmanagedReader
ISymUnmanagedMethod	0.2	1 type	10 methods	System.Workflow.ComponentModel.Compiler .ISymUnmanagedMethod
ISymUnmanagedDocument	0.1	1 type	10 methods	System.Workflow.ComponentModel.Compiler .ISymUnmanagedDocument
IMetaDataDispenser	0.33	1 type	3 methods	System.Workflow.ComponentModel.Compiler .IMetaDataDispenser
ITypeAuthorizer	0.33	3 types	1 method	System.Workflow.ComponentModel .Serialization.ITypeAuthorizer
IDirectoryOperation	0.5	2 types	1 method	System.Workflow.Activities .IDirectoryOperation
ICorrelationProvider	0.33	3 types	2 methods	System.Workflow.Activities .ICorrelationProvider
IMethodResponseMessage	0.25	2 types	4 methods	System.Workflow.Activities .IMethodResponseMessage
IDeliverMessage	0.33	3 types	2 methods	System.Workflow.Activities .IDeliverMessage
IPropertyValueProvider	1	2 types	1 method	System.Workflow.Activities.Common .IPropertyValueProvider
IAliasResolver	1	1 type	2 methods	System.Resources.IAliasResolver
ISection	0	4 types	4 methods	System.Deployment.Internal.Isolation .ISection
ISectionEntry	0	1 type	2 methods	System.Deployment.Internal.Isolation .ISectionEntry
IEnumSTORE_ASSEMBLY_INSTALLATION_REFEREN CE	0	1 type	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_INSTALLATION_REFERE NCE
IEnumSTORE_DEPLOYMENT_METADATA	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA
IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY
IEnumSTORE_ASSEMBLY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY
IEnumSTORE_ASSEMBLY_FILE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_FILE
IEnumSTORE_CATEGORY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY
IEnumSTORE_CATEGORY_SUBCATEGORY	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_SUBCATEGORY
IEnumSTORE_CATEGORY_INSTANCE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_INSTANCE
IReferenceIdentity	0.071	7 types	4 methods	System.Deployment.Internal.Isolation .IReferenceIdentity
IDefinitionIdentity	0.038	13 types	4 methods	System.Deployment.Internal.Isolation .IDefinitionIdentity
IEnumDefinitionIdentity	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumDefinitionIdentity
IEnumReferenceIdentity	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumReferenceIdentity
IDefinitionAppId	0.059	17 types	6 methods	System.Deployment.Internal.Isolation .IDefinitionAppId
IReferenceAppId	0.2	5 types	5 methods	System.Deployment.Internal.Isolation .IReferenceAppId
IIdentityAuthority	0	1 type	18 methods	System.Deployment.Internal.Isolation .IIdentityAuthority
IAppIdAuthority	0.062	3 types	16 methods	System.Deployment.Internal.Isolation .IAppIdAuthority
IStore	0.24	4 types	20 methods	System.Deployment.Internal.Isolation .IStore
IManifestParseErrorCallback	0	1 type	1 method	System.Deployment.Internal.Isolation .IManifestParseErrorCallback
IManifestInformation	0.5	2 types	1 method	System.Deployment.Internal.Isolation .IManifestInformation
IActContext	0.28	2 types	18 methods	System.Deployment.Internal.Isolation .IActContext
ICMS	0.011	4 types	22 methods	System.Deployment.Internal.Isolation .Manifest.ICMS
IDescriptionMetadataEntry	0.43	1 type	7 methods	System.Deployment.Internal.Isolation .Manifest.IDescriptionMetadataEntry
IDeploymentMetadataEntry	0.17	1 type	6 methods	System.Deployment.Internal.Isolation .Manifest.IDeploymentMetadataEntry
IMetadataSectionEntry	0.14	1 type	21 methods	System.Deployment.Internal.Isolation .Manifest.IMetadataSectionEntry
FileDialogNative+IModalWindow	0	1 type	1 method	System.Windows.Forms .FileDialogNative+IModalWindow
FileDialogNative+IShellItemArray	0.14	2 types	7 methods	System.Windows.Forms .FileDialogNative+IShellItemArray
FileDialogNative+IFileDialog	0.017	5 types	24 methods	System.Windows.Forms .FileDialogNative+IFileDialog
FileDialogNative+IFileOpenDialog	0.038	2 types	26 methods	System.Windows.Forms .FileDialogNative+IFileOpenDialog
FileDialogNative+IFileSaveDialog	0	2 types	29 methods	System.Windows.Forms .FileDialogNative+IFileSaveDialog
FileDialogNative+IFileDialogEvents	0	1 type	7 methods	System.Windows.Forms .FileDialogNative+IFileDialogEvents
FileDialogNative+IShellItem	0	7 types	5 methods	System.Windows.Forms .FileDialogNative+IShellItem
IKeyboardToolTip	0.23	4 types	13 methods	System.Windows.Forms.IKeyboardToolTip
ISupportOleDropSource	1	1 type	2 methods	System.Windows.Forms .ISupportOleDropSource
ISupportToolStripPanel	0.27	6 types	8 methods	System.Windows.Forms .ISupportToolStripPanel
ListView+ListViewItemCollection+IInnerLi st	0.31	3 types	15 methods	System.Windows.Forms .ListView+ListViewItemCollection+IInnerL ist
NativeMethods+IHTMLDocument	0	1 type	1 method	System.Windows.Forms .NativeMethods+IHTMLDocument
UnsafeNativeMethods+IHTMLDocument	0	6 types	1 method	System.Windows.Forms .UnsafeNativeMethods+IHTMLDocument
UnsafeNativeMethods+IHTMLDocument2	0.057	6 types	109 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLDocument2
UnsafeNativeMethods+IHTMLDocument3	0.049	3 types	41 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLDocument3
UnsafeNativeMethods+IHTMLDocument4	0.071	2 types	14 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLDocument4
UnsafeNativeMethods+IHTMLFramesCollectio n2	0.33	3 types	2 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLFramesCollecti on2
UnsafeNativeMethods+IHTMLLocation	0.039	4 types	19 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLLocation
UnsafeNativeMethods+IOmHistory	0.17	3 types	4 methods	System.Windows.Forms .UnsafeNativeMethods+IOmHistory
UnsafeNativeMethods+IOmNavigator	0	1 type	19 methods	System.Windows.Forms .UnsafeNativeMethods+IOmNavigator
UnsafeNativeMethods+IHTMLEventObj	0.14	5 types	25 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLEventObj
UnsafeNativeMethods+IHTMLEventObj2	0	1 type	56 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLEventObj2
UnsafeNativeMethods+IHTMLEventObj4	0	1 type	1 method	System.Windows.Forms .UnsafeNativeMethods+IHTMLEventObj4
UnsafeNativeMethods+IHTMLElementCollecti on	0.083	4 types	6 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLElementCollect ion
UnsafeNativeMethods+IHTMLElement	0.043	7 types	87 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLElement
UnsafeNativeMethods+IHTMLElement2	0.065	3 types	98 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLElement2
UnsafeNativeMethods+IHTMLElement3	0.035	2 types	43 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLElement3
UnsafeNativeMethods+IHTMLStyle	0.0056	2 types	178 methods	System.Windows.Forms .UnsafeNativeMethods+IHTMLStyle
UnsafeNativeMethods+ICorRuntimeHost	0.026	2 types	19 methods	System.Windows.Forms .UnsafeNativeMethods+ICorRuntimeHost
UnsafeNativeMethods+IServiceProvider	0	1 type	1 method	System.Windows.Forms .UnsafeNativeMethods+IServiceProvider
UnsafeNativeMethods+IAccessibleEx	0	1 type	4 methods	System.Windows.Forms .UnsafeNativeMethods+IAccessibleEx
PropertyGridView+IMouseHookClient	0.5	2 types	1 method	System.Windows.Forms .PropertyGridInternal .PropertyGridView+IMouseHookClient
IArrangedElement	0.12	32 types	9 methods	System.Windows.Forms.Layout .IArrangedElement
IDataPointCustomPropertiesProvider	1	1 type	1 method	System.Windows.Forms.DataVisualization .Charting .IDataPointCustomPropertiesProvider
IChartElement	0.25	4 types	4 methods	System.Windows.Forms.DataVisualization .Charting.IChartElement
INameController	0.57	1 type	7 methods	System.Windows.Forms.DataVisualization .Charting.INameController
IChartRenderingEngine	0.93	1 type	45 methods	System.Windows.Forms.DataVisualization .Charting.IChartRenderingEngine
IDesignerMessageBoxDialog	0.5	2 types	1 method	System.Windows.Forms.DataVisualization .Charting.IDesignerMessageBoxDialog
IFormula	0.25	2 types	2 methods	System.Windows.Forms.DataVisualization .Charting.Formulas.IFormula
IChartType	0.11	13 types	22 methods	System.Windows.Forms.DataVisualization .Charting.ChartTypes.IChartType
ICircularChartType	0.17	5 types	6 methods	System.Windows.Forms.DataVisualization .Charting.ChartTypes.ICircularChartType
IBorderType	0.3	4 types	5 methods	System.Windows.Forms.DataVisualization .Charting.Borders3D.IBorderType
INotifyConnection2	0.5	2 types	2 methods	System.Web.Services.Interop .INotifyConnection2
INotifySink2	0.5	2 types	4 methods	System.Web.Services.Interop.INotifySink2
INotifySource2	0	1 type	1 method	System.Web.Services.Interop .INotifySource2
IDeviceSpecificChoiceDesigner	0.5	4 types	2 methods	System.Web.UI.Design.MobileControls .IDeviceSpecificChoiceDesigner
IDeviceSpecificDesigner	0.15	11 types	10 methods	System.Web.UI.Design.MobileControls .IDeviceSpecificDesigner
IListDesigner	0.05	2 types	10 methods	System.Web.UI.Design.MobileControls .IListDesigner
IRefreshableDeviceSpecificEditor	0.5	2 types	7 methods	System.Web.UI.Design.MobileControls .IRefreshableDeviceSpecificEditor
NativeMethods+IStream	0	1 type	11 methods	System.Web.UI.Design.MobileControls .NativeMethods+IStream
NativeMethods+IHTMLElement	0.0077	3 types	87 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLElement
NativeMethods+IHTMLDocument2	0.0055	5 types	109 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLDocument2
NativeMethods+IHTMLDocument3	0.012	2 types	41 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLDocument3
NativeMethods+IHTMLStyleSheet	0	1 type	21 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLStyleSheet
NativeMethods+IHTMLStyle	0	1 type	178 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLStyle
NativeMethods+IHTMLElementCollection	0	1 type	6 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLElementCollection
NativeMethods+IHTMLDOMNode	0	1 type	20 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLDOMNode
NativeMethods+IOleContainer	0	2 types	3 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleContainer
NativeMethods+IOleClientSite	0	1 type	6 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleClientSite
NativeMethods+IOleDocumentSite	0	1 type	1 method	System.Web.UI.Design.MobileControls .NativeMethods+IOleDocumentSite
NativeMethods+IOleDocumentView	0.15	2 types	13 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleDocumentView
NativeMethods+IOleInPlaceSite	0	1 type	12 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleInPlaceSite
NativeMethods+IOleInPlaceFrame	0	1 type	12 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleInPlaceFrame
NativeMethods+IOleInPlaceUIWindow	0	2 types	6 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleInPlaceUIWindow
NativeMethods+IDocHostUIHandler	0	1 type	15 methods	System.Web.UI.Design.MobileControls .NativeMethods+IDocHostUIHandler
NativeMethods+IOleInPlaceActiveObject	0	2 types	7 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleInPlaceActiveObject
NativeMethods+IOleObject	0.048	2 types	21 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleObject
NativeMethods+IOleCommandTarget	0	2 types	2 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleCommandTarget
NativeMethods+IOleDropTarget	0	2 types	4 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleDropTarget
NativeMethods+IOleDataObject	0	2 types	9 methods	System.Web.UI.Design.MobileControls .NativeMethods+IOleDataObject
NativeMethods+IEnumOLEVERB	0	1 type	4 methods	System.Web.UI.Design.MobileControls .NativeMethods+IEnumOLEVERB
NativeMethods+IAdviseSink	0	1 type	5 methods	System.Web.UI.Design.MobileControls .NativeMethods+IAdviseSink
NativeMethods+IHTMLBodyElement	0.014	2 types	35 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLBodyElement
NativeMethods+IPersistStreamInit	0.083	2 types	6 methods	System.Web.UI.Design.MobileControls .NativeMethods+IPersistStreamInit
NativeMethods+IHTMLElement2	0.0094	3 types	106 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLElement2
NativeMethods+IHTMLRectCollection	0.33	2 types	3 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLRectCollection
NativeMethods+IHTMLCurrentStyle	0	1 type	67 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLCurrentStyle
NativeMethods+IHTMLRect	0.12	2 types	8 methods	System.Web.UI.Design.MobileControls .NativeMethods+IHTMLRect
IListControl	1	1 type	2 methods	System.Web.UI.MobileControls .IListControl
IScriptResourceHandler	1	1 type	3 methods	System.Web.Handlers .IScriptResourceHandler
IContractGeneratorReferenceTypeLoader	0.5	2 types	3 methods	System.Web.Compilation.WCFModel .IContractGeneratorReferenceTypeLoader
IContractGeneratorReferenceTypeLoader2	1	1 type	1 method	System.Web.Compilation.WCFModel .IContractGeneratorReferenceTypeLoader2
IClientScriptManager	0.14	5 types	7 methods	System.Web.UI.IClientScriptManager
IClientUrlResolver	0.4	5 types	2 methods	System.Web.UI.IClientUrlResolver
ICompilationSection	1	1 type	1 method	System.Web.UI.ICompilationSection
IControl	0.25	2 types	2 methods	System.Web.UI.IControl
ICustomErrorsSection	0.5	2 types	2 methods	System.Web.UI.ICustomErrorsSection
IDeploymentSection	1	1 type	1 method	System.Web.UI.IDeploymentSection
IHtmlForm	0.33	3 types	4 methods	System.Web.UI.IHtmlForm
IPage	0.12	8 types	31 methods	System.Web.UI.IPage
IScriptManagerInternal	0.17	4 types	12 methods	System.Web.UI.IScriptManagerInternal
IDynamicQueryable	0.14	2 types	7 methods	System.Web.UI.WebControls .IDynamicQueryable
ILinqToSql	0.67	1 type	6 methods	System.Web.UI.WebControls.ILinqToSql
ILinqDataSourceChooseContextType	0.44	2 types	8 methods	System.Web.UI.Design.WebControls .ILinqDataSourceChooseContextType
ILinqDataSourceChooseContextTypePanel	0.5	2 types	4 methods	System.Web.UI.Design.WebControls .ILinqDataSourceChooseContextTypePanel
ILinqDataSourceConfiguration	0.5	2 types	8 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfiguration
ILinqDataSourceConfigurationPanel	0.5	2 types	8 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigurationPanel
ILinqDataSourceConfigureAdvanced	0.5	2 types	1 method	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureAdvanced
ILinqDataSourceConfigureAdvancedForm	0.33	3 types	4 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureAdvancedForm
ILinqDataSourceConfigureGroupBy	0.42	2 types	6 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureGroupBy
ILinqDataSourceConfigureGroupByPanel	0.33	3 types	7 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureGroupByPanel
ILinqDataSourceConfigureOrderBy	0.33	2 types	3 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureOrderBy
ILinqDataSourceConfigureOrderByForm	0.33	3 types	6 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureOrderByForm
ILinqDataSourceConfigureSelect	0.42	2 types	6 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureSelect
ILinqDataSourceConfigureSelectPanel	0.33	3 types	22 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureSelectPanel
ILinqDataSourceConfigureWhere	0.25	4 types	16 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureWhere
ILinqDataSourceConfigureWhereForm	0.28	4 types	15 methods	System.Web.UI.Design.WebControls .ILinqDataSourceConfigureWhereForm
ILinqDataSourceContextTypeItem	0.22	9 types	3 methods	System.Web.UI.Design.WebControls .ILinqDataSourceContextTypeItem
ILinqDataSourceDesignerHelper	0.086	13 types	67 methods	System.Web.UI.Design.WebControls .ILinqDataSourceDesignerHelper
ILinqDataSourceProjection	0.25	5 types	8 methods	System.Web.UI.Design.WebControls .ILinqDataSourceProjection
ILinqDataSourcePropertyItem	0.099	22 types	11 methods	System.Web.UI.Design.WebControls .ILinqDataSourcePropertyItem
ILinqDataSourceStatementEditorForm	0.38	2 types	4 methods	System.Web.UI.Design.WebControls .ILinqDataSourceStatementEditorForm
ILinqDataSourceWizardForm	0.33	6 types	2 methods	System.Web.UI.Design.WebControls .ILinqDataSourceWizardForm
ILinqDataSourceWrapper	0.5	2 types	44 methods	System.Web.UI.Design.WebControls .ILinqDataSourceWrapper
IMetaChildrenColumn	0.17	1 type	6 methods	System.Web.DynamicData .IMetaChildrenColumn
IMetaColumn	0.073	6 types	39 methods	System.Web.DynamicData.IMetaColumn
IMetaForeignKeyColumn	0.17	2 types	9 methods	System.Web.DynamicData .IMetaForeignKeyColumn
IMetaModel	0.019	3 types	18 methods	System.Web.DynamicData.IMetaModel
IMetaTable	0.035	10 types	43 methods	System.Web.DynamicData.IMetaTable
MetaColumn+IMetaColumnMetadata	0.37	3 types	20 methods	System.Web.DynamicData .MetaColumn+IMetaColumnMetadata
IClrStrongNameUsingIntPtr	0.24	1 type	25 methods	Microsoft.Runtime.Hosting .IClrStrongNameUsingIntPtr
IClrStrongName	0.36	1 type	25 methods	Microsoft.Runtime.Hosting.IClrStrongName
IRequestCompletedNotifier	0.5	2 types	1 method	System.Web.IRequestCompletedNotifier
IBufferAllocator	0.083	3 types	4 methods	System.Web.IBufferAllocator
IBufferAllocator<T>	0.33	4 types	3 methods	System.Web.IBufferAllocator<T>
IAllocatorProvider	0.25	5 types	4 methods	System.Web.IAllocatorProvider
HttpApplication+IExecutionStep	0.2	5 types	3 methods	System.Web .HttpApplication+IExecutionStep
IHttpResponseElement	0.83	2 types	3 methods	System.Web.IHttpResponseElement
IHttpHandlerFactory2	1	1 type	1 method	System.Web.IHttpHandlerFactory2
IPartitionInfo	0.25	4 types	1 method	System.Web.IPartitionInfo
IAsyncAbortableWebSocket	0.5	2 types	1 method	System.Web.WebSockets .IAsyncAbortableWebSocket
IWebSocketPipe	0.5	2 types	4 methods	System.Web.WebSockets.IWebSocketPipe
IUnmanagedWebSocketContext	0.5	2 types	5 methods	System.Web.WebSockets .IUnmanagedWebSocketContext
IPerfCounters	0.12	4 types	4 methods	System.Web.Util.IPerfCounters
ISyncContextLock	0.33	3 types	1 method	System.Web.Util.ISyncContextLock
ISyncContext	0.2	5 types	2 methods	System.Web.Util.ISyncContext
ITypedWebObjectFactory	1	4 types	1 method	System.Web.Util.ITypedWebObjectFactory
ICustomRuntimeRegistrationToken	0	2 types	1 method	System.Web.Hosting .ICustomRuntimeRegistrationToken
IProcessSuspendListener	1	1 type	1 method	System.Web.Hosting .IProcessSuspendListener
IProcessResumeCallback	0.5	2 types	1 method	System.Web.Hosting .IProcessResumeCallback
ICustomRuntime	0	3 types	3 methods	System.Web.Hosting.ICustomRuntime
IStateFormatter2	0.62	8 types	2 methods	System.Web.UI.IStateFormatter2
IPageAsyncTask	0.5	2 types	1 method	System.Web.UI.IPageAsyncTask
IAssemblyDependencyParser	1	1 type	1 method	System.Web.UI.IAssemblyDependencyParser
IScriptResourceMapping	0.5	3 types	2 methods	System.Web.UI.IScriptResourceMapping
IScriptResourceDefinition	0.33	3 types	8 methods	System.Web.UI.IScriptResourceDefinition
IScriptManager	0.15	11 types	17 methods	System.Web.UI.IScriptManager
ITagNameToTypeMapper	1	1 type	1 method	System.Web.UI.ITagNameToTypeMapper
IRenderOuterTableControl	1	1 type	3 methods	System.Web.UI.IRenderOuterTableControl
IWizardSideBarListControl	0.1	5 types	12 methods	System.Web.UI.WebControls .IWizardSideBarListControl
IWebPartMenuUser	1	1 type	16 methods	System.Web.UI.WebControls.WebParts .IWebPartMenuUser
NativeComInterfaces+IAdsPathname	0.12	3 types	11 methods	System.Web.Security .NativeComInterfaces+IAdsPathname
NativeComInterfaces+IAdsLargeInteger	0.5	3 types	4 methods	System.Web.Security .NativeComInterfaces+IAdsLargeInteger
IDataProtectorFactory	0.5	2 types	1 method	System.Web.Security.Cryptography .IDataProtectorFactory
ICryptoServiceProvider	1	1 type	1 method	System.Web.Security.Cryptography .ICryptoServiceProvider
IMasterKeyProvider	0.5	2 types	2 methods	System.Web.Security.Cryptography .IMasterKeyProvider
ICryptoAlgorithmFactory	0.5	2 types	2 methods	System.Web.Security.Cryptography .ICryptoAlgorithmFactory
ICryptoService	0.83	6 types	2 methods	System.Web.Security.Cryptography .ICryptoService
IAssemblyCache	0.2	2 types	5 methods	System.Web.Configuration.IAssemblyCache
IConfigMapPath2	0.67	2 types	3 methods	System.Web.Configuration.IConfigMapPath2
IServerConfig	0.2	6 types	5 methods	System.Web.Configuration.IServerConfig
IServerConfig2	1	1 type	1 method	System.Web.Configuration.IServerConfig2
IDataPointCustomPropertiesProvider	1	1 type	1 method	System.Web.UI.DataVisualization.Charting .IDataPointCustomPropertiesProvider
IChartElement	0.25	3 types	4 methods	System.Web.UI.DataVisualization.Charting .IChartElement
INameController	0.57	1 type	7 methods	System.Web.UI.DataVisualization.Charting .INameController
IChartRenderingEngine	0.93	1 type	45 methods	System.Web.UI.DataVisualization.Charting .IChartRenderingEngine
IDesignerMessageBoxDialog	0.5	2 types	1 method	System.Web.UI.DataVisualization.Charting .IDesignerMessageBoxDialog
IFormula	0.25	2 types	2 methods	System.Web.UI.DataVisualization.Charting .Formulas.IFormula
IChartType	0.11	14 types	22 methods	System.Web.UI.DataVisualization.Charting .ChartTypes.IChartType
ICircularChartType	0.17	5 types	6 methods	System.Web.UI.DataVisualization.Charting .ChartTypes.ICircularChartType
IBorderType	0.3	4 types	5 methods	System.Web.UI.DataVisualization.Charting .Borders3D.IBorderType
IMembershipAdapter	0.27	3 types	5 methods	System.Web.Security.IMembershipAdapter
ICustomLoaderHelperFunctions	0.5	2 types	4 methods	System.Web.Hosting .ICustomLoaderHelperFunctions
IPromotedEnlistment	0.089	14 types	12 methods	System.Transactions.IPromotedEnlistment
IEnlistmentNotificationInternal	0.28	8 types	4 methods	System.Transactions .IEnlistmentNotificationInternal
ISinglePhaseNotificationInternal	0.25	4 types	1 method	System.Transactions .ISinglePhaseNotificationInternal
IVoterBallotShim	0.5	2 types	1 method	System.Transactions.Oletx .IVoterBallotShim
IPhase0EnlistmentShim	0.38	4 types	2 methods	System.Transactions.Oletx .IPhase0EnlistmentShim
IEnlistmentShim	0.5	2 types	3 methods	System.Transactions.Oletx .IEnlistmentShim
ITransactionShim	0.25	4 types	8 methods	System.Transactions.Oletx .ITransactionShim
IResourceManagerShim	0.44	3 types	3 methods	System.Transactions.Oletx .IResourceManagerShim
IDtcProxyShimFactory	0.2	5 types	8 methods	System.Transactions.Oletx .IDtcProxyShimFactory
ITransactionNativeInternal	0.33	1 type	3 methods	System.Transactions.Oletx .ITransactionNativeInternal
IWebFaultException	1	1 type	4 methods	System.ServiceModel.Web .IWebFaultException
IDuplexRouterCallback	0.33	3 types	2 methods	System.ServiceModel.Routing .IDuplexRouterCallback
IRoutingClient	0.23	5 types	7 methods	System.ServiceModel.Routing .IRoutingClient
IAsyncEventArgs	0.7	5 types	2 methods	System.Runtime.IAsyncEventArgs
IClassFactory	0.25	2 types	2 methods	IClassFactory
IOperationContractAttributeProvider	1	1 type	1 method	System.ServiceModel .IOperationContractAttributeProvider
ICatalog2	0.018	1 type	57 methods	System.ServiceModel.ComIntegration .ICatalog2
ICatalogObject	0.24	3 types	7 methods	System.ServiceModel.ComIntegration .ICatalogObject
ICatalogCollection	0.17	3 types	16 methods	System.ServiceModel.ComIntegration .ICatalogCollection
ICreateServiceChannel	1	1 type	1 method	System.ServiceModel.ComIntegration .ICreateServiceChannel
IMoniker	0	1 type	20 methods	System.ServiceModel.ComIntegration .IMoniker
IParseDisplayName	0	1 type	1 method	System.ServiceModel.ComIntegration .IParseDisplayName
IProvideChannelBuilderSettings	0.12	4 types	4 methods	System.ServiceModel.ComIntegration .IProvideChannelBuilderSettings
IProxyCreator	0.5	2 types	4 methods	System.ServiceModel.ComIntegration .IProxyCreator
IProxyManager	0	4 types	6 methods	System.ServiceModel.ComIntegration .IProxyManager
IProxyProvider	0.5	2 types	2 methods	System.ServiceModel.ComIntegration .IProxyProvider
IPseudoDispatch	0	1 type	2 methods	System.ServiceModel.ComIntegration .IPseudoDispatch
ITransactionProxy	0	1 type	7 methods	System.ServiceModel.ComIntegration .ITransactionProxy
ITransactionVoterBallotAsync2	0	1 type	1 method	System.ServiceModel.ComIntegration .ITransactionVoterBallotAsync2
ITransactionVoterNotifyAsync2	0.4	2 types	5 methods	System.ServiceModel.ComIntegration .ITransactionVoterNotifyAsync2
ITypeCacheManager	0.33	3 types	4 methods	System.ServiceModel.ComIntegration .ITypeCacheManager
IPersistStream	0.2	3 types	5 methods	System.ServiceModel.ComIntegration .IPersistStream
IServiceThreadPoolConfig	1	1 type	2 methods	System.ServiceModel.ComIntegration .IServiceThreadPoolConfig
IServicePartitionConfig	1	1 type	2 methods	System.ServiceModel.ComIntegration .IServicePartitionConfig
IServiceSysTxnConfig	0.14	1 type	7 methods	System.ServiceModel.ComIntegration .IServiceSysTxnConfig
IServiceSxsConfig	1	1 type	3 methods	System.ServiceModel.ComIntegration .IServiceSxsConfig
IServiceTransactionConfig	0.17	1 type	6 methods	System.ServiceModel.ComIntegration .IServiceTransactionConfig
IServiceCall	0	1 type	1 method	System.ServiceModel.ComIntegration .IServiceCall
IServiceActivity	0.25	2 types	4 methods	System.ServiceModel.ComIntegration .IServiceActivity
IComThreadingInfo	0.17	3 types	4 methods	System.ServiceModel.ComIntegration .IComThreadingInfo
IObjectContextInfo	0.3	2 types	5 methods	System.ServiceModel.ComIntegration .IObjectContextInfo
IContractResolver	0.2	5 types	1 method	System.ServiceModel.Description .IContractResolver
ServiceMetadataExtension+IHttpGetMetadat a	0	2 types	1 method	System.ServiceModel.Description .ServiceMetadataExtension+IHttpGetMetada ta
IWrappedBodyTypeGenerator	0.25	4 types	3 methods	System.ServiceModel.Description .IWrappedBodyTypeGenerator
WbemNative+IWbemProviderInit	0	1 type	1 method	System.ServiceModel.Administration .WbemNative+IWbemProviderInit
WbemNative+IWbemDecoupledRegistrar	0.5	2 types	2 methods	System.ServiceModel.Administration .WbemNative+IWbemDecoupledRegistrar
WbemNative+IWbemServices	0.022	4 types	23 methods	System.ServiceModel.Administration .WbemNative+IWbemServices
WbemNative+IWbemClassObject	0.056	6 types	24 methods	System.ServiceModel.Administration .WbemNative+IWbemClassObject
WbemNative+IWbemContext	0	5 types	9 methods	System.ServiceModel.Administration .WbemNative+IWbemContext
WbemNative+IWbemProviderInitSink	0.5	2 types	1 method	System.ServiceModel.Administration .WbemNative+IWbemProviderInitSink
WbemNative+IWbemObjectSink	0.33	6 types	2 methods	System.ServiceModel.Administration .WbemNative+IWbemObjectSink
WbemNative+IEnumWbemClassObject	0	2 types	5 methods	System.ServiceModel.Administration .WbemNative+IEnumWbemClassObject
WbemNative+IWbemQualifierSet	0	1 type	7 methods	System.ServiceModel.Administration .WbemNative+IWbemQualifierSet
IWmiProvider	0.5	2 types	5 methods	System.ServiceModel.Administration .IWmiProvider
IWmiInstances	0.75	8 types	2 methods	System.ServiceModel.Administration .IWmiInstances
IWmiInstance	0.44	22 types	3 methods	System.ServiceModel.Administration .IWmiInstance
IWmiMethodContext	0.27	3 types	5 methods	System.ServiceModel.Administration .IWmiMethodContext
IWmiInstanceProvider	1	3 types	2 methods	System.ServiceModel.Administration .IWmiInstanceProvider
IFunctionLibrary	1	1 type	1 method	System.ServiceModel.Dispatcher .IFunctionLibrary
INodeCounter	0.5	2 types	6 methods	System.ServiceModel.Dispatcher .INodeCounter
IItemComparer<K,V>	0.5	2 types	1 method	System.ServiceModel.Dispatcher .IItemComparer<K,V>
ConcurrencyBehavior+IWaiter	0.5	2 types	1 method	System.ServiceModel.Dispatcher .ConcurrencyBehavior+IWaiter
IClientFaultFormatter	0.33	6 types	1 method	System.ServiceModel.Dispatcher .IClientFaultFormatter
IDispatchFaultFormatter	0.22	9 types	1 method	System.ServiceModel.Dispatcher .IDispatchFaultFormatter
IDispatchFaultFormatterWrapper	0.5	1 type	2 methods	System.ServiceModel.Dispatcher .IDispatchFaultFormatterWrapper
IChannelBinder	0.076	23 types	20 methods	System.ServiceModel.Dispatcher .IChannelBinder
IListenerBinder	0.3	4 types	5 methods	System.ServiceModel.Dispatcher .IListenerBinder
IManualConcurrencyOperationInvoker	0.56	3 types	3 methods	System.ServiceModel.Dispatcher .IManualConcurrencyOperationInvoker
IInvokeReceivedNotification	0.19	8 types	2 methods	System.ServiceModel.Dispatcher .IInvokeReceivedNotification
IResumeMessageRpc	0.17	8 types	6 methods	System.ServiceModel.Dispatcher .IResumeMessageRpc
IInstanceTransaction	1	1 type	1 method	System.ServiceModel.Dispatcher .IInstanceTransaction
IInstanceContextManager	0.4	1 type	10 methods	System.ServiceModel.Dispatcher .IInstanceContextManager
ISessionThrottleNotification	1	1 type	1 method	System.ServiceModel.Dispatcher .ISessionThrottleNotification
IConfigurationContextProviderInternal	0.33	3 types	2 methods	System.ServiceModel.Configuration .IConfigurationContextProviderInternal
ILockingQueue	1	1 type	2 methods	System.ServiceModel.Channels .ILockingQueue
IChannelDemuxer	1	2 types	7 methods	System.ServiceModel.Channels .IChannelDemuxer
IChannelDemuxFailureHandler	0.16	11 types	4 methods	System.ServiceModel.Channels .IChannelDemuxFailureHandler
IChannelAcceptor<TChannel>	0	12 types	6 methods	System.ServiceModel.Channels .IChannelAcceptor<TChannel>
IRequestReplyCorrelator	0.17	6 types	2 methods	System.ServiceModel.Channels .IRequestReplyCorrelator
ICorrelatorKey	0.5	2 types	2 methods	System.ServiceModel.Channels .ICorrelatorKey
ICommunicationWaiter	0.75	2 types	2 methods	System.ServiceModel.Channels .ICommunicationWaiter
RemoteEndpointMessageProperty+IRemoteEnd pointProvider	0.5	2 types	2 methods	System.ServiceModel.Channels .RemoteEndpointMessageProperty+IRemoteEn dpointProvider
IRequestBase	0.33	1 type	3 methods	System.ServiceModel.Channels .IRequestBase
IRequest	0	3 types	2 methods	System.ServiceModel.Channels.IRequest
IAsyncRequest	0	3 types	2 methods	System.ServiceModel.Channels .IAsyncRequest
IConnectionOrientedListenerSettings	0	5 types	4 methods	System.ServiceModel.Channels .IConnectionOrientedListenerSettings
ITransportFactorySettings	0.2	16 types	5 methods	System.ServiceModel.Channels .ITransportFactorySettings
IConnectionOrientedTransportFactorySetti ngs	0.092	19 types	4 methods	System.ServiceModel.Channels .IConnectionOrientedTransportFactorySett ings
IConnectionOrientedTransportChannelFacto rySettings	0	6 types	2 methods	System.ServiceModel.Channels .IConnectionOrientedTransportChannelFact orySettings
ITcpChannelFactorySettings	0.5	2 types	1 method	System.ServiceModel.Channels .ITcpChannelFactorySettings
IHttpTransportFactorySettings	0.042	12 types	2 methods	System.ServiceModel.Channels .IHttpTransportFactorySettings
IPipeTransportFactorySettings	0.33	3 types	1 method	System.ServiceModel.Channels .IPipeTransportFactorySettings
ITransportManagerRegistration	0	7 types	3 methods	System.ServiceModel.Channels .ITransportManagerRegistration
IChannelBindingProvider	0.5	11 types	2 methods	System.ServiceModel.Channels .IChannelBindingProvider
IStreamUpgradeChannelBindingProvider	0.5	6 types	2 methods	System.ServiceModel.Channels .IStreamUpgradeChannelBindingProvider
IConnection	0.078	62 types	19 methods	System.ServiceModel.Channels.IConnection
IConnectionInitiator	0.095	7 types	3 methods	System.ServiceModel.Channels .IConnectionInitiator
IConnectionListener	0.12	8 types	3 methods	System.ServiceModel.Channels .IConnectionListener
IMessageSource	0.14	7 types	6 methods	System.ServiceModel.Channels .IMessageSource
ISingletonChannelListener	0.14	7 types	2 methods	System.ServiceModel.Channels .ISingletonChannelListener
ISocketListenerSettings	0.5	2 types	3 methods	System.ServiceModel.Channels .ISocketListenerSettings
HttpChannelListener+IHttpAuthenticationC ontext	0.38	2 types	4 methods	System.ServiceModel.Channels .HttpChannelListener+IHttpAuthentication Context
HttpRequestMessageProperty+IHttpHeaderPr ovider	0.25	4 types	1 method	System.ServiceModel.Channels .HttpRequestMessageProperty+IHttpHeaderP rovider
IWebMessageEncoderHelper	1	1 type	1 method	System.ServiceModel.Channels .IWebMessageEncoderHelper
ITransportPolicyImport	1	2 types	1 method	System.ServiceModel.Channels .ITransportPolicyImport
IPoisonHandlingStrategy	0.5	2 types	3 methods	System.ServiceModel.Channels .IPoisonHandlingStrategy
IMsmqMessagePool	0.25	4 types	2 methods	System.ServiceModel.Channels .IMsmqMessagePool
IPostRollbackErrorStrategy	1	2 types	1 method	System.ServiceModel.Channels .IPostRollbackErrorStrategy
MsmqUri+IAddressTranslator	0.29	26 types	3 methods	System.ServiceModel.Channels .MsmqUri+IAddressTranslator
IReliableChannelBinder	0.07	47 types	36 methods	System.ServiceModel.Channels .IReliableChannelBinder
IClientReliableChannelBinder	0.083	16 types	9 methods	System.ServiceModel.Channels .IClientReliableChannelBinder
IServerReliableChannelBinder	0.12	24 types	5 methods	System.ServiceModel.Channels .IServerReliableChannelBinder
IReliableFactorySettings	0.19	10 types	10 methods	System.ServiceModel.Channels .IReliableFactorySettings
DatagramAdapter+DatagramAdapterListenerB ase<TChannel,TSessionChannel,ItemType >+IWaiter	0	1 type	1 method	System.ServiceModel.Channels .DatagramAdapter+DatagramAdapterListener Base<TChannel,TSessionChannel,ItemType >+IWaiter
IMergeEnabledMessageProperty	1	1 type	1 method	System.ServiceModel.Channels .IMergeEnabledMessageProperty
IBufferedMessageData	0.27	10 types	9 methods	System.ServiceModel.Channels .IBufferedMessageData
ICompressedMessageEncoder	0.67	4 types	3 methods	System.ServiceModel.Channels .ICompressedMessageEncoder
ITransportCompressionSupport	0.33	3 types	1 method	System.ServiceModel.Channels .ITransportCompressionSupport
IPeerNeighbor	0.11	18 types	18 methods	System.ServiceModel.Channels .IPeerNeighbor
IPeerFactory	0.28	4 types	8 methods	System.ServiceModel.Channels .IPeerFactory
IFlooderForThrottle	0.5	1 type	2 methods	System.ServiceModel.Channels .IFlooderForThrottle
IPeerMaintainer	1	1 type	17 methods	System.ServiceModel.Channels .IPeerMaintainer
IConnectAlgorithms	1	1 type	4 methods	System.ServiceModel.Channels .IConnectAlgorithms
IPeerNodeMessageHandling	0.071	6 types	7 methods	System.ServiceModel.Channels .IPeerNodeMessageHandling
IPeerConnectorContract	0.5	2 types	4 methods	System.ServiceModel.Channels .IPeerConnectorContract
IPeerFlooderContract<TFloodContract ,TLinkContract>	0.5	2 types	3 methods	System.ServiceModel.Channels .IPeerFlooderContract<TFloodContract ,TLinkContract>
IPeerServiceContract	0.2	1 type	10 methods	System.ServiceModel.Channels .IPeerServiceContract
ITransactionChannel	0.25	1 type	4 methods	System.ServiceModel.Channels .ITransactionChannel
WSTrustDec2005+DriverDec2005+IWsTrustDec 2005SecurityTokenService	0	2 types	1 method	System.ServiceModel.Security .WSTrustDec2005+DriverDec2005+IWsTrustDe c2005SecurityTokenService
WSTrustFeb2005+DriverFeb2005+IWsTrustFeb 2005SecurityTokenService	0	2 types	1 method	System.ServiceModel.Security .WSTrustFeb2005+DriverFeb2005+IWsTrustFe b2005SecurityTokenService
IChannelSecureConversationSessionSetting s	0	1 type	6 methods	System.ServiceModel.Security .IChannelSecureConversationSessionSettin gs
IListenerSecureConversationSessionSettin gs	0	1 type	12 methods	System.ServiceModel.Security .IListenerSecureConversationSessionSetti ngs
ISecurityCommunicationObject	1	1 type	14 methods	System.ServiceModel.Security .ISecurityCommunicationObject
TimeBoundedCache+IExpirableItem	0.5	4 types	1 method	System.ServiceModel.Security .TimeBoundedCache+IExpirableItem
ISecurityContextSecurityTokenCacheProvid er	1	2 types	1 method	System.ServiceModel.Security.Tokens .ISecurityContextSecurityTokenCacheProvi der
IAspNetMessageProperty	0.17	6 types	4 methods	System.ServiceModel.Activation .IAspNetMessageProperty
IConnectionDuplicator	1	1 type	2 methods	System.ServiceModel.Activation .IConnectionDuplicator
IConnectionRegister	0.67	1 type	3 methods	System.ServiceModel.Activation .IConnectionRegister
IConnectionRegisterAsync	0.5	2 types	2 methods	System.ServiceModel.Activation .IConnectionRegisterAsync
ListenerUnsafeNativeMethods+ICorRuntimeH ost	0.045	2 types	11 methods	System.ServiceModel.Activation .ListenerUnsafeNativeMethods+ICorRuntime Host
IAnnouncementInnerClient	0.25	4 types	19 methods	System.ServiceModel.Discovery .IAnnouncementInnerClient
IAnnouncementServiceImplementation	0	6 types	5 methods	System.ServiceModel.Discovery .IAnnouncementServiceImplementation
IDiscoveryInnerClient	0.25	4 types	12 methods	System.ServiceModel.Discovery .IDiscoveryInnerClient
IDiscoveryInnerClientResponse	0.42	8 types	5 methods	System.ServiceModel.Discovery .IDiscoveryInnerClientResponse
IDiscoveryServiceImplementation	0	10 types	6 methods	System.ServiceModel.Discovery .IDiscoveryServiceImplementation
IDiscoveryVersionImplementation	0.14	10 types	11 methods	System.ServiceModel.Discovery .IDiscoveryVersionImplementation
IMulticastSuppressionImplementation	0	6 types	4 methods	System.ServiceModel.Discovery .IMulticastSuppressionImplementation
IAnnouncementContractCD1	0.5	2 types	6 methods	System.ServiceModel.Discovery.VersionCD1 .IAnnouncementContractCD1
IDiscoveryContractAdhocCD1	0.33	3 types	6 methods	System.ServiceModel.Discovery.VersionCD1 .IDiscoveryContractAdhocCD1
IDiscoveryContractManagedCD1	0.5	2 types	6 methods	System.ServiceModel.Discovery.VersionCD1 .IDiscoveryContractManagedCD1
IDiscoveryResponseContractCD1	0.67	2 types	6 methods	System.ServiceModel.Discovery.VersionCD1 .IDiscoveryResponseContractCD1
IAnnouncementContractApril2005	0.5	2 types	6 methods	System.ServiceModel.Discovery .VersionApril2005 .IAnnouncementContractApril2005
IDiscoveryContractApril2005	1	1 type	6 methods	System.ServiceModel.Discovery .VersionApril2005 .IDiscoveryContractApril2005
IDiscoveryResponseContractApril2005	0.67	2 types	6 methods	System.ServiceModel.Discovery .VersionApril2005 .IDiscoveryResponseContractApril2005
IAnnouncementContract11	0.5	2 types	6 methods	System.ServiceModel.Discovery.Version11 .IAnnouncementContract11
IDiscoveryContractAdhoc11	0.33	3 types	6 methods	System.ServiceModel.Discovery.Version11 .IDiscoveryContractAdhoc11
IDiscoveryContractManaged11	0.5	2 types	6 methods	System.ServiceModel.Discovery.Version11 .IDiscoveryContractManaged11
IDiscoveryResponseContract11	0.67	2 types	6 methods	System.ServiceModel.Discovery.Version11 .IDiscoveryResponseContract11
IUdpReceiveHandler	1	1 type	3 methods	System.ServiceModel.Channels .IUdpReceiveHandler
IServiceModelActivationHandler	0.5	2 types	1 method	System.ServiceModel.Activation .IServiceModelActivationHandler
IMSAdminBase	0.097	1 type	31 methods	System.ServiceModel.Activation .IMSAdminBase
ICanonicalizableNode	0.33	3 types	4 methods	System.Security.Cryptography.Xml .ICanonicalizableNode
IStorageFolderHandleAccess	1	1 type	1 method	System.IO.IStorageFolderHandleAccess
IStorageItemHandleAccess	1	1 type	1 method	System.IO.IStorageItemHandleAccess
IDispatcherQueue	0.17	2 types	3 methods	System.Threading.IDispatcherQueue
IBufferByteAccess	1	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime.IBufferByteAccess
IRestrictedErrorInfo	1	1 type	2 methods	System.Runtime.InteropServices .WindowsRuntime.IRestrictedErrorInfo
ISerParser	0.5	2 types	1 method	System.Runtime.Serialization.Formatters .Soap.ISerParser
IDataNode	0.15	10 types	18 methods	System.Runtime.Serialization.IDataNode
IGenericNameProvider	0	2 types	6 methods	System.Runtime.Serialization .IGenericNameProvider
IByteBufferPool	0.23	15 types	2 methods	System.IO.IByteBufferPool
WsdlParser+IDump	1	1 type	1 method	System.Runtime.Remoting.MetadataServices .WsdlParser+IDump
WsdlParser+INamespaces	0	1 type	1 method	System.Runtime.Remoting.MetadataServices .WsdlParser+INamespaces
ICancelable	1	1 type	1 method	System.Runtime.ICancelable
IPersistencePipelineModule	0.16	8 types	11 methods	System.Runtime .IPersistencePipelineModule
IDurableInstancingOptions	1	1 type	1 method	System.Runtime.DurableInstancing .IDurableInstancingOptions
IPersistStream	0	2 types	5 methods	System.Messaging.Interop.IPersistStream
IPersistStreamInit	0.17	1 type	6 methods	System.Messaging.Interop .IPersistStreamInit
IStream	0	2 types	11 methods	System.Messaging.Interop.IStream
ITransaction	0.17	4 types	3 methods	System.Messaging.Interop.ITransaction
IWbemPathKeyList	0.2	1 type	10 methods	WmiNative.IWbemPathKeyList
IWbemPath	0.15	1 type	26 methods	WmiNative.IWbemPath
IWbemDecoupledRegistrar	1	1 type	2 methods	WmiNative.IWbemDecoupledRegistrar
IWbemServices	0.043	1 type	23 methods	WmiNative.IWbemServices
IWbemClassObject	0.065	7 types	24 methods	WmiNative.IWbemClassObject
IWbemContext	0	4 types	9 methods	WmiNative.IWbemContext
IWbemProviderInitSink	0.5	2 types	1 method	WmiNative.IWbemProviderInitSink
IWbemObjectSink	0.33	3 types	2 methods	WmiNative.IWbemObjectSink
IEnumWbemClassObject	0	2 types	5 methods	WmiNative.IEnumWbemClassObject
IWbemQualifierSet	0.14	1 type	7 methods	WmiNative.IWbemQualifierSet
ICIMResultHandler	0.2	3 types	5 methods	System.Management.Instrumentation .ICIMResultHandler
ICIMQuery	0	1 type	1 method	System.Management.Instrumentation .ICIMQuery
ICIMEnumerate	0.5	2 types	1 method	System.Management.Instrumentation .ICIMEnumerate
ICIMGet	0.5	2 types	1 method	System.Management.Instrumentation .ICIMGet
ICIMDelete	0.5	2 types	1 method	System.Management.Instrumentation .ICIMDelete
ICIMUpdate	0.5	2 types	1 method	System.Management.Instrumentation .ICIMUpdate
ICIMExecute	0.5	2 types	1 method	System.Management.Instrumentation .ICIMExecute
ICIMCapabilities	0.83	1 type	6 methods	System.Management.Instrumentation .ICIMCapabilities
IWbemClassObject_DoNotMarshal	0	5 types	24 methods	System.Management .IWbemClassObject_DoNotMarshal
IWbemLocator	0	1 type	1 method	System.Management.IWbemLocator
IWbemContext	0.014	16 types	9 methods	System.Management.IWbemContext
IWbemServices	0.041	19 types	23 methods	System.Management.IWbemServices
IWbemCallResult	0.5	1 type	4 methods	System.Management.IWbemCallResult
IWbemObjectSink	0.11	9 types	2 methods	System.Management.IWbemObjectSink
IEnumWbemClassObject	0.053	15 types	5 methods	System.Management.IEnumWbemClassObject
IWbemObjectTextSrc	0.5	1 type	2 methods	System.Management.IWbemObjectTextSrc
IWbemStatusCodeText	0.5	1 type	2 methods	System.Management.IWbemStatusCodeText
IWbemProviderInitSink	1	1 type	1 method	System.Management.IWbemProviderInitSink
IWbemDecoupledRegistrar	1	1 type	2 methods	System.Management .IWbemDecoupledRegistrar
IWbemPathKeyList	0.2	1 type	10 methods	System.Management.IWbemPathKeyList
IWbemPath	0.46	1 type	26 methods	System.Management.IWbemPath
IMetaDataDispenser	0.33	1 type	3 methods	System.Management.Instrumentation .IMetaDataDispenser
IMetaDataImportInternalOnly	0.12	1 type	8 methods	System.Management.Instrumentation .IMetaDataImportInternalOnly
ILog	1	1 type	7 methods	System.IO.Log.ILog
IFileBasedLogInit	1	1 type	1 method	System.IO.Log.IFileBasedLogInit
ISspiNegotiation	0.1	11 types	8 methods	System.ServiceModel.Security .ISspiNegotiation
ISspiNegotiationInfo	1	1 type	1 method	System.ServiceModel.Security .ISspiNegotiationInfo
IPrefixGenerator	0	2 types	1 method	System.IdentityModel.IPrefixGenerator
ISecurityElement	0.29	7 types	3 methods	System.IdentityModel.ISecurityElement
ISignatureValueSecurityElement	0	5 types	1 method	System.IdentityModel .ISignatureValueSecurityElement
ICanonicalWriterEndRootElementCallback	1	1 type	1 method	System.IdentityModel .ICanonicalWriterEndRootElementCallback
IIdentityInfo	1	1 type	1 method	System.IdentityModel.Policy .IIdentityInfo
IClrStrongNameUsingIntPtr	0.24	1 type	25 methods	Microsoft.Runtime.Hosting .IClrStrongNameUsingIntPtr
IClrStrongName	0.36	1 type	25 methods	Microsoft.Runtime.Hosting.IClrStrongName
IGetContextProperties	0.33	1 type	3 methods	System.EnterpriseServices .IGetContextProperties
IContextProperties	0.2	1 type	5 methods	System.EnterpriseServices .IContextProperties
IObjectConstruct	0	1 type	1 method	System.EnterpriseServices .IObjectConstruct
IObjectConstructString	1	2 types	1 method	System.EnterpriseServices .IObjectConstructString
IObjectContext	0.12	2 types	8 methods	System.EnterpriseServices.IObjectContext
IObjectContextInfo	0.4	1 type	5 methods	System.EnterpriseServices .IObjectContextInfo
IObjectContextInfo2	0.38	1 type	8 methods	System.EnterpriseServices .IObjectContextInfo2
IObjectControl	0	2 types	3 methods	System.EnterpriseServices.IObjectControl
ITransactionProxy	0	1 type	7 methods	System.EnterpriseServices .ITransactionProxy
ITransactionVoterBallotAsync2	0	1 type	1 method	System.EnterpriseServices .ITransactionVoterBallotAsync2
ITransactionVoterNotifyAsync2	0.4	2 types	5 methods	System.EnterpriseServices .ITransactionVoterNotifyAsync2
ISharedProperty	0.5	2 types	2 methods	System.EnterpriseServices .ISharedProperty
ISharedPropertyGroup	0.5	2 types	4 methods	System.EnterpriseServices .ISharedPropertyGroup
ISharedPropertyGroupManager	1	1 type	3 methods	System.EnterpriseServices .ISharedPropertyGroupManager
IManagedObject	0	3 types	2 methods	System.EnterpriseServices.IManagedObject
IContext	0.33	1 type	3 methods	System.EnterpriseServices.IContext
IManagedObjectInfo	0	1 type	4 methods	System.EnterpriseServices .IManagedObjectInfo
ITransactionProperty	0.077	1 type	13 methods	System.EnterpriseServices .ITransactionProperty
ISecurityCallersColl	0.5	2 types	3 methods	System.EnterpriseServices .ISecurityCallersColl
ISecurityIdentityColl	0.11	3 types	3 methods	System.EnterpriseServices .ISecurityIdentityColl
ISecurityCallContext	0.33	2 types	6 methods	System.EnterpriseServices .ISecurityCallContext
IConfigurationAttribute	0.83	2 types	3 methods	System.EnterpriseServices .IConfigurationAttribute
ICreateTypeLib	0.1	1 type	10 methods	System.EnterpriseServices.ICreateTypeLib
IConfigCallback	1	1 type	6 methods	System.EnterpriseServices .IConfigCallback
ITransactionResourcePool	1	1 type	2 methods	System.EnterpriseServices .ITransactionResourcePool
ICreateWithTipTransactionEx	1	1 type	1 method	System.EnterpriseServices .ICreateWithTipTransactionEx
ICreateWithTransactionEx	1	1 type	1 method	System.EnterpriseServices .ICreateWithTransactionEx
ICreateWithLocalTransaction	1	1 type	1 method	System.EnterpriseServices .ICreateWithLocalTransaction
IAssemblyCache	0.4	1 type	5 methods	System.EnterpriseServices.Internal .IAssemblyCache
ITypeLib2	0.071	1 type	14 methods	System.EnterpriseServices.Internal .ITypeLib2
IFormatLogRecords	1	1 type	3 methods	System.EnterpriseServices .CompensatingResourceManager .IFormatLogRecords
_IMonitorClerks	0.43	2 types	7 methods	System.EnterpriseServices .CompensatingResourceManager ._IMonitorClerks
ICatalog	0.12	1 type	26 methods	System.EnterpriseServices.Admin.ICatalog
ICatalogObject	0.21	29 types	7 methods	System.EnterpriseServices.Admin .ICatalogObject
ICatalogCollection	0.26	7 types	16 methods	System.EnterpriseServices.Admin .ICatalogCollection
IThunkInstallation	1	1 type	1 method	System.EnterpriseServices.Thunk .IThunkInstallation
IProxyInvoke	0.5	1 type	2 methods	System.EnterpriseServices.Thunk .IProxyInvoke
IDispatch	0.21	6 types	4 methods	System.Dynamic.IDispatch
IProvideClassInfo	1	1 type	1 method	System.Dynamic.IProvideClassInfo
ISystemColorTracker	1	1 type	1 method	System.Drawing.Internal .ISystemColorTracker
UnsafeNativeMethods+IMarshal	0	1 type	6 methods	Microsoft.Win32 .UnsafeNativeMethods+IMarshal
IInternetSecurityManager	0.12	2 types	8 methods	Microsoft.Win32.IInternetSecurityManager
IAuthenticationManager	1	1 type	14 methods	System.Net.IAuthenticationManager
IWebProxyFinder	1	1 type	4 methods	System.Net.IWebProxyFinder
IRequestLifetimeTracker	1	1 type	1 method	System.Net.IRequestLifetimeTracker
ISessionAuthenticationModule	0.67	1 type	3 methods	System.Net.ISessionAuthenticationModule
ICloseEx	1	6 types	1 method	System.Net.ICloseEx
SSPIInterface	0.2	5 types	21 methods	System.Net.SSPIInterface
IAutoWebProxy	1	1 type	1 method	System.Net.IAutoWebProxy
IEncodableStream	0.42	3 types	4 methods	System.Net.Mime.IEncodableStream
IMSAdminBase	0.13	1 type	31 methods	System.Net.Mail.IMSAdminBase
ISmtpAuthenticationModule	0.4	5 types	3 methods	System.Net.Mail .ISmtpAuthenticationModule
INotifyCollectionChangedEventArgs	1	1 type	5 methods	System.Runtime.InteropServices .WindowsRuntime .INotifyCollectionChangedEventArgs
IPropertyChangedEventArgs	1	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime .IPropertyChangedEventArgs
INotifyCollectionChanged_WinRT	1	1 type	2 methods	System.Runtime.InteropServices .WindowsRuntime .INotifyCollectionChanged_WinRT
INotifyPropertyChanged_WinRT	1	1 type	2 methods	System.Runtime.InteropServices .WindowsRuntime .INotifyPropertyChanged_WinRT
ICommand_WinRT	1	1 type	4 methods	System.Runtime.InteropServices .WindowsRuntime.ICommand_WinRT
IDeflater	1	1 type	4 methods	System.IO.Compression.IDeflater
IInflater	0.6	1 type	5 methods	System.IO.Compression.IInflater
IFileFormatWriter	0.5	2 types	3 methods	System.IO.Compression.IFileFormatWriter
IFileFormatReader	0.33	3 types	4 methods	System.IO.Compression.IFileFormatReader
NativeComInterfaces+IAdsPathname	0.21	7 types	11 methods	System.DirectoryServices.ActiveDirectory .NativeComInterfaces+IAdsPathname
NativeComInterfaces+IAdsProperty	0.042	2 types	24 methods	System.DirectoryServices.ActiveDirectory .NativeComInterfaces+IAdsProperty
NativeComInterfaces+IAdsClass	0.058	2 types	43 methods	System.DirectoryServices.ActiveDirectory .NativeComInterfaces+IAdsClass
ILocationReport	0.67	1 type	3 methods	System.Device.Location.Internal .ILocationReport
ILatLongReport	0.62	1 type	8 methods	System.Device.Location.Internal .ILatLongReport
ILocation	0.67	1 type	9 methods	System.Device.Location.Internal .ILocation
IWizardStepEditableRegion	1	2 types	1 method	System.Web.UI.Design.WebControls .IWizardStepEditableRegion
IDesignConnection	0.046	14 types	14 methods	System.Data.Design.IDesignConnection
IDataSourceNamedObject	0	5 types	1 method	System.Data.Design .IDataSourceNamedObject
IDataSourceXmlSerializable	1	1 type	2 methods	System.Data.Design .IDataSourceXmlSerializable
IDataSourceXmlSpecialOwner	1	1 type	2 methods	System.Data.Design .IDataSourceXmlSpecialOwner
IDataSourceInitAfterLoading	1	1 type	1 method	System.Data.Design .IDataSourceInitAfterLoading
INamedObject	0.5	4 types	2 methods	System.Data.Design.INamedObject
INamedObjectCollection	0	3 types	1 method	System.Data.Design .INamedObjectCollection
INameService	0.083	8 types	6 methods	System.Data.Design.INameService
IEventHandlerService	0.18	11 types	6 methods	System.Windows.Forms.Design .IEventHandlerService
IMenuStatusHandler	1	1 type	2 methods	System.Windows.Forms.Design .IMenuStatusHandler
IMouseHandler	0.5	2 types	6 methods	System.Windows.Forms.Design .IMouseHandler
IOleDragClient	0.33	4 types	6 methods	System.Windows.Forms.Design .IOleDragClient
IOverlayService	0.32	5 types	5 methods	System.Windows.Forms.Design .IOverlayService
ISelectionUIHandler	0.5	2 types	13 methods	System.Windows.Forms.Design .ISelectionUIHandler
ISelectionUIService	0.11	5 types	20 methods	System.Windows.Forms.Design .ISelectionUIService
ISplitWindowService	0.5	2 types	2 methods	System.Windows.Forms.Design .ISplitWindowService
ISupportInSituService	0.33	3 types	3 methods	System.Windows.Forms.Design .ISupportInSituService
IClrStrongNameUsingIntPtr	0.24	1 type	25 methods	Microsoft.Runtime.Hosting .IClrStrongNameUsingIntPtr
IClrStrongName	0.36	1 type	25 methods	Microsoft.Runtime.Hosting.IClrStrongName
IEnumSTORE_ASSEMBLY_INSTALLATION_REFEREN CE	0	1 type	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_INSTALLATION_REFERE NCE
IEnumSTORE_DEPLOYMENT_METADATA	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA
IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY
IEnumSTORE_ASSEMBLY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY
IEnumSTORE_ASSEMBLY_FILE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_FILE
IEnumSTORE_CATEGORY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY
IEnumSTORE_CATEGORY_SUBCATEGORY	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_SUBCATEGORY
IEnumSTORE_CATEGORY_INSTANCE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_INSTANCE
IReferenceIdentity	0.12	13 types	4 methods	System.Deployment.Internal.Isolation .IReferenceIdentity
IDefinitionIdentity	0.083	18 types	4 methods	System.Deployment.Internal.Isolation .IDefinitionIdentity
IEnumIDENTITY_ATTRIBUTE	0.2	2 types	5 methods	System.Deployment.Internal.Isolation .IEnumIDENTITY_ATTRIBUTE
IEnumDefinitionIdentity	0.25	4 types	4 methods	System.Deployment.Internal.Isolation .IEnumDefinitionIdentity
IEnumReferenceIdentity	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumReferenceIdentity
IDefinitionAppId	0.083	20 types	6 methods	System.Deployment.Internal.Isolation .IDefinitionAppId
IReferenceAppId	0.2	5 types	5 methods	System.Deployment.Internal.Isolation .IReferenceAppId
IIdentityAuthority	0.22	3 types	18 methods	System.Deployment.Internal.Isolation .IIdentityAuthority
IAppIdAuthority	0.16	2 types	16 methods	System.Deployment.Internal.Isolation .IAppIdAuthority
IStore	0.19	5 types	20 methods	System.Deployment.Internal.Isolation .IStore
IManifestParseErrorCallback	0	2 types	1 method	System.Deployment.Internal.Isolation .IManifestParseErrorCallback
IManifestInformation	0.5	2 types	1 method	System.Deployment.Internal.Isolation .IManifestInformation
IActContext	0.22	3 types	18 methods	System.Deployment.Internal.Isolation .IActContext
IStateManager	0.25	1 type	4 methods	System.Deployment.Internal.Isolation .IStateManager
ISection	0.21	7 types	4 methods	System.Deployment.Internal.Isolation .ISection
ISectionWithStringKey	0.5	1 type	2 methods	System.Deployment.Internal.Isolation .ISectionWithStringKey
ISectionWithReferenceIdentityKey	1	1 type	1 method	System.Deployment.Internal.Isolation .ISectionWithReferenceIdentityKey
ISectionEntry	0	1 type	2 methods	System.Deployment.Internal.Isolation .ISectionEntry
IEnumUnknown	0.25	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumUnknown
ICMS	0.064	5 types	22 methods	System.Deployment.Internal.Isolation .Manifest.ICMS
IHashElementEntry	0.14	2 types	7 methods	System.Deployment.Internal.Isolation .Manifest.IHashElementEntry
IFileEntry	0.067	1 type	15 methods	System.Deployment.Internal.Isolation .Manifest.IFileEntry
IFileAssociationEntry	0.17	1 type	6 methods	System.Deployment.Internal.Isolation .Manifest.IFileAssociationEntry
IAssemblyReferenceEntry	0.25	1 type	4 methods	System.Deployment.Internal.Isolation .Manifest.IAssemblyReferenceEntry
IEntryPointEntry	0.17	1 type	6 methods	System.Deployment.Internal.Isolation .Manifest.IEntryPointEntry
IDescriptionMetadataEntry	0.14	1 type	7 methods	System.Deployment.Internal.Isolation .Manifest.IDescriptionMetadataEntry
IDeploymentMetadataEntry	0.17	1 type	6 methods	System.Deployment.Internal.Isolation .Manifest.IDeploymentMetadataEntry
IDependentOSMetadataEntry	0.12	1 type	8 methods	System.Deployment.Internal.Isolation .Manifest.IDependentOSMetadataEntry
ICompatibleFrameworksMetadataEntry	0.5	1 type	2 methods	System.Deployment.Internal.Isolation .Manifest .ICompatibleFrameworksMetadataEntry
IMetadataSectionEntry	0.33	1 type	21 methods	System.Deployment.Internal.Isolation .Manifest.IMetadataSectionEntry
ICompatibleFrameworkEntry	0.2	1 type	5 methods	System.Deployment.Internal.Isolation .Manifest.ICompatibleFrameworkEntry
IManagedDeploymentServiceCom	0	2 types	7 methods	System.Deployment.Application .IManagedDeploymentServiceCom
IDownloadNotification	0	2 types	2 methods	System.Deployment.Application .IDownloadNotification
IMetaDataDispenser	0.33	1 type	3 methods	System.Deployment.Application .IMetaDataDispenser
IMetaDataImport	0	1 type	62 methods	System.Deployment.Application .IMetaDataImport
IMetaDataAssemblyImport	0.5	1 type	14 methods	System.Deployment.Application .IMetaDataAssemblyImport
NativeMethods+IAssemblyCache	0.05	4 types	5 methods	System.Deployment.Application .NativeMethods+IAssemblyCache
NativeMethods+IAssemblyEnum	0.17	2 types	3 methods	System.Deployment.Application .NativeMethods+IAssemblyEnum
NativeMethods+IApplicationContext	0	2 types	5 methods	System.Deployment.Application .NativeMethods+IApplicationContext
NativeMethods+IAssemblyName	0	2 types	9 methods	System.Deployment.Application .NativeMethods+IAssemblyName
NativeMethods+ICorRuntimeHost	0.026	2 types	19 methods	System.Deployment.Application .NativeMethods+ICorRuntimeHost
ISourceLineInfo	0.22	18 types	4 methods	System.Xml.Xsl.ISourceLineInfo
IErrorHelper	0.38	4 types	2 methods	System.Xml.Xsl.IErrorHelper
IXPathBuilder<Node>	0.6	3 types	10 methods	System.Xml.Xsl.XPath.IXPathBuilder<Node>
IFocus	0.5	2 types	3 methods	System.Xml.Xsl.XPath.IFocus
IXPathEnvironment	0.38	2 types	4 methods	System.Xml.Xsl.XPath.IXPathEnvironment
IQilAnnotation	1	1 type	1 method	System.Xml.Xsl.Qil.IQilAnnotation
RecordOutput	0.2	5 types	2 methods	System.Xml.Xsl.XsltOld.RecordOutput
IStackFrame	0	1 type	5 methods	System.Xml.Xsl.XsltOld.Debugger .IStackFrame
IXsltProcessor	0	1 type	2 methods	System.Xml.Xsl.XsltOld.Debugger .IXsltProcessor
IXsltDebugger	0.12	8 types	3 methods	System.Xml.Xsl.XsltOld.Debugger .IXsltDebugger
IDataService	0.12	28 types	15 methods	System.Data.Services.IDataService
IProjectedResult	0.5	2 types	2 methods	System.Data.Services.IProjectedResult
OperationSignatures+ILogicalSignatures	0	2 types	3 methods	System.Data.Services.Parsing .OperationSignatures+ILogicalSignatures
OperationSignatures+IArithmeticSignature s	0	2 types	11 methods	System.Data.Services.Parsing .OperationSignatures+IArithmeticSignatur es
OperationSignatures+IRelationalSignature s	0	2 types	9 methods	System.Data.Services.Parsing .OperationSignatures+IRelationalSignatur es
OperationSignatures+INegationSignatures	0	2 types	11 methods	System.Data.Services.Parsing .OperationSignatures+INegationSignatures
OperationSignatures+INotSignatures	0	2 types	3 methods	System.Data.Services.Parsing .OperationSignatures+INotSignatures
OperationSignatures+IEnumerableSignature s	0	1 type	28 methods	System.Data.Services.Parsing .OperationSignatures+IEnumerableSignatur es
IExceptionWriter	0.5	2 types	1 method	System.Data.Services.Serializers .IExceptionWriter
IProjectionProvider	0.5	2 types	1 method	System.Data.Services.Providers .IProjectionProvider
IDataServices	0.21	8 types	7 methods	System.Data.Linq.Provider.IDataServices
IDeferredSourceFactory	0.25	2 types	2 methods	System.Data.Linq.Provider .IDeferredSourceFactory
IProvider	0.14	10 types	18 methods	System.Data.Linq.Provider.IProvider
ICompiledQuery	0.67	3 types	1 method	System.Data.Linq.Provider.ICompiledQuery
IConnectionManager	0.25	2 types	2 methods	System.Data.Linq.SqlClient .IConnectionManager
IConnectionUser	1	1 type	1 method	System.Data.Linq.SqlClient .IConnectionUser
IObjectReader	0.33	3 types	1 method	System.Data.Linq.SqlClient.IObjectReader
IObjectReaderSession	0.17	6 types	2 methods	System.Data.Linq.SqlClient .IObjectReaderSession
IReaderProvider	0.17	3 types	2 methods	System.Data.Linq.SqlClient .IReaderProvider
IObjectReaderFactory	0.14	7 types	2 methods	System.Data.Linq.SqlClient .IObjectReaderFactory
IObjectReaderCompiler	1	1 type	2 methods	System.Data.Linq.SqlClient .IObjectReaderCompiler
ICompiledSubQuery	0	6 types	1 method	System.Data.Linq.SqlClient .ICompiledSubQuery
IEntityStateManager	0.3	4 types	5 methods	System.Data.IEntityStateManager
IEntityStateEntry	0.11	25 types	14 methods	System.Data.IEntityStateEntry
IEntityAdapter	0.33	3 types	7 methods	System.Data.IEntityAdapter
ISqlFragment	0.33	3 types	1 method	System.Data.SqlClient.SqlGen .ISqlFragment
IDbSpatialValue	0.5	4 types	8 methods	System.Data.SqlClient.Internal .IDbSpatialValue
IObjectView	1	1 type	2 methods	System.Data.Objects.IObjectView
IObjectViewData<T>	0.33	3 types	13 methods	System.Data.Objects.IObjectViewData<T>
IChangeTrackingStrategy	0	4 types	4 methods	System.Data.Objects.Internal .IChangeTrackingStrategy
IEntityKeyStrategy	0	4 types	3 methods	System.Data.Objects.Internal .IEntityKeyStrategy
IPropertyAccessorStrategy	0	4 types	5 methods	System.Data.Objects.Internal .IPropertyAccessorStrategy
IEntityWrapper	0.13	21 types	29 methods	System.Data.Objects.Internal .IEntityWrapper
IRelationshipFixer	0.33	3 types	1 method	System.Data.Objects.DataClasses .IRelationshipFixer
IBaseList<T>	0.18	19 types	3 methods	System.Data.Metadata.Edm.IBaseList<T>
ITileQuery	1	1 type	1 method	System.Data.Mapping.ViewGeneration .QueryRewriting.ITileQuery
IRelationship	0.24	9 types	7 methods	System.Data.EntityModel .SchemaObjectModel.IRelationship
IRelationshipEnd	0.3	10 types	5 methods	System.Data.EntityModel .SchemaObjectModel.IRelationshipEnd
ISchemaElementLookUpTable<T>	0.25	4 types	5 methods	System.Data.EntityModel .SchemaObjectModel .ISchemaElementLookUpTable<T>
IGroupExpressionExtendedInfo	1	1 type	2 methods	System.Data.Common.EntitySql .IGroupExpressionExtendedInfo
IGetAlternativeName	1	1 type	1 method	System.Data.Common.EntitySql .IGetAlternativeName
ITypedGetters	0	3 types	35 methods	Microsoft.SqlServer.Server.ITypedGetters
ITypedGettersV3	0.11	10 types	17 methods	Microsoft.SqlServer.Server .ITypedGettersV3
ITypedSettersV3	0.2	5 types	17 methods	Microsoft.SqlServer.Server .ITypedSettersV3
IXmlDataVirtualNode	0.75	1 type	4 methods	System.Xml.IXmlDataVirtualNode
IFilter	0.11	9 types	1 method	System.Data.IFilter
NativeMethods+ISourcesRowset	0.5	2 types	1 method	System.Data.Common .NativeMethods+ISourcesRowset
NativeMethods+ITransactionJoin	0.17	3 types	2 methods	System.Data.Common .NativeMethods+ITransactionJoin
UnsafeNativeMethods+ADORecordConstructio n	0.5	2 types	1 method	System.Data.Common .UnsafeNativeMethods+ADORecordConstructi on
UnsafeNativeMethods+ADORecordsetConstruc tion	0.33	2 types	3 methods	System.Data.Common .UnsafeNativeMethods+ADORecordsetConstru ction
UnsafeNativeMethods+Recordset15	0.027	2 types	55 methods	System.Data.Common .UnsafeNativeMethods+Recordset15
UnsafeNativeMethods+_ADORecord	0.031	2 types	16 methods	System.Data.Common .UnsafeNativeMethods+_ADORecord
UnsafeNativeMethods+IAccessor	0.1	5 types	4 methods	System.Data.Common .UnsafeNativeMethods+IAccessor
UnsafeNativeMethods+IChapteredRowset	0.25	2 types	2 methods	System.Data.Common .UnsafeNativeMethods+IChapteredRowset
UnsafeNativeMethods+IColumnsInfo	0.33	3 types	1 method	System.Data.Common .UnsafeNativeMethods+IColumnsInfo
UnsafeNativeMethods+IColumnsRowset	0.33	3 types	2 methods	System.Data.Common .UnsafeNativeMethods+IColumnsRowset
UnsafeNativeMethods+ICommandPrepare	0.5	2 types	1 method	System.Data.Common .UnsafeNativeMethods+ICommandPrepare
UnsafeNativeMethods+ICommandProperties	0.33	3 types	2 methods	System.Data.Common .UnsafeNativeMethods+ICommandProperties
UnsafeNativeMethods+ICommandText	0.15	4 types	5 methods	System.Data.Common .UnsafeNativeMethods+ICommandText
UnsafeNativeMethods+ICommandWithParamete rs	0.17	2 types	3 methods	System.Data.Common .UnsafeNativeMethods+ICommandWithParamet ers
UnsafeNativeMethods+IDBInfo	0.25	4 types	2 methods	System.Data.Common .UnsafeNativeMethods+IDBInfo
UnsafeNativeMethods+IDBProperties	0.14	7 types	3 methods	System.Data.Common .UnsafeNativeMethods+IDBProperties
UnsafeNativeMethods+IDBSchemaRowset	0.2	5 types	2 methods	System.Data.Common .UnsafeNativeMethods+IDBSchemaRowset
UnsafeNativeMethods+IErrorInfo	0.21	8 types	3 methods	System.Data.Common .UnsafeNativeMethods+IErrorInfo
UnsafeNativeMethods+IErrorRecords	0.17	3 types	6 methods	System.Data.Common .UnsafeNativeMethods+IErrorRecords
UnsafeNativeMethods+IMultipleResults	0.33	3 types	1 method	System.Data.Common .UnsafeNativeMethods+IMultipleResults
UnsafeNativeMethods+IOpenRowset	0.33	3 types	1 method	System.Data.Common .UnsafeNativeMethods+IOpenRowset
UnsafeNativeMethods+IRow	0.5	2 types	1 method	System.Data.Common .UnsafeNativeMethods+IRow
UnsafeNativeMethods+IRowset	0.2	3 types	5 methods	System.Data.Common .UnsafeNativeMethods+IRowset
UnsafeNativeMethods+IRowsetInfo	0.33	3 types	2 methods	System.Data.Common .UnsafeNativeMethods+IRowsetInfo
UnsafeNativeMethods+ISQLErrorInfo	0.5	2 types	1 method	System.Data.Common .UnsafeNativeMethods+ISQLErrorInfo
UnsafeNativeMethods+ITransactionLocal	0.05	4 types	5 methods	System.Data.Common .UnsafeNativeMethods+ITransactionLocal
ICngSymmetricAlgorithm	1	1 type	13 methods	Internal.Cryptography .ICngSymmetricAlgorithm
IIListProvider<TElement>	0.33	1 type	3 methods	System.Linq.IIListProvider<TElement>
IParallelPartitionable<T>	1	1 type	1 method	System.Linq.Parallel .IParallelPartitionable<T>
IMergeHelper<TInputOutput>	1	1 type	3 methods	System.Linq.Parallel.IMergeHelper <TInputOutput>
IPartitionedStreamRecipient<TElement>	0.94	34 types	1 method	System.Linq.Parallel .IPartitionedStreamRecipient<TElement>
IAttributedImport	0.33	3 types	6 methods	System.ComponentModel.Composition .IAttributedImport
IReflectionPartCreationInfo	0.33	3 types	8 methods	System.ComponentModel.Composition .ReflectionModel .IReflectionPartCreationInfo
IPartCreatorImportDefinition	1	5 types	1 method	System.ComponentModel.Composition .Primitives.IPartCreatorImportDefinition
FilteredCatalog+IComposablePartCatalogTr aversal	1	1 type	2 methods	System.ComponentModel.Composition .Hosting .FilteredCatalog+IComposablePartCatalogT raversal
IActivityDelegateFactory	1	1 type	2 methods	System.Activities.Presentation .IActivityDelegateFactory
IExpandChild	0	1 type	1 method	System.Activities.Presentation .IExpandChild
IAutoSplitContainer	1	1 type	2 methods	System.Activities.Presentation .FreeFormEditing.IAutoSplitContainer
INestedFreeFormPanelContainer	0.75	2 types	2 methods	System.Activities.Presentation .FreeFormEditing .INestedFreeFormPanelContainer
IAutoConnectContainer	0.33	3 types	2 methods	System.Activities.Presentation .FreeFormEditing.IAutoConnectContainer
IAnnotationVisualProvider	0.25	4 types	3 methods	System.Activities.Presentation .Annotations.IAnnotationVisualProvider
IAnnotationIndicator	0.2	5 types	4 methods	System.Activities.Presentation .Annotations.IAnnotationIndicator
IDockedAnnotation	0.25	4 types	5 methods	System.Activities.Presentation .Annotations.IDockedAnnotation
IFloatingAnnotation	0.23	4 types	13 methods	System.Activities.Presentation .Annotations.IFloatingAnnotation
IValidationErrorSourceLocator	0.33	3 types	2 methods	System.Activities.Presentation .Validation .IValidationErrorSourceLocator
IItemsCollection	0.5	1 type	4 methods	System.Activities.Presentation.Model .IItemsCollection
IModelTreeItem	0.14	27 types	12 methods	System.Activities.Presentation.Model .IModelTreeItem
IPropertyViewManager	0.22	3 types	6 methods	System.Activities.Presentation.Internal .PropertyEditing.Views .IPropertyViewManager
ISelectionPathInterpreter	1	1 type	2 methods	System.Activities.Presentation.Internal .PropertyEditing.Selection .ISelectionPathInterpreter
ISelectionStop	0.27	6 types	5 methods	System.Activities.Presentation.Internal .PropertyEditing.Selection .ISelectionStop
IStateContainer	1	1 type	2 methods	System.Activities.Presentation.Internal .PropertyEditing.State.IStateContainer
IAutomationFocusChangedEventSource	1	2 types	1 method	System.Activities.Presentation.Internal .PropertyEditing.Automation .IAutomationFocusChangedEventSource
IMessageLogger	0.22	3 types	3 methods	System.Activities.Presentation.Internal .PropertyEditing.FromExpression .Framework.IMessageLogger
IIconProvider	1	1 type	1 method	System.Activities.Presentation.Internal .PropertyEditing.FromExpression .Framework.ValueEditors.IIconProvider
IPropertyInspector	0.25	2 types	2 methods	System.Activities.Presentation.Internal .PropertyEditing.FromExpression .Framework.PropertyInspector .IPropertyInspector
IVersionEditor	1	1 type	1 method	System.Activities.Presentation.View .IVersionEditor
ITreeViewItemSelectionHandler	0.5	3 types	2 methods	System.Activities.Presentation.View .TreeView.ITreeViewItemSelectionHandler
IWorkflowDesignerXamlHelperExecutionCont ext	1	1 type	10 methods	Microsoft.Activities.Presentation.Xaml .IWorkflowDesignerXamlHelperExecutionCon text
ILoadRetryStrategy	0.5	2 types	1 method	System.Activities.DurableInstancing .ILoadRetryStrategy
IObjectSerializer	0.35	5 types	4 methods	System.Activities.DurableInstancing .IObjectSerializer
IAsyncCodeActivity	1	1 type	1 method	System.Activities.IAsyncCodeActivity
IDynamicActivity	0.33	2 types	3 methods	System.Activities.IDynamicActivity
ILocationReferenceExpression	1	1 type	1 method	System.Activities.Expressions .ILocationReferenceExpression
ILocationReferenceWrapper	1	3 types	1 method	System.Activities.Expressions .ILocationReferenceWrapper
DynamicUpdateMapBuilder+IDefinitionMatch er	0.25	4 types	4 methods	System.Activities.DynamicUpdate .DynamicUpdateMapBuilder+IDefinitionMatc her
IInstanceUpdatable	1	1 type	1 method	System.Activities.DynamicUpdate .IInstanceUpdatable
IFlowSwitch	1	1 type	2 methods	System.Activities.Statements.IFlowSwitch
ICaseKeyBoxView	0.88	1 type	8 methods	System.Activities.Core.Presentation .ICaseKeyBoxView
IFlowSwitchLink	0.33	2 types	9 methods	System.Activities.Core.Presentation .IFlowSwitchLink
IFlowSwitchDefaultLink	1	1 type	2 methods	System.Activities.Core.Presentation .IFlowSwitchDefaultLink
IActivationService	0.5	2 types	5 methods	System.ServiceModel.Activation .IActivationService
IActivatedMessageQueue	0.33	3 types	9 methods	System.ServiceModel.Activation .IActivatedMessageQueue
ICreateITypeLib	0.1	1 type	10 methods	Microsoft.Tools.RegAsm.ICreateITypeLib
IAssemblyEnum	0.17	2 types	3 methods	Microsoft.Win32.IAssemblyEnum
IApplicationContext	0	2 types	5 methods	Microsoft.Win32.IApplicationContext
IAssemblyName	0.056	2 types	9 methods	Microsoft.Win32.IAssemblyName
IClrStrongNameUsingIntPtr	0.24	1 type	25 methods	Microsoft.Runtime.Hosting .IClrStrongNameUsingIntPtr
IClrStrongName	0.36	1 type	25 methods	Microsoft.Runtime.Hosting.IClrStrongName
IAsyncCausalityTracerStatics	0.86	1 type	7 methods	Windows.Foundation.Diagnostics .IAsyncCausalityTracerStatics
IWellKnownStringEqualityComparer	1	1 type	2 methods	System.IWellKnownStringEqualityComparer
IRuntimeMethodInfo	0.24	21 types	1 method	System.IRuntimeMethodInfo
IRuntimeFieldInfo	0.67	6 types	1 method	System.IRuntimeFieldInfo
IResourceGroveler	1	1 type	2 methods	System.Resources.IResourceGroveler
ISecurityElementFactory	0.5	2 types	4 methods	System.Security.ISecurityElementFactory
IBuiltInPermission	1	1 type	1 method	System.Security.Permissions .IBuiltInPermission
IUnionSemanticCodeGroup	0	1 type	1 method	System.Security.Policy .IUnionSemanticCodeGroup
ILegacyEvidenceAdapter	1	1 type	2 methods	System.Security.Policy .ILegacyEvidenceAdapter
IDelayEvaluatedEvidence	0.33	8 types	3 methods	System.Security.Policy .IDelayEvaluatedEvidence
IReportMatchMembershipCondition	1	2 types	1 method	System.Security.Policy .IReportMatchMembershipCondition
IRuntimeEvidenceFactory	0.5	2 types	3 methods	System.Security.Policy .IRuntimeEvidenceFactory
Tokenizer+ITokenReader	1	1 type	1 method	System.Security.Util .Tokenizer+ITokenReader
IAsyncLocal	0.11	9 types	1 method	System.Threading.IAsyncLocal
IAsyncLocalValueMap	0.5	3 types	2 methods	System.Threading.IAsyncLocalValueMap
IDeferredDisposable	1	1 type	1 method	System.Threading.IDeferredDisposable
IThreadPoolWorkItem	0.12	8 types	2 methods	System.Threading.IThreadPoolWorkItem
ITaskCompletionAction	0.67	3 types	1 method	System.Threading.Tasks .ITaskCompletionAction
IProducerConsumerQueue<T>	0.25	4 types	5 methods	System.Threading.Tasks .IProducerConsumerQueue<T>
ISection	0.083	6 types	4 methods	System.Deployment.Internal.Isolation .ISection
ISectionWithStringKey	0.5	1 type	2 methods	System.Deployment.Internal.Isolation .ISectionWithStringKey
ISectionWithReferenceIdentityKey	1	1 type	1 method	System.Deployment.Internal.Isolation .ISectionWithReferenceIdentityKey
ISectionEntry	0	2 types	2 methods	System.Deployment.Internal.Isolation .ISectionEntry
IEnumUnknown	0.25	1 type	4 methods	System.Deployment.Internal.Isolation .IEnumUnknown
IEnumSTORE_ASSEMBLY_INSTALLATION_REFEREN CE	0	1 type	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_INSTALLATION_REFERE NCE
IEnumSTORE_DEPLOYMENT_METADATA	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA
IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_DEPLOYMENT_METADATA_PROPERTY
IEnumSTORE_ASSEMBLY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY
IEnumSTORE_ASSEMBLY_FILE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_ASSEMBLY_FILE
IEnumSTORE_CATEGORY	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY
IEnumSTORE_CATEGORY_SUBCATEGORY	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_SUBCATEGORY
IEnumSTORE_CATEGORY_INSTANCE	0.17	3 types	4 methods	System.Deployment.Internal.Isolation .IEnumSTORE_CATEGORY_INSTANCE
IReferenceIdentity	0	5 types	4 methods	System.Deployment.Internal.Isolation .IReferenceIdentity
IDefinitionIdentity	0.021	12 types	4 methods	System.Deployment.Internal.Isolation .IDefinitionIdentity
IEnumDefinitionIdentity	0.25	2 types	4 methods	System.Deployment.Internal.Isolation .IEnumDefinitionIdentity
IDefinitionAppId	0.046	18 types	6 methods	System.Deployment.Internal.Isolation .IDefinitionAppId
IReferenceAppId	0	2 types	5 methods	System.Deployment.Internal.Isolation .IReferenceAppId
IIdentityAuthority	0.028	2 types	18 methods	System.Deployment.Internal.Isolation .IIdentityAuthority
IAppIdAuthority	0.062	4 types	16 methods	System.Deployment.Internal.Isolation .IAppIdAuthority
IStore	0.19	5 types	20 methods	System.Deployment.Internal.Isolation .IStore
IManifestParseErrorCallback	0	2 types	1 method	System.Deployment.Internal.Isolation .IManifestParseErrorCallback
IManifestInformation	0.5	2 types	1 method	System.Deployment.Internal.Isolation .IManifestInformation
IActContext	0.14	2 types	18 methods	System.Deployment.Internal.Isolation .IActContext
ICMS	0.053	6 types	22 methods	System.Deployment.Internal.Isolation .Manifest.ICMS
IAssemblyReferenceDependentAssemblyEntry	0.091	1 type	11 methods	System.Deployment.Internal.Isolation .Manifest .IAssemblyReferenceDependentAssemblyEntr y
IAssemblyReferenceEntry	0.25	1 type	4 methods	System.Deployment.Internal.Isolation .Manifest.IAssemblyReferenceEntry
IEntryPointEntry	0.17	1 type	6 methods	System.Deployment.Internal.Isolation .Manifest.IEntryPointEntry
IPermissionSetEntry	0.33	1 type	3 methods	System.Deployment.Internal.Isolation .Manifest.IPermissionSetEntry
IDescriptionMetadataEntry	0.14	1 type	7 methods	System.Deployment.Internal.Isolation .Manifest.IDescriptionMetadataEntry
IMetadataSectionEntry	0.048	2 types	21 methods	System.Deployment.Internal.Isolation .Manifest.IMetadataSectionEntry
IInternalMessage	0.27	8 types	7 methods	System.Runtime.Remoting.Messaging .IInternalMessage
ISerializationRootObject	1	1 type	1 method	System.Runtime.Remoting.Messaging .ISerializationRootObject
NativeMethods+IDispatch	0	2 types	4 methods	System.Runtime.InteropServices .NativeMethods+IDispatch
IRestrictedErrorInfo	0	2 types	2 methods	System.Runtime.InteropServices .WindowsRuntime.IRestrictedErrorInfo
IClosable	1	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime.IClosable
IStringable	1	2 types	1 method	System.Runtime.InteropServices .WindowsRuntime.IStringable
IReference<T>	0	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime.IReference<T>
IGetProxyTarget	1	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime.IGetProxyTarget
ICustomProperty	0	4 types	8 methods	System.Runtime.InteropServices .WindowsRuntime.ICustomProperty
IIterable<T>	0.6	5 types	1 method	System.Runtime.InteropServices .WindowsRuntime.IIterable<T>
IBindableIterable	1	1 type	1 method	System.Runtime.InteropServices .WindowsRuntime.IBindableIterable
IIterator<T>	0.17	9 types	4 methods	System.Runtime.InteropServices .WindowsRuntime.IIterator<T>
IBindableIterator	0.17	6 types	3 methods	System.Runtime.InteropServices .WindowsRuntime.IBindableIterator
IVector<T>	0.27	4 types	12 methods	System.Runtime.InteropServices .WindowsRuntime.IVector<T>
IVector_Raw<T>	0.83	1 type	12 methods	System.Runtime.InteropServices .WindowsRuntime.IVector_Raw<T>
IVectorView<T>	0.38	6 types	4 methods	System.Runtime.InteropServices .WindowsRuntime.IVectorView<T>
IBindableVector	0.33	3 types	10 methods	System.Runtime.InteropServices .WindowsRuntime.IBindableVector
IBindableVectorView	0	1 type	3 methods	System.Runtime.InteropServices .WindowsRuntime.IBindableVectorView
IMap<K,V>	0.29	3 types	7 methods	System.Runtime.InteropServices .WindowsRuntime.IMap<K,V>
IMapView<K,V>	0.19	4 types	4 methods	System.Runtime.InteropServices .WindowsRuntime.IMapView<K,V>
IKeyValuePair<K,V>	0.67	3 types	2 methods	System.Runtime.InteropServices .WindowsRuntime.IKeyValuePair<K,V>
OpportunisticIntern+IInternable	0.6	3 types	5 methods	Microsoft.Build .OpportunisticIntern+IInternable
INodeEndpoint	0	3 types	7 methods	Microsoft.Build.BackEnd.INodeEndpoint
INodePacket	0.4	5 types	1 method	Microsoft.Build.BackEnd.INodePacket
INodePacketHandler	0.5	2 types	1 method	Microsoft.Build.BackEnd .INodePacketHandler
INodePacketTranslatable	1	2 types	1 method	Microsoft.Build.BackEnd .INodePacketTranslatable
INodePacketTranslator	0.063	14 types	27 methods	Microsoft.Build.BackEnd .INodePacketTranslator
IRecordEnum	1	1 type	1 method	Microsoft.VisualBasic.CompilerServices .IRecordEnum
IRowsetInternal	0.3	2 types	5 methods	Microsoft.VisualBasic.Compatibility.VB6 .IRowsetInternal
IRowsetChangeInternal	0.33	1 type	3 methods	Microsoft.VisualBasic.Compatibility.VB6 .IRowsetChangeInternal
IDataFormatInternal	0.36	1 type	14 methods	Microsoft.VisualBasic.Compatibility.VB6 .IDataFormatInternal
IScriptScope	0	2 types	1 method	Microsoft.Compiler.VisualBasic .IScriptScope
ITypeScope	0	2 types	2 methods	Microsoft.Compiler.VisualBasic .ITypeScope
IImportScope	0	2 types	1 method	Microsoft.Compiler.VisualBasic .IImportScope
UCOMITransactionBridgeNetworkConfigXP	1	1 type	7 methods	Microsoft.Transactions.Bridge.Dtc .UCOMITransactionBridgeNetworkConfigXP
UCOMITransactionBridgeNetworkConfig	1	1 type	8 methods	Microsoft.Transactions.Bridge.Dtc .UCOMITransactionBridgeNetworkConfig
UCOMIGatewayProtocol	0.67	1 type	3 methods	Microsoft.Transactions.Bridge.Dtc .UCOMIGatewayProtocol
IActivationCoordinator	0.2	5 types	1 method	Microsoft.Transactions.Wsat.Messaging .IActivationCoordinator
ICompletionCoordinator	0.2	5 types	3 methods	Microsoft.Transactions.Wsat.Messaging .ICompletionCoordinator
ICompletionParticipant	0.25	4 types	3 methods	Microsoft.Transactions.Wsat.Messaging .ICompletionParticipant
IDatagramService	0	1 type	2 methods	Microsoft.Transactions.Wsat.Messaging .IDatagramService
IRequestReplyService	0	4 types	3 methods	Microsoft.Transactions.Wsat.Messaging .IRequestReplyService
IWSActivationCoordinator	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSActivationCoordinator
IWSRegistrationCoordinator	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSRegistrationCoordinator
IWSCompletionCoordinator	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSCompletionCoordinator
IWSCompletionParticipant	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSCompletionParticipant
IWSTwoPhaseCommitCoordinator	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSTwoPhaseCommitCoordinator
IWSTwoPhaseCommitParticipant	0.5	2 types	1 method	Microsoft.Transactions.Wsat.Messaging .IWSTwoPhaseCommitParticipant
ICoordinationListener	0.33	5 types	3 methods	Microsoft.Transactions.Wsat.Messaging .ICoordinationListener
IRegistrationCoordinator	0.2	5 types	1 method	Microsoft.Transactions.Wsat.Messaging .IRegistrationCoordinator
ITwoPhaseCommitCoordinator	0.2	5 types	6 methods	Microsoft.Transactions.Wsat.Messaging .ITwoPhaseCommitCoordinator
ITwoPhaseCommitParticipant	0.2	5 types	4 methods	Microsoft.Transactions.Wsat.Messaging .ITwoPhaseCommitParticipant
ITimerRecipient	1	1 type	3 methods	Microsoft.Transactions.Wsat.Protocol .ITimerRecipient
IProtocolProvider	0.3	3 types	9 methods	Microsoft.Transactions.Bridge .IProtocolProvider
IProtocolProviderCoordinatorService	0.14	20 types	6 methods	Microsoft.Transactions.Bridge .IProtocolProviderCoordinatorService
IProtocolProviderPropagationService	0.079	7 types	9 methods	Microsoft.Transactions.Bridge .IProtocolProviderPropagationService
IProducerConsumerQueue<T>	0.6	2 types	5 methods	System.Threading.Tasks .IProducerConsumerQueue<T>
IDataflowBlock	0.087	23 types	3 methods	System.Threading.Tasks.Dataflow .IDataflowBlock
IReceivableSourceBlock<TOutput>	0.5	1 type	2 methods	System.Threading.Tasks.Dataflow .IReceivableSourceBlock<TOutput>
ISourceBlock<TOutput>	0.13	29 types	4 methods	System.Threading.Tasks.Dataflow .ISourceBlock<TOutput>
ITargetBlock<TInput>	0.11	35 types	1 method	System.Threading.Tasks.Dataflow .ITargetBlock<TInput>
IDebuggerDisplay	1	6 types	1 method	System.Threading.Tasks.Dataflow.Internal .IDebuggerDisplay
IReorderingBuffer	0.25	4 types	1 method	System.Threading.Tasks.Dataflow.Internal .IReorderingBuffer
ICSharpInvokeOrInvokeMemberBinder	0.57	2 types	7 methods	Microsoft.CSharp.RuntimeBinder .ICSharpInvokeOrInvokeMemberBinder
ITypeOrNamespace	0.2	5 types	4 methods	Microsoft.CSharp.RuntimeBinder.Semantics .ITypeOrNamespace
IErrorSink	0.25	2 types	2 methods	Microsoft.CSharp.RuntimeBinder.Errors .IErrorSink
IKeyed	1	1 type	1 method	Microsoft.Build.Collections.IKeyed
IInternetSecurityManager	0.12	1 type	8 methods	IInternetSecurityManager
IClrStrongNameUsingIntPtr	0.24	1 type	25 methods	Microsoft.Runtime.Hosting .IClrStrongNameUsingIntPtr
IClrStrongName	0.36	1 type	25 methods	Microsoft.Runtime.Hosting.IClrStrongName
OpportunisticIntern+IInternable	0.6	3 types	5 methods	Microsoft.Build .OpportunisticIntern+IInternable
IComReferenceResolver	0.17	2 types	3 methods	Microsoft.Build.Tasks .IComReferenceResolver
UCOMICreateITypeLib	0.1	1 type	10 methods	Microsoft.Build.Tasks .UCOMICreateITypeLib
IMetaDataDispenser	0.33	1 type	3 methods	Microsoft.Build.Tasks.IMetaDataDispenser
IMetaDataImport	0	2 types	62 methods	Microsoft.Build.Tasks.IMetaDataImport
IMetaDataImport2	0.014	2 types	69 methods	Microsoft.Build.Tasks.IMetaDataImport2
IMetaDataAssemblyImport	0.25	2 types	14 methods	Microsoft.Build.Tasks .IMetaDataAssemblyImport
IAssemblyCache	0.1	2 types	5 methods	Microsoft.Build.Tasks.IAssemblyCache
IAssemblyName	0.056	2 types	9 methods	Microsoft.Build.Tasks.IAssemblyName
IAssemblyEnum	0.17	2 types	3 methods	Microsoft.Build.Tasks.IAssemblyEnum
IEngineCallback	0.18	12 types	6 methods	Microsoft.Build.BuildEngine .IEngineCallback
INodeProvider	0.3	3 types	10 methods	Microsoft.Build.BuildEngine .INodeProvider
ITaskRegistry	0.22	6 types	3 methods	Microsoft.Build.BuildEngine .ITaskRegistry
OpportunisticIntern+IInternable	0.26	7 types	5 methods	Microsoft.Build .OpportunisticIntern+IInternable
IToolsetProvider	0.17	6 types	2 methods	Microsoft.Build.Evaluation .IToolsetProvider
ConditionEvaluator+IConditionEvaluationS tate	0.22	7 types	7 methods	Microsoft.Build.Evaluation .ConditionEvaluator+IConditionEvaluation State
IEvaluatorData<P,I,M,D>	0.43	2 types	38 methods	Microsoft.Build.Evaluation .IEvaluatorData<P,I,M,D>
IItem	0.3	10 types	5 methods	Microsoft.Build.Evaluation.IItem
IItemDefinition<M>	0.33	3 types	2 methods	Microsoft.Build.Evaluation .IItemDefinition<M>
IItemFactory<S,T>	0.14	8 types	8 methods	Microsoft.Build.Evaluation.IItemFactory <S,T>
IItem<M>	0.5	2 types	2 methods	Microsoft.Build.Evaluation.IItem<M>
IItemProvider<T>	0.14	7 types	1 method	Microsoft.Build.Evaluation.IItemProvider <T>
IMetadataTable	0.037	9 types	3 methods	Microsoft.Build.Evaluation .IMetadataTable
IProjectMetadataParent	1	1 type	2 methods	Microsoft.Build.Evaluation .IProjectMetadataParent
IProperty	0.33	10 types	3 methods	Microsoft.Build.Evaluation.IProperty
IPropertyProvider<T>	0.1	10 types	2 methods	Microsoft.Build.Evaluation .IPropertyProvider<T>
IKeyed	0.7	10 types	1 method	Microsoft.Build.Collections.IKeyed
IDeepCloneable<T>	1	1 type	1 method	Microsoft.Build.Collections .IDeepCloneable<T>
IValued	1	3 types	1 method	Microsoft.Build.Collections.IValued
IElementLocation	0.042	48 types	4 methods	Microsoft.Build.Shared.IElementLocation
INodeEndpoint	0.2	5 types	7 methods	Microsoft.Build.BackEnd.INodeEndpoint
INodePacket	0.56	18 types	1 method	Microsoft.Build.BackEnd.INodePacket
INodePacketFactory	0.31	4 types	4 methods	Microsoft.Build.BackEnd .INodePacketFactory
INodePacketHandler	0.17	6 types	1 method	Microsoft.Build.BackEnd .INodePacketHandler
INodePacketTranslatable	1	3 types	1 method	Microsoft.Build.BackEnd .INodePacketTranslatable
INodePacketTranslator	0.091	45 types	27 methods	Microsoft.Build.BackEnd .INodePacketTranslator
IConfigCache	0.29	7 types	11 methods	Microsoft.Build.BackEnd.IConfigCache
IResultsCache	0.39	4 types	7 methods	Microsoft.Build.BackEnd.IResultsCache
ITargetBuilderCallback	0.33	3 types	1 method	Microsoft.Build.BackEnd .ITargetBuilderCallback
IRequestBuilder	0.26	3 types	9 methods	Microsoft.Build.BackEnd.IRequestBuilder
IRequestBuilderCallback	0.42	2 types	6 methods	Microsoft.Build.BackEnd .IRequestBuilderCallback
ITargetBuilder	1	1 type	1 method	Microsoft.Build.BackEnd.ITargetBuilder
ITaskBuilder	0.5	2 types	1 method	Microsoft.Build.BackEnd.ITaskBuilder
IBuildResults	0.44	1 type	9 methods	Microsoft.Build.BackEnd.IBuildResults
IBuildRequestEngine	0.67	2 types	18 methods	Microsoft.Build.BackEnd .IBuildRequestEngine
INodeManager	0.62	2 types	4 methods	Microsoft.Build.BackEnd.INodeManager
INodeProvider	0.6	2 types	5 methods	Microsoft.Build.BackEnd.INodeProvider
IBuildComponent	0.28	9 types	2 methods	Microsoft.Build.BackEnd.IBuildComponent
IBuildComponentHost	0.19	26 types	6 methods	Microsoft.Build.BackEnd .IBuildComponentHost
IScheduler	0.89	1 type	9 methods	Microsoft.Build.BackEnd.IScheduler
INode	1	1 type	1 method	Microsoft.Build.BackEnd.INode
ITaskExecutionHost	0.89	1 type	9 methods	Microsoft.Build.BackEnd .ITaskExecutionHost
ILoggingService	0.053	31 types	48 methods	Microsoft.Build.BackEnd.Logging .ILoggingService
IBuildEventSink	0.3	3 types	9 methods	Microsoft.Build.BackEnd.Logging .IBuildEventSink
IRegisteredTaskObjectCache	0.42	3 types	4 methods	Microsoft.Build.BackEnd.Components .Caching.IRegisteredTaskObjectCache
ICatalog2	0.088	1 type	57 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICatalog2
ICatalogObject	0.48	3 types	7 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICatalogObject
ICatalogCollection	0.29	3 types	16 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICatalogCollection
IPSFactoryBuffer	0.5	1 type	2 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.IPSFactoryBuffer
ICreateTypeLib	0.25	2 types	10 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICreateTypeLib
ICreateTypeInfo	0.13	1 type	23 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICreateTypeInfo
ICreateTypeInfo2	0.053	1 type	38 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.ICreateTypeInfo2
IEnumUnknown	0.25	1 type	4 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.IEnumUnknown
IClrMetaHost	0.17	1 type	6 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.IClrMetaHost
IClrRuntimeInfo	0.071	2 types	7 methods	Microsoft.Tools.ServiceModel .ComSvcConfig.IClrRuntimeInfo

Are SOLID principles Cargo Cult?

My last post about SOLID Design: The Single Responsibility Principle (SRP) generated some discussion on reddit. The discussion originated from a remark considering SOLID principles as Cargo Cult. Taking account the definition of Cargo Cult the metaphor is a bit provocative but it is not unfounded.

A cargo cult is a belief system among members of a relatively undeveloped society in which adherents practice superstitious rituals hoping to bring modern goods supplied by a more technologically advanced society

The recent Boeing’s 737 Max fiasco revealed that some parts of their software have been outsourced to $9-an-hour engineers. Those engineers shouldn’t be blamed for not achieving top notch software taking account the budget. Nevertheless it is clear that a lot of software written nowadays look like this cargo cult plane. For many real-world developers, SOLID principles are superstitious rituals whose primary goal is to succeed during job interview.

The SRP article underlines that SRP is the only SOLID principle not related to the usage of abstraction and polymorphism. SRP is about logic partitioning into code: which logic should be declared in which class. But SRP is so vague it is practically useless from its two definitions.

Definition 1: A class should have a single responsibility and this responsibility should be entirely encapsulated by the class.

Definition 2: A class should have one reason to change.

One can justify any class design choice by tweaking somehow what is a responsibility or what is a reason to change. In other words, as someone wrote in comment: Most people who “practice” it don’t actually know what it means and use it as an excuse to do whatever the hell they were going to do anyways.

We can feel bitterness in those comments, certainly coming from seasoned developers whose job is to fix mistakes of $9 an hour engineers.

SOLID Principles vs. OOP Patterns

We must remember that SOLID principles emerged in the 80s and 90s from the work of world-class OOP experts like Robert C. Martin (Uncle Bob) and Bertrand Meyer. Software writing is often considered as an art. Terminologies such as clean code or beautiful code have been widely used. But art is a subjective activity. In this context, SOLID principles necessarily remain vague and subject to interpretation. And this is what makes the difference between a SOLID principle and an OOP pattern:

A SOLID Principle is subjective. It helps to guide the usage of powerful concepts of Object Oriented Programming (OOP).
An OOP Pattern is objective. It is a set of recipes to implement a well identified situation with the OOP concepts.

Despite a restraint number of keywords and operators, the OOP toolbelt of languages such as C# or Java is very rich. With a few dozens of characters it is possible to write code that puzzle experts. C# especially gets richer and richer with many syntactic sugars to express complex situations with just a few characters. This power is a double edged sword: seasoned developers can write neat and compact code. But on the other hand it is easy to misuse this power, especially for junior developers and all those that write code just to pay their bills.

Always keep in mind the KISS principle

Someone wrote in comments: “SOLID encourages abstraction, and abstraction increases complexity. It’s not always worth it, but it’s always presented as the non-plus ultra of good approaches.”

The only reason to be for abstraction in OOP is to simplify the implementation of a complex business rule.

Abstracting Circle, Rectangle and Triangle with an IShape interface will dramatically simplify the implementation of a shape drawing software.
On the other hand, creating an interface for each class is a waste of resource: not every concepts in your program deserve an abstraction.

This is why the Keep It Simple Stupid KISS principle should be always kept in mind: don’t add up extra implementation complexity on top of the business complexity.

SOLID and Static Analysis

I am in the .NET static analysis industry since 2004. At that time I was consulting for large companies with massive legacy apps that were very costly to maintain. Books like Robert Martin’s Agile Principles, Patterns, and Practices made me realize that the source code is data. This data can be measured with code metrics. And the same way relational data can be crawled with SQL queries, code as data can be crawled with code queries. For example:

from m in Application.Methods  
where m.CyclomatiComplexity > 15 && m.PercentageCoverage < 100
select new { m, m.CyclomatiComplexity, m.PercentageCoverage }

from m in Application.Methods

where m.CyclomatiComplexity > 15 && m.PercentageCoverage < 100

select new { m, m.CyclomatiComplexity, m.PercentageCoverage }

This query will objectively match complex methods not fully covered by tests. There are situations where one can argue that static analysis returns false positives but there is no justification for complex methods not well tested.

Not all aspects of SOLID principles can be objectively measured and verified. However static analysis can help bring objectiveness. For example:

A class with many methods and fields and with a poor Lack of Cohesion Of Method (LCOM) score certainly has too many responsibilities.
A base class that uses some of its derivative is objectively a violation of the Open Close Principle (OCP).
A method that overrides a base method and that throws NotImplementedException or NotSupportedException is objectively a violation of the Liskov Substitution Principle.
An interface presenting a dozen of method is objectively a violation of the Interface Segregation Principle (ISP).
Some code metric exists to measure both coupling over implementations and over abstractions. Those metrics can help pinpoint violations of the Dependency Inversion Principle (DIP).

SOLID and Testability

Regularly applying such rules will avoid taking SOLID too far to the point it becomes detrimental. However there are still all those aspects of SOLID, and code design in general, that must be left to creativity and interpretation. Experience in software development helps a lot here: over the years one refines his/her gut feeling about which design will increase flexibility and maintainability.

By definition juniors developer have no experience. However anyone can relentlessly struggle for 100% code coverage by tests. Being able to fully cover your code means, by definition, that your code is testable. Testability doesn’t come by chance. The properties that leads to full testability are the same properties that leads to high maintainability. Those properties include:

Easiness to use API
Domain classes well isolated
Careful map of logic to classes
Short classes and short methods
Cohesive classes
Abstractions and polymorphism used judiciously
Careful management of states mutability

Advices to add up objectivity when applying SOLID principles

Not everyone is a senior developer with a passion for well designed code. As a consequence Cargo Cult usage of SOLID principles is common. To improve the design some objectivity needs to be added in the development process. Here are my 3 advices for that:

KISS principle first, always struggle for simplicity: if it is complicated it is not SOLID.
Use static analysis to automatically monitor some measurable aspects of SOLID. Gross violations of code quality rules and metrics are also SOLID principles violations.
Refactor your code until it becomes seamlessly 100% coverable by tests. Code that cannot be easily 100% covered by tests is not SOLID.

SOLID Design: The Single Responsibility Principle (SRP)

After having covered The Open-Close Principle (OCP) and The Liskov Substitution Principle (LSP) let’s talk about the Single Responsibility Principle (SRP) which is the S in the SOLID acronym. The SRP definition is:

A class should have a single responsibility and this responsibility should be entirely encapsulated by the class.

This leads to what is a responsibility in software design? There is no trivial answer, this is why Robert C. Martin (Uncle Bob) rewrote the SRP principle this way:

A class should have one reason to change.

This leads to what is a reason to change?

SRP is a principle that cannot be easily inferred from its definition. Moreover the SRP lets a lot of room for own opinions and interpretations. So what is SRP about? SRP is about logic partitioning into code: which logic should be declared in which class. Something to keep in mind is that SRP is the only SOLID principle not related to the usage of abstraction and polymorphism.

The goal of this post is to propose objective and concrete guidelines to increase your classes compliance with SRP, and in-fine, increase the maintainability of your code.

SRP and Concerns

Typically the ActiveRecord pattern is used to exhibit a typical SRP violation. An ActiveRecord class has two responsibilities:

First an ActiveRecord object stores in-memory data retrieved from a relational database.
Second the record is active in the sense that data in-memory and data in the relational database are kept mirrored. For that, the CRUD (Create Read Update Delete) operations are implemented by the ActiveRecord.

To make things concrete an ActiveRecord class can look like that:

public class Employee {
   public string Name { get; set; }
   public string Address { get; set; }
   ...

   public static Employee LoadFromName(string name) {
      //below query will get only a value from DB
      string sqlQuery = "SELECT * FROM Employee WHERE Name = '" + name + "' LIMIT 1;";

      // get value from DB and fill this employee with obtained value
      Employee record = new Employee() { Name =  name, Address = ...};
      return record;
   }

   public bool Create() { 
      // create the record in DB
   }
   public bool Update() {
      // update the record in DB ...
   }
   public bool Delete() { 
      // delete the record in DB ...
   }
}

public class Employee {

public string Name { get; set; }

public string Address { get; set; }

...

public static Employee LoadFromName(string name) {

//below query will get only a value from DB

string sqlQuery = "SELECT * FROM Employee WHERE Name = '" + name + "' LIMIT 1;";

// get value from DB and fill this employee with obtained value

Employee record = new Employee() { Name = name, Address = ...};

return record;

}

public bool Create() {

// create the record in DB

}

public bool Update() {

// update the record in DB ...

}

public bool Delete() {

// delete the record in DB ...

}

If Employee was a POCO class that doesn’t know about persistence and if the persistence was handled in a dedicated persistence layer the API would be improved because:

Not all Employee consumer wants to deal with persistence.
More importantly an Employee consumer really needs to know when an expensive DB roundtrip is triggered: if the Employee class is responsible for the persistence who knows if the data is persisted as soon as a setter is invoked?

Hence better isolate the persistence layer accesses and make them more explicit. This is why at NDepend we promote rules like UI layer shouldn’t use directly DB types that can be easily adapted to enforce any sort of code isolation.

Persistence is what we call a cross-cutting concerns, an aspect of the implementation that tends to spawn all over the code. We can expect that most domain objects are concerned with persistence. Other cross-cutting-concerns we want to separate domain objects from include: validation, log, authentication, error handling, threading, caching. The need to separate domain entities from those cross-cutting concerns can be handled by some OOP pattern like the pattern decorator for example. Alternatively some Object-Relational Mapping (ORM) frameworks and some Aspect-Oriented-Programming (AOP) frameworks can be used.

SRP and Reason to Change

Let’s consider this version of Employee:

public class Employee { 
  public string Name { get; set; }
  public string Address { get; set; } 
  ...
  public void ComputePay() { ... }
  public void ReportHours() { ...}
}

public class Employee {

public string Name { get; set; }

public string Address { get; set; }

...

public void ComputePay() { ... }

public void ReportHours() { ...}

}

The ComputePay() behavior is under the responsibility of the finance people and the ReportHours() behavior is under the responsibility of the operational people. Hence if a financial person needs a change to be implemented in ComputePay() we can assume this change won’t affect the ReportHours() method. Thus according to the version of SRP that states “a class should have one reason to change”, it is wise to declare these methods in different dedicated modules. As a consequence a change in ComputePay() has no risk to affect the behavior of ReportHours() and vice-versa. In other words we want these two parts of the code to be independent because they will evolve independently.

This is why Robert C. Martin wrote that SRP is about people : make sure that logics controlled by different people are implemented in different modules.

SRP and High-Cohesion

The SRP is about encapsulating logic and data in a class because they fit well together. Fit well means that the class is cohesive in the sense that most methods use most fields. Actually cohesion of a class can be measured with the Lack of Cohesion Of Methods (LCOM) metric. See below an explanations of LCOM (extracted from this great Stuart Celarier placemat) What matters is to understand that if all methods of a class are using all instances fields, the class is considered utterly cohesive and has the best LCOM score, which is 0 or close to 0.

Typically the effect of a SRP violation is to partition a class methods and fields into groups with few connections. The fields needed to compute the pay of an employee are not the same than the fields needed to report pending work. This is why the LCOM metric can be used to measure adherence to SRP and take actions. You can use the rule Avoid types with poor cohesion to track classes with poor cohesion between methods and fields.

SRP and Fat Code Smells

While we can hardly find an easy definition for what is a responsibility we noticed that adhering to SRP usually results in classes with a good LCOM score. On the other hand, not adhering to SRP usually leads to the God class phenomenon: a class that knows too much and does too much. Such god class is usually too large: violations of rules like Avoid types too big, Avoid types with too many methods, Avoid types with too many fields are good candidate to spot god classes and refactor into a finer-grained design.

Guidelines to adhere to SRP

Here are a set of objective and concrete guidelines to adhere to SRP:

Domain classes must be isolated from Cross-Cutting Concerns: code responsible for persistence, validation, log, authentication, error handling, threading, caching…
When implementing your domain, favor POCO classes that do not have any dependency on an external framework. Note that a POCO class is not necessarily a fields and properties only class, but can implement logic/behavior related to its data.
Use your understanding of the Domain to partition code: logics related to different business functions should be kept separated to avoid interference.
Regularly check the Lack of Cohesion Of Methods (LCOM) score of your classes.
Regularly check for too large and too complex classes.

SOLID Design: The Open-Close Principle (OCP)

The Open-Close principle (OCP) is the O in the well known SOLID acronym.

Bertrand Meyer is generally credited for having originated the term open/closed principle, which appeared in his 1988 book Object Oriented Software Construction. Its original definition is

A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs.
A module will be said to be closed if it is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding)

Upon these definitions the principle is usually expressed and summarized this way:

Modules should be open for extension and closed for modification.

There have been (and still are) a lot of debates about the meaning of this simple definition and its implication on the usage of Object-Oriented Programming (OOP) in the real-world.

In this post I’ll try to be as concrete and concise as possible.

The classical code example to explain OCP

The classical code example to explain OCP can be translated in C# this way:

public class Circle { }

public class Square { }

public static class Drawer {
   public static void DrawShapes(IEnumerable<object> shapes) {
      foreach (object shape in shapes) {
         if (shape is Circle) {
            DrawCircle(shape as Circle);
         } else if (shape is Square) {
            DrawSquare(shape as Square);
         }
      }
   }
   private static void DrawCircle(Circle circle) { /*Draw circle*/ }

   private static void DrawSquare(Square square) { /*Draw Square*/ }
}

public class Circle { }

public class Square { }

public static class Drawer {

public static void DrawShapes(IEnumerable<object> shapes) {

foreach (object shape in shapes) {

if (shape is Circle) {

DrawCircle(shape as Circle);

} else if (shape is Square) {

DrawSquare(shape as Square);

}

private static void DrawCircle(Circle circle) { /*Draw circle*/ }

private static void DrawSquare(Square square) { /*Draw Square*/ }

}

I find this example a bit gross. I believe one must have no idea of what OOP is to write such code. It can obviously be refactored to something like this:

public interface IShape { void Draw(); }

public class Circle : IShape { public void Draw() { /*Draw circle*/ }}

public class Square : IShape { public void Draw() { /*Draw Square*/ } }

public static class Drawer {
   public static void DrawShapes(IEnumerable<IShape> shapes) {
      foreach (IShape shape in shapes) {
         shape.Draw();
      }
   }
}

public interface IShape { void Draw(); }

public class Circle : IShape { public void Draw() { /*Draw circle*/ }}

public class Square : IShape { public void Draw() { /*Draw Square*/ } }

public static class Drawer {

public static void DrawShapes(IEnumerable<IShape> shapes) {

foreach (IShape shape in shapes) {

shape.Draw();

}

Let’s look at the implication of this refactoring:

We introduced a new abstraction IShape to represent a concept that we already had in mind. Indeed, in the first code sample the method DrawShapes() already accepted a sequence of shapes. With the new IShape abstraction our design is now open to accept more shapes like Triangle or Pentagone.
The method DrawShapes() will draw any new shape without any need for modification. In other words the DrawShapes() method implementation is closed.

Here is how the OCP is usually presented. It is all about anticipating the future changes in the system in a way that:

When a change occurs existing code is left untouched. Existing code here is DrawShapes() concrete method body, IShape interface and Circle and Square classes.
When a change occurs new code to implement changes is written in new classes that implement existing abstraction. New classes here could be Triangle and Pentagone.

The Point of Variation principle

Another way to see the OCP is the Point of Variation (PV) principle that states:

Identify points of predicted variation and create a stable interface around them.

I find PV more understandable than OCP because it is actionable. First identify potential variations, second build the proper abstractions around these variations.

The real challenge: Anticipation

But the real challenge is anticipation, anticipating is hard. If anticipation was easy we’d be all billionaire in bitcoins. In real world, when you anticipate the risk is high that:

We do anticipate variations that won’t vary. This is what the YAGNI principle says (You aren’t gonna need it): Always implement things when you actually need them, never when you just foresee that you need them. Developing and maintaining an abstraction has a cost and if we won’t need it this cost is negative.
The risk is also high that we don’t anticipate the variation that will really be needed. But once the need for variation becomes real this is your developer responsibility to refactor and create the right abstractions and the right stable code that will act upon these abstractions. This is the fool me once, don’t fool me twice idea: I am not supposed to foresee what I’ll need but I am supposed to identify and then write the right abstraction when I need it.

OCP in the real world

Here is a pragmatic approach to OCP:

In any case the KISS principle applies (Keep It Simple Stupid): don’t underestimate the difficulty of anticipating and don’t waste your resources creating abstractions you won’t need.
Write automatic tests: one of the greatest benefit of writing tests is that for a while, you must look at your code from the client perspective. If your code contains some area difficult to cover by tests, it certainly means that your code should be refactored to be easily 100% testable. Experience shows that when refactoring from poorly testable code to fully testable code, the need for right abstractions naturally pops up.
Some static analyzers can help you pinpoint typical OCP violations:
- when downcasting reference (i.e casting from a base class or interface to a subclass or leaf class.),
- when using the is or as operators (as in the first example above).
- NDepend has the rule Base class should not use derivatives: matches of this rules are obvious violation of the OCP.

Keep in mind the fool me once, don’t fool me twice idea. You must refactor code as soon as the need to abstract some concepts is identified. Of course sometime it is not possible if tons of client code depend upon your API: in this situation you cannot easily refactor and often you’ll have to live with wrong design. This is why public API design is such a sensitive topic: you have no other choice than doing your best to anticipate and to accept to live with your past design mistake.

Be open to more than one variation with the Visitor pattern

Finally let’s underline that in the real world, data objects (like the shapes here) don’t implement themselves algorithm such as drawing. Experience tells that this is a clear violation of OCP because when a new algorithm is needed on data objects, like persistence in addition of drawing for example, all shape classes must be modified again. This is also a violation of the Single Responsibility Principle (SRP, the S in SOLID) because a shape class has now two responsibilities: 1) holding the shape data 2) drawing the shape.

Hence we now have two variations: we need a way to abstract both the shapes and the algorithms applied on the shapes, in order to to write something like algorithm.ApplyOn(shape). This sort of call on two abstractions is named a double dispatching call: the implementation really invoked depends both on the IShape object’s type and the IAlgorithm object’s type. If you have N shapes and M algorithms you need [N x M] implementations.

Fortunately the visitor pattern helps implementing double dispatching. The code with the new persistence algorithm would then look like:

//
// Shapes elements
//
public interface IShape { void Accept(IVisitor visitor); }
public class Circle : IShape {
   public void Accept(IVisitor visitor) { visitor.Visit(this); }
}
public class Square : IShape {
   public void Accept(IVisitor visitor) { visitor.Visit(this); }
}

//
// Visitors algorithms on shapes elements
// don't use the IAlgorithm terminology to keep up with the classical visitor pattern terminology
//
public interface IVisitor {
   void Visit(Circle circle);
   void Visit(Square square);
}
public class DrawAlgorithm : IVisitor {
   public void Visit(Circle circle) { /*Draw circle*/}
   public void Visit(Square square) { /*Draw square*/}
}
public class PersistAlgorithm : IVisitor {
   public void Visit(Circle circle) { /*Persist circle*/}
   public void Visit(Square square) { /*Persist square*/}
}

public static class Program {
   public static void ApplyVisitorAlgorithmOnShapesElements(IEnumerable<IShape> shapes, IVisitor visitor) {
      foreach (IShape shape in shapes) {
         // Double dispatching:
         //   shape can be both: Circle or Square
         //   visitor can be both Draw or Persist
         shape.Accept(visitor);  
      }
   }
}

// Shapes elements

public interface IShape { void Accept(IVisitor visitor); }

public class Circle : IShape {

public void Accept(IVisitor visitor) { visitor.Visit(this); }

}

public class Square : IShape {

public void Accept(IVisitor visitor) { visitor.Visit(this); }

}

// Visitors algorithms on shapes elements

// don't use the IAlgorithm terminology to keep up with the classical visitor pattern terminology

public interface IVisitor {

void Visit(Circle circle);

void Visit(Square square);

}

public class DrawAlgorithm : IVisitor {

public void Visit(Circle circle) { /*Draw circle*/}

public void Visit(Square square) { /*Draw square*/}

}

public class PersistAlgorithm : IVisitor {

public void Visit(Circle circle) { /*Persist circle*/}

public void Visit(Square square) { /*Persist square*/}

}

public static class Program {

public static void ApplyVisitorAlgorithmOnShapesElements(IEnumerable<IShape> shapes, IVisitor visitor) {

foreach (IShape shape in shapes) {

// Double dispatching:

// shape can be both: Circle or Square

// visitor can be both Draw or Persist

shape.Accept(visitor);

}

SOLID design: The Liskov Substitution Principle (LSP)

The Liskov substitution principle is the L in the well known SOLID acronym. The original principle definition is:

Methods that use references to base classes must be able to use objects of derived classes without knowing it.

At first glance this principle is pretty easy to understand. At second glance it seems redundant with the OOP concept of polymorphism. After all, the whole point of polymorphism is to consume an abstraction without knowing the implementation behind isn’t it?

However it is a good thing that the community emphases the Liskov substitution principle. This principle is in fact a caveat for developers that polymorphism is both powerful and tricky : in the real world, the usage of polymorphism often leads to a dead-end situation, it must be wisely used.

LSP is often summarized with a counter-example of Duck Test: “If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction”

Let’s details some common polymorphism pitfalls that the Liskov substitution principle attempts to prevent by reminding the developer to adopt the client perspective.

Prevent situations where a method cannot be implemented

When a class implements an interface or derives from a base class, refactor tooling like Visual Studio refactor tools, Resharper or CodeRush propose to insert abstract methods stubs to implement. Typically the default body of such inserted method is throw NotImplementedException().

Obviously this behavior must remain temporary and must not be released in production. Client code that hold a reference on the interface or the base class doesn’t expect to get a NotImplementedException raised upon a method call. This is why NDepend has a default rule named Do implement methods that throw NotImplementedException, to prevent such situation.

On the other hand, if it doesn’t make sense to implement an abstract method, it clearly means that the design is wrong. Here is such wrong design, assuming that all birds can fly:

   public abstract class Bird {
      public abstract void Fly();
   }
   public class Parrot : Bird {
      public override void Fly() { throw new NotImplementedException(); } // To implement
   }
   public class Ostrich : Bird {
      public override void Fly() { throw new NotImplementedException(); } // How to implement this, Ostrih can't fly??
   }

public abstract class Bird {

public abstract void Fly();

}

public class Parrot : Bird {

public override void Fly() { throw new NotImplementedException(); } // To implement

}

public class Ostrich : Bird {

public override void Fly() { throw new NotImplementedException(); } // How to implement this, Ostrih can't fly??

}

This code could then be refactored to:

   public abstract class Bird {
   }
   public abstract class FlyingBird : Bird {
      public abstract void Fly();
   }
   public class Parrot : FlyingBird {
      public override void Fly() { throw new NotImplementedException(); }
   }
   public class Ostrich : Bird {
   }

public abstract class Bird {

}

public abstract class FlyingBird : Bird {

public abstract void Fly();

}

public class Parrot : FlyingBird {

public override void Fly() { throw new NotImplementedException(); }

}

public class Ostrich : Bird {

}

The problem was that Bird with its Fly() method was too coarse, we needed some refinement because not all bird can fly. From my experience such wrong assumptions on interfaces and base classes happen quite often in the real world. When you stumble on such situation, see it as a good starting point for refactoring … if possible. Indeed, sometime refactoring is not an option if many clients depend already on the wrong design.

Example of a LSP violation in the .NET framework design

One dreaded LSP violation is .NET System.Array implementing the ICollection<T> interface. Hence Array has to implement the ICollection<T>.Add() method but calling this method on an array throws at runtime a NotSupportedException:

The C# compiler doesn’t even warn on such simple erroneous program.

Of course we’d need to ensure that ICollection<T>.IsReadOnly is false before modifying a collection through a reference of IList<T> or a ICollection<T> but frankly this is an error-prone design. I can remember having stumbled on this situation quite a few times during the last 15 years I am programming with C#/.NET.

Moreover refactoring this original design mistake is not an option anymore, even when .NET Core was introduced, since millions of programs are relying on this API. IReadOnlyCollection<T> has been introduced with .NET v4.5 in 2012 but the original design cannot be changed.

Think twice before applying the ISA trick

Another common example to explain the Liskov substitution principle is the Rectangle/Square paradigm. A square is-a rectangle isn’t it? So we should be able to write such code:

   public class Rectangle {
      public virtual int Width { get; set; }
      public virtual int Height { get; set; }
   }
   public class Square : Rectangle {
      // Need to make sure that a Square width and height remain equal!
      public override int Width { set { this.Width = value; this.Height = value; } }
      public override int Height { set { this.Height = value; this.Width = value; } }
   }
   public void Method(Rectangle rect) {
     rect.Width = 2;
     rect.Height = 3;
     Debug.Assert(rect.Width == 2); // If rect references a Square object this legitimate client assertion is violated!!!
   }

public class Rectangle {

public virtual int Width { get; set; }

public virtual int Height { get; set; }

}

public class Square : Rectangle {

// Need to make sure that a Square width and height remain equal!

public override int Width { set { this.Width = value; this.Height = value; } }

public override int Height { set { this.Height = value; this.Width = value; } }

}

public void Method(Rectangle rect) {

rect.Width = 2;

rect.Height = 3;

Debug.Assert(rect.Width == 2); // If rect references a Square object this legitimate client assertion is violated!!!

}

Clearly this is a wrong usage of the ISA principle: yes a square is a rectangle but the client doesn’t expect that when modifying the height of the rectangle, the width gets modified also.

Here also such wrong design emerges quite often in the real world. For example when dealing with a complex control hierarchy with dozens of fields to maintain at various level, it can become quite tricky to maintain coherence in your objects’ states at runtime.

Code Contract to help?

In theory code contract could help here. A contract is one or several assertions that prevent corrupted state. When a corrupted state is reached at runtime (whether in production or at test run time), such assertion must deadly fail because continuing running with corrupted state can potentially lead to more corrupted states.

Often contracts are used at interface level to improve the semantic by adding constraints to classes that implement the interface. We might want to force all implementations of IRectangle.set_Width to let the Height value untouched. By using Microsoft Code Contracts we could try to write something like that:

using System.Diagnostics.Contracts;

[ContractClass(typeof(IRectangleContract))]
public interface IRectangle {
   int Width { get; set; } 
   int Height { get; set; }
}

[ContractClassFor(typeof(IRectangle))]
public class IRectangleContract : IRectangle {
   public int Width { get;
      set { Contract.PreserveValue(this.Height), "Height must not be changed when assigning Width"); }
   }
   public int Height { get;
      set { Contract.PreserveValue(this.Width), "Width must not be changed when assigning Height"); }
   }
}

using System.Diagnostics.Contracts;

[ContractClass(typeof(IRectangleContract))]

public interface IRectangle {

int Width { get; set; }

int Height { get; set; }

}

[ContractClassFor(typeof(IRectangle))]

public class IRectangleContract : IRectangle {

public int Width { get;

set { Contract.PreserveValue(this.Height), "Height must not be changed when assigning Width"); }

}

public int Height { get;

set { Contract.PreserveValue(this.Width), "Width must not be changed when assigning Height"); }

}

Unfortunately, as far as I know, Microsoft Code Contracts has no support for such PreserveValue() possibility. More generally it seems that Microsoft Code Contracts doesn’t receive much love nowadays despite how useful code contract can be. Ok C#8 non-nullable reference addresses many of the situations usually verified through contracts or assertions, but not all contracts are about nullable reference, as this example suggests.

Use polymorphism with great caution

These classical Bird and Rectangle examples show well how polymorphism and inheritance can quickly lead to rotten design, even in apparently simple situations. The Array class implementing ICollection<T> situation shows that in practice LSP violations just happen.

In my point of view, what the Liskov substitution principle really says is that when writing an API relying on polymorphism, you should first take the point of view of the client of your API before writing any interface and any class hierarchy.

Do really all birds can fly? What happen if I try to call Fly() on a bird that cannot fly?
Is a square really a rectangle? What happen if I change the width on a square?

In the real world this looks like:

Can all collections really be modified? What happen if I add or remove an element to an array?
Do all controls are scrollable? What happen if a scrollbar is displayed on a control that should not scroll?
Do withdrawal applies to all bank account? What happen if we try to withdraw money from a locked long term deposit account? Should we fail withdrawal badly in this situation or should we prevent such situation with an IAccountThatAuthorizeWithdraw abstraction?

A pattern emerges here: for each members of your interface you should question yourself: Do this member applies seamlessly to all objects that will implement this interface?

Notice that API writing principle is more general, it doesn’t only apply to polymorphism: when writing an API first take the point of view of the client of your API. This is the only way to achieve elegant API that clients will love to consume. This is another way to explain Test-Driven Development (TDD), where client code must be written for test and design purposes before writing the code itself.

In a previous post I explained why your classes should be declared as sealed when possible and why NDepend proposes the default rule Class with no descendant should be sealed if possible. In the real world, a class is never well designed for inheritance by chance and thus should be sealed by default. Designing well a class for inheritance requires quite an extensive understanding of your domain. As for everything in life, it requires a lot of effort to build something that others will find easy to use.

Identify .NET Code Structure Patterns with no Effort

The two pillars of code maintainability are automatic testing and clean code structure.

Testing is used to regularly challenge code correctness and detect regression early. Testing can be easily assessed with numbers like code coverage ratio and the amount of assertions tested.
A clean code structure prevents the phenomenon of spaghetti code, entangled code that is hard to understand and hard to maintain. However assessing the code structure cannot be achieved through numbers like for testing. Moreover the structure emerges from a myriad of details buried in many source files and thus appropriate tooling is needed.

For most engineers, code dependency graph is the tool of choice to explore code structure. Boxes and arrows graph is intuitive and well adapted to visualize a small amount of dependencies. However to visualize complex portion of code the Dependency Structure Matrix (DSM) is more adapted. See below the same set of 34 namespaces visualized with the NDepend Dependency Graph and the NDepend Dependency Matrix.

If the concept of dependency matrix is something new to you, it is important to note that:

The Matrix headers’ elements represent graph boxes
The Matrix non-empty cells correspond to graph arrows. Numbers on the cells represents a measure of the coupling in terms of numbers of methods and fields involved. In a symmetric matrix a pair of blue and green cell is symmetric because both cells represents the same thing: the blue cell represents A uses B and the green cells represents B is used by A.

Here is a 5 minutes introduction video if you are not familiar with the dependency matrix:

Clearly the graph is more intuitive, but apart the two red arrows that represent two pairs of namespaces mutually dependent this graph tells few things about the overall structure.

On the other hand the matrix algorithm naturally attempts to layer code elements, exhibit dependency cycles, shows which element is used a lot or not… Let’s enumerate some structural patterns that can be visualized at a glance with the dependency matrix:

Layers

One pattern that is made obvious by a DSM is layered structure (i.e acyclic structure). When the matrix is triangular, with all blue cells in the lower-left triangle and all green cells in the upper-right triangle, then it shows that the structure is perfectly layered. In other words, the structure doesn’t contain any dependency cycle.

On the right part of the snapshot, the same layered structure is represented with a graph. All arrows have the same left to right direction. The problem with graph, is that the graph layout doesn’t scale. Here, we can barely see the big picture of the structure. If the number of boxes would be multiplied by 2, the graph would be completely unreadable. On the other side, the DSM representation wouldn’t be affected; we say that the DSM scales better than graph.

Notice that NDepend proposes 2 rules out of the box to control layering by preventing dependency cycles to appear: ND1400 Avoid namespaces mutually dependent and ND1401 Avoid namespaces dependency cycles.

Interestingly enough, most of graph layout algorithms rely on the fact that a graph is acyclic. To compute layout of a graph with cycles, these algorithms temporarily discard some dependencies to deal with a layered graph, and then append the discarded dependencies at the last step of the computation.

Cycles

If a structure contains a cycle, the cycle is displayed by a red square on the DSM. We can see that inside the red square, green and blue cells are mixed across the diagonal. There are also some black cells that represent mutual direct usage (i.e A is using B and B is using A).

The NDepend’s DSM comes with the option Indirect Dependency. An indirect dependency between A and B means that A is using something, that is using something, that is using something … that is using B. Below is shown the same DSM with a cycle but in indirect mode. We can see that the red square is filled up with only black cells. It just means that given any element A and B in the cycle, A and B are indirectly and mutually dependent.

Here is the same structure represented with a graph. The red arrow shows that several elements are mutually dependent. But the graph is not of any help to highlight all elements involved in the parent cycle.

Notice that in NDepend, we provided a button to highlight cycles in the DSM (if any). If the structure is layered, then this button has for effect to triangularize the matrix and to keep non-empty cells as closed as possible to the diagonal.

High Cohesion / Low-Coupling

The idea of high-cohesion (inside a component) / low-coupling (between components) is popular nowadays. But if one cannot measure and visualize dependencies, it is hard to get a concrete evaluation of cohesion and coupling. DSM is good at showing high cohesion. In the DSM below, an obvious squared aggregate around the diagonal is displayed. It means that elements involved in the square have a high cohesion: they are strongly dependent on each other although. Moreover, we can see that they are layered since there is no cycle. They are certainly candidate to be grouped into a parent artifact (such as a namespace or an assembly).

On the other hand, the fact that most cells around the square are empty advocate for low-coupling between elements of the square and other elements.

In the DSM below, we can see 2 components with high cohesion (upper and lower square) and a pretty low coupling between them.

While refactoring, having such an indicator can be pretty useful to know if there are opportunities to split coarse components into several more fine-grained components.

Too many responsibilities

The popular Single Responsibility Principle (SRP) states that: a class shouldn’t have more than one reason to change. Another way to interpret the SRP is that a class shouldn’t use too many different other types. If we extend the idea at other level (assemblies, namespaces and method), certainly, if a code element is using dozens of other different code elements (at same level), it has too many responsibilities. Often the term God class or God component is used to qualify such piece of code.

DSM can help pinpoint code elements with too many responsibilities. Such code element is represented by columns with many blue cells and by rows with many green cells. The DSM below exposes this phenomenon.

Popular Code Elements

A popular code element is used by many other code elements. Popular code elements are unavoidable (think of the String class for example).

A popular code element is not a flaw. However it is advised that popular elements are interfaces and enumerations. This way consumers rely on abstractions and not on implementations details. The benefit is that consumers are less often broken because abstraction are less subject to change than implementations.

A popular code element is represented by columns with many green cells and by rows with many blue cells. The DSM below highlights a popular code element.

Something to notice is that when one is keeping its code structure perfectly layered, popular components are naturally kept at low-level. Indeed, a popular component cannot de-facto use many things, because popular component are low-level, they cannot use something at a higher level. This would create a dependency from low-level to high-level and this would break the acyclic property of the structure.

Mutual dependencies

You can see the coupling between 2 components by right clicking a non-empty cell, and select the menu Open this dependency.

If the opened cell was black as in the snapshot above (i.e if A and B are mutually dependent) then the resulting rectangular matrix will contains both green and blue cells (and eventually black cells as well) as in the snapshot below.

In this situation, you’ll often notice a deficit of green or blue cells (3 blue cells for 1 green cell here). It is because even if 2 code elements are mutually dependent, there often exists a natural level order between them. For example, consider the System.Threading namespaces and the System.String class. They are mutually dependent; they both rely on each other. But the matrix shows that Threading is much more dependent on String than the opposite (there are much more blue cells than green cells). This confirms the intuition that Threading is upper level than String.