Travis Illig
My feedback
3 results found
-
39 votes
An error occurred while saving the comment An error occurred while saving the comment 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.
Travis Illig
shared this idea
·
-
13 votesTravis Illig
shared this idea
·
-
23 votesTravis Illig
supported this idea
·
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.