icelava.net

why be normal?
Welcome to icelava.net Sign in | Help
in Search

Getting NDepend to cope with too many DataSet assemblies

Last post 08-27-2010, 5:31 by Anonymous. 3 replies.
Sort Posts: Previous Next
  •  04-28-2010, 4:23 6703

    Getting NDepend to cope with too many DataSet assemblies

    Previously I was all happy and impressed by the performance and stability of NDepend v3.0. I still am, but alas, the fact remains that no matter how well you design and build something, there will always be something much more horrid to make your work crumble to pieces. When I started moving onto the larger deployments in the enterprise - numbering near 2000 assemblies - the several hundred DataSet assemblies reared their ugly heads again and utterly crushed NDepend with the weight of all their fatty members. This is no fault of NDepend, really, but just one of many signs that the architects who envisioned such work need to be burnt at the stake. With aircraft-grade jet fuel.

    So how should one deal with when being faced with such gigantic .NET solutions? The most apparent workaround is simply to point out the DataSet assemblies and exclude them completely from analysis. But this prevents NDepend from gaining awareness of elements in those assemblies; crucial CQL queries regarding how DataSets and DataTables are being utilised cannot be fully realised.

    Thankfully, there is an alternative - make the DataSet assemblies tier assemblies (blue) instead of application-level assemblies. How to do that? I discovered this by accident, when i originally moved all DataSet assemblies to a separate sub-directory. I did so to avoid selecting them with a Select-all operation during the assembly-selection process for Analysis. Of course, this only ended up with the above situation since my original intention was to exlcude the DataSet assemblies totally. The trick came when I actually re-added them into the (application) assembly list for analysis, and subsequently removed them. NDepend, knowing that those assemblies were being referenced and made use of, shifted their entries from the application column over to the tier column.

    With such a setup, analysis of ~1500 application assemblies with ~300 tier DataSet assemblies was possible without OutOfMemoryException blowing up. With this manner of analysis completed, I was able to query out names of DataSets/DataTables being used within stacks of method calls, satisfying most of our data-related questions about our code base. Hopefully this tactic can help others faced with monolithtic systems manage a little better when attempting to do some untangling study with NDepend.

  •  04-29-2010, 2:24 6704 in reply to 6703

    Re: Getting NDepend to cope with too many DataSet assemblies

    Indeed tier assemblies is a cool NDepeni features I descaibed in depth here: Controlling the usage of Library

    http://codebetter.com/blogs/patricksmacchia/archive/2008/10/20/controlling-the-usage-of-libraries.aspx

    > the several hundred DataSet assemblies reared their ugly heads again and utterly crushed NDepend with the weight of all their fatty members.

    Our goal achieved with NDepend v3, was to be able to analyze the whole .NET Fx assemblies on a 32 bits machine in less than a minute. This represents around 1.5M Lines of Code. So with your datasets assemblies, your app seems to be bigger than the whole .NET Fx. You can buy a 64bits machine :)

     

  •  05-01-2010, 8:11 6710 in reply to 6704

    Re: Getting NDepend to cope with too many DataSet assemblies

    Yes, this whole system (more than one app) is vastly bigger than the .NET Framework itself. And that is not news to be happy about by any measure.
  •  08-27-2010, 5:31 7084 in reply to 6710

    Re: Getting NDepend to cope with too many DataSet assemblies

    interesting... and hilarious!!! especially now that im on the same boat! hahaha! 

    - alvin

View as RSS news feed in XML
Powered by Community Server, by Telligent Systems