Ability to analyze NuGet packages
There are currently project types for analyzing a project/solution and for analyzing a folder full of assemblies.
Much of my work lately has been in creating smaller, standalone "framework" sorts of packages on an internal NuGet feed that different applications can consume. There isn't "a master project" that has all of these packages working together; instead it's different combinations of the packages.
I'd like to be able to analyze all of these packages in a single report without having to either manually download them all or create a "fake" project just for the sake of referencing them.
One way to do this might be to allow analysis on a packages.config file. Add the packages you want to the file, specify a target framework, and have NDepend download the packages (and dependencies) and basically run the same process as "analyze a folder full of assemblies."
I think this will be even more interesting as DNX and the new project structure picks up momentum - everything becomes NuGet package references rather than direct project or assembly references.
Travis Illig
shared this idea
-
Travis Illig
commented
At this point the simplest solution for me is to have a fake project that references all of the packages and analyze it that way. That mostly avoids all the guessing at framework moniker and all that. I just look forward to a future where it's a little easier. And maybe it will be with the new <PackageReference> elements in .csproj files - This was written long before that was a thing, so maintaining packages.config is almost the same as maintaining a set of <PackageReference> elements.
-
For v2017.3 we are focusing on analyzing NuGet packages referenced by your application assemblies (i.e v2017.3 will resolve third-party assemblies in NuGet packages)
But this is definitely important to analyze application assemblies of one or several NuGet packages.
For now you can still use the feature -Analyze assemblies in folder (***recursive***)- and point out to C:\Users\[users]\.nuget\packages or wherever lies your NuGet packages unzipped
and then filter assemblies to analyze by namesYou'll then see how assemblies of your packages relate.
But you'll miss
1) filter by package name that can be more convenient than filter by assemblies (in NuGet pkg) names
2) filter by moniker (netstandard1.X...) (a moniker will be chosen randomly, but you can change the dir referenced by the project property later in Project Properties > Code to Analyze > Folders)
3) filter by version to analyze (when several assemblies with the same name are found in the folders referenced by the NDepend project, NDepend will analyze assemblies with highest version, so as in 2) this can be controlled by changing folders referenced in Project Properties > Code to Analyze > Folders)
-
Travis Illig
commented
Additional explanation - The problem I'm describing is: I don't have an application, I only have a set of dependencies, and I want to analyze how those dependencies relate.
I can manually download and extract the NuGet packages into a location and then set up an NDepend project based on that, but then I have to manually reference the specific assemblies from the specific framework folders. What I was describing and hoping for is more automation than that - a packages.config + a target framework and that's the whole thing.
- We have a lot of "framework" dependency packages we publish
- We have a lot of applications that consume various combinations of these dependencies but
- We don't have a single application that consumes all of the framework dependency packages at the same timeSo there's not a great way to get an overall view of the framework without creating a fake project that references all of the framework packages at once. I'm hoping to bypass that need by just providing the list of NuGet packages and having "magic happen" under the covers to do whatever needs to happen to do the complete framework analysis.
