Re: Getting NDepend to cope with too many DataSet assemblies

Anonymous — Fri, 27 Aug 2010 10:31:59 GMT

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

- alvin

Re: Getting NDepend to cope with too many DataSet assemblies

icelava — Sat, 01 May 2010 13:11:25 GMT

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.

Re: Getting NDepend to cope with too many DataSet assemblies

Anonymous — Thu, 29 Apr 2010 07:24:44 GMT

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 :)

Getting NDepend to cope with too many DataSet assemblies

icelava — Wed, 28 Apr 2010 09:23:06 GMT

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.

Software Development

Re: Getting NDepend to cope with too many DataSet assemblies

Re: Getting NDepend to cope with too many DataSet assemblies

Re: Getting NDepend to cope with too many DataSet assemblies

Getting NDepend to cope with too many DataSet assemblies