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.