Point pathFilters to a csproj and use <ProjectReferences> as filters

[Cjewett]

We want to increment the version of a project anytime it or one of its project references change. We can manually specify the paths in pathFilters but that requires manual updates to version.json anytime a developer adds or removes a project. Is this possible within the current feature set? We don't want to add a version.json in a parent directory because monolithic repository problems.

I'm thinking about writing a tool internally that updates the version.json pathFilters to include the ProjectReferences as an MSBuild task but that still requires developers to remember to check it in. I wanted to ask before working on this because it seems like it could be a common use case. Is this already possible? If not is this a feature this project would be willing to include?

[KalleOlaviNiemitalo]

There is no such feature in NBGV itself, but some users have apparently implemented tools like that. See #800 about the resulting performance problem.

[Cjewett]

There is no such feature in NBGV itself, but some users have apparently implemented tools like that. See #800 about the resulting performance problem.

Thanks for linking that! Looks like there is some history related to this so I'll take a look.

[AArnott]

Thanks for sharing your thoughts and ideas. Maybe we could even incorporate that tool with nbgv if you build it.

[Cjewett]

@AArnott I took a quick look and wanted to get your thoughts to see if this functionality could be baked into nbgv.

My current thinking is creating a UseProjectReferenceAsPathFilter property (naming can be changed of course) which can be set to true or false. It will look for a csproj in the same directory as the version.json, load its direct and transitive project references, and then include the directories of those project references in the includePaths set here and here. If a csproj doesn't exist then it will throw an error explaining the setting should only be set to true if the version.json lives in the same directory as one with a csproj file. Some edge cases to deal with but wanted to get thoughts on general thought process first.

Does the above sound sane?

[AArnott]

@Cjewett sounds great, and I knew requests like this would come in when we did the original feature. But it's far too expensive at runtime to do that, considering we need it for every single commit. If we have a version height of 200, for example, we'd have to evaluate n msbuild projects and resolve their project references for each of those 200. Your build perf would crawl if we did that.
Alternatively though, one could devise an msbuild Target that looks at the project reference graph at build time (when the work has already happened) and update the version.json file with the list of paths to consider significant during the build. That way, any time your build changes the version.json file's list of references, you could commit those, and NBGV would benefit from it without having to repeatedly compute the same values.
And that could be done totally externally to NB.GV. And if it works well, we could evaluate making it a part of this package.

[Cjewett]

@AArnott Understood. I'll take a look at that approach and report back when I have some type of PoC.

[Cjewett]

We went the MSBuild task route that updates the pathFilters property in version.json during compilation. In addition to that we use a tool that verifies the pathFilters match what we expect.

• Local builds will update version.json so you can check in the changes.
• CI builds will fail the builds early if your version.json doesn't match what we expect.

We've had it running for a while and haven't had any complaints or performance concerns, so we'll be sticking with it. We have an effort internally to look in at open-sourcing some of our tooling in the future so we're not having to replicate logic elsewhere. Closing this ticket out since there's no intent to make changes in this repository.