Adding a command line argument for including the transitive project dependencies of the projects found in the initial scan directory

[jeremy-allocate]

Let me know if it's unclear what this does, I can post some diagrams to illustrate if so.

[jeremy-allocate]

{ get; set; } not needed on private vars.

[jeremy-allocate]

If the option is on, find the directory for all of the projects this project depends on, and add all of them that aren't already in the list to the list of directories to run discovery on. This lets one chase a dependency hierarchy for a single project all the way to the root through lots of directories and build a much more meaningful graph than one that just has it's projects and the single projects it depends on (when you run it focused on a single project directory in a solution for example).

[jeremy-allocate]

doc updates!

[jeremy-allocate]

Command line support.

[madushans]

I'm not sure how this related to #25 as it is asking to visually isolate/filter existing output.

From the implementation, I think this is similar to #34 ?

Keen to see your illustrations for this one.

My concern with this is that I don't want to make the tool search outside of the specified folder. User probably don't expect the tool to do it anyway. If this is required, currently there are 2 options.

1. Start the search higher up in the directory tree (and exclude the ones you don't want searched via -ExcludeFolders option)

2. Somewhat convoluted (on Windows) is to setup symlinks within your src folder. (and use `-FollowReparsePoints option)

There's also things like git submodules, which should be covered inder second option above.

Assumption (which I'm feeling may be is broken) is that your repository is in a folder so when you load the solution in to your IDE, it should find it inside that folder. So if DependenSee is run within the repo folder, everything the IDE would see should be visible this way.

I understand some projects may have setups where they rely on a directory structure outside if the repository (for whatever reason). For these my current thinking is that these scenarios are serviceable using above options.

I should also mention there has been a feature almost shipped to do the discovery based on one or more .sln files. (see #27) but I think this will also be isolated within the solution folder. I really thought this was already in main but looks like I've decided to move that to v3 release which, unfortunately isn't progressing at the moment. (Explains why this switch isn't in CLI docs.)

I'm not sure what I'm missing here to understand your use case, so keen to see your illustration.

[jeremy-allocate]

You can classify it however you'd like, I see this as a command-line way of obtaining the kind of focus within a large solution this question was seeking.

Either way, we could easily read the solution file and keep you within the solution when we add the additional directories. But remember that project references are EXTREMELY unlikely to point at something outside of the solution anyway.

I don't use reparse points or symlinks in my solution, and I wouldn't add them to get an analysis tool to do what I'd like it to.

There are too many folders to exclude, so that doesn't work either. Only this approach got me the diagram I needed. I'll post some redacted diagrams in a bit to illustrate.

[jeremy-allocate]

Is there some way I can send these diagrams to you privately @madushans? I want to include the diagram of my entire solution for context, but it's impractical for me to redact that so it can be posted here. Email maybe?

[madushans]

I think I get the end goal.

You have a large solution where you want discovery to be done based on a given project, rather than seeing all the projects in the folder/solution.

So if you have the below graph.

project1 -------> project2 ----> project3
                     /\            |
                      |            |
   project3 ---------+             +----> project5

And you're "focusing" on project2, you want to see something like below

project2 ----> project3
                   |
                   |
                   +----> project5

Since you're only focusing on downstream dependencies, and don't want to see what's "above" that level.
I hope I'm getting this right?

Currently the only way to do this is to exclude all the other projects, which is not practical. (Exclusion was implemented for scenarios like excluding test projects .etc.) So I see a use for this in large solutions and/or mono repos.

Let me have a think about what the best approach for this can be. Command line arguments are already getting a bit out of hand, so I don't want to build too many of them that might make things hard to maintain down the road.

Currently your solution is to have something like this

DependenSee -SourceFolder projectFolder -IncludeTransitiveProjectDependencies ...

I'm still against the tool searching outside what's provided in the -SourceFolder argument. I'm thinking may be something like below.

DependenSee -SourceFolder solutionFolder -DiscoverFrom projectFile ...

e,g:
DependenSee -SourceFolder C:\Repos\MyRepository -DiscoverFrom SomeProject\SomeProject.csproj ...

This way IMO the experience is a bit better.

• User still explicitly specifies the solution folder, so the bounds of the search is readily apparent.
• DependenSee can check and refuse if the -DiscoverFrom is outside the specified source folder, and if any downstream refs fall outside the source folder.
• DependenSee also use the relative path (relative to source folder) as the ID of each project. If this falls outside and we were to include the full path, that may reveal private details like username and OS which I'd like to avoid. see Privacy Note.

We should also be able to accept multiple projects in this new switch, if we want to do the discovery from multiple locations of the graph. We could also accept just a folder, instead of a project file, which might be better. I think vis.js can handle multiple "islands" in the visualization, so things should be ok in that side.

I think this will not conflict with other switches, but give me some time to sleep on it, to see if I miss something.

[ransagy]

A bit of a revive, But some of the assumptions made here change when you consider that some references aren't projects in your solution/folder/control or even projects - they are NuGets.
Could be its outside the scope of this tool - I wouldn't say so, but possibly - otherwise seeing the transitive dependencies of whole NuGet package trees can be very helpful to know what a project/solution REALLY depends on.