NDepend Users Voice

Integrate with IoC Framewoks

Parse IoC Framewoks settings XML files to append on-demand defined dependencies to the NDepend code model.

74 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminPatrick Smacchia (Senior Software Engineer, NDepend) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Pressacco commented  ·   ·  Flag as inappropriate

    Still waiting to see if this feature could add value to static analysis.

    Re: our current project... all dependencies are being managed from within the code base using PRISM.

  • Mark Kharitonov commented  ·   ·  Flag as inappropriate

    Our DI is entirely in code, we do not have any XML.
    Specifically, we use MEF for Dependency Injection. Everything is attribute based.

    I agree, that in order to be meaningful the DI analysis should have deep knowledge of the respective DI framework.

    NDepend is unlikely to have a single implementation for all. It will probably have a modular implementation with a module per DI framework and ideally an API to allow third parties to develop modules for other DI frameworks. Something like that.

    Non trivial, but essential if the call graph feature is to be supported in the future.

  • Mark Kharitonov commented  ·   ·  Flag as inappropriate

    We are using MEF as our .NET Dependency Injection framework. But this would be true for any project considering itself as modern - a pervasive use of DI. NDepend is significantly less attractive as long as it does not support DI.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I would really love this feature, and also support for attribute based metadata clues for Classes. NDepend would be much better of understanding the implementation if I could somehow instruct with metadata attributes the IOC purpose and those implementations. I often see in some projects that have heavily using and abusing the IOC. The NDepend makes the whole dependency a very spaghetti, and sometimes the analysis is actually worse as it seems not accounting the IOC in analysis and diagrams.

  • Paul Saunders commented  ·   ·  Flag as inappropriate

    Given that the general industry trend is away from xml configuration for IoC, this feature only really becomes useful when code IoC aware. As Dru said. It ain't going to be that easy.

  • krainey commented  ·   ·  Flag as inappropriate

    I agree with Steven that it would be more useful if NDepend could also look at DI container registration in code. I very seldom come across projects where configuration is done in XML -- it's virtually always done in code.

  • Dru Sellers commented  ·   ·  Flag as inappropriate

    I would be very interested not in the XML parsing, but in tooling that is IoC aware. I don't expect that one to be easy or what it would really give me. but i like the idea.

  • Steven commented  ·   ·  Flag as inappropriate

    That would not be a very useful features, since there should hardly be any of your DI configuration written in XML. 99% of the configuration should be done in code. So to do any useful analysis, NDepend should look at the code that configures the DI configuration, but this is actually very hard and to yield any useful analysis, this needs deep knowledge of the DI framework in question. For instance, just look at what the Agent Mulder (https://github.com/hmemcpy/AgentMulder) plug-in for Resharper does. It integrates DI containers with Resharper, but it stops at the point where DI containers get useful: batch registration. So to be honest, I don't think that static analysis is really helpful in this area, since DI containers dynamic in nature and you'll need to run code to be able to analyze what's happening.

Feedback and Knowledge Base