.NET - supporting .nuspec and Directory.Build.props?

[skolima]

Related to #541 , there's two more files related to NuGet updates: .nuspec and Directory.Build.props. Would you consider updating those as well in the future?

Disclosure: I'm one of the devs at https://github.com/NuKeeperDotNet/NuKeeper , and I think it's awesome dependabot got acquired by GitHub and it would be amazing to have feature parity 😄 Unfortunately, my Ruby skills are nonexistent, I'd be more than happy to answer any obscure NuGet/.NET/MSBuild questions.

So: .nuspec : this is the file describing how a NuGet package is published from a project. The "modern" .NET projects using <PackageReference/> format will generally have .nuspec generated automatically and there will be nothing to update. The older projects might have a version range specified there (not that common, AFAIK) or a fixed version, in line with what is in packages.config. In that last case, this file would need to be updated to stay in sync with packages.config.
MSDN .nuspec file reference
NuKeeper .nuspec update code

Directory.Build.props on the other hand is relevant only to the "modern" project format: it's a file automatically merged with every project in its folder and subfolders. Quite useful for specifying things like compilation settings, copyrights, versions - and shared references, like analyzers. This file can be updated (and has the same syntax) as a .csproj.
MSDN introduction (rather barebones)
Sample use with shared build analyzer settings
NuKeeper Directory.Build.props update code

[david-driscoll]

Any progress on this? 😄

[greysteil]

We already fetch Directory.Build.props files and update them, but not .nuspec ones (yet).

[greysteil]

And more generally, thanks for opening this @skolima, and for all your work on NuKeeper. I'm super keen to get to feature parity, but we're still a tiny team on Dependabot (we don't have much additional resource from GitHub yet and have a lot of additional work integrating directly into GitHub and dealing with a 1000x scale increase). We'll definitely get to this and PRs are very appreciated (although I understand not easy since Dependabot Core is in Ruby).

[skolima]

Update regarding the Directory.Build.props: there's a (minor) bug where currently Dependabot does not detect if that dependency has been updated externally and the PR is no longer needed, like it does for other updates - the PR is not auto-flagged and closed. Mentioning it with @dependabot rebase will correctly detect and close.

Repro repository: skolima/dependabot-props-problem#3

[greysteil]

Good catch! Fixed by 55aab50. Thanks for the heads up.

[SeanFeldman]

@greysteil, is this issue still open as there's more to be done or can it be closed?

[greysteil]

I think there's more to be done - the fix commit I mentioned above was for a small issue @skolima pointed out, not the full details of the issue body.

I don't work on Dependabot anymore (these days I'm a product manager for code security at GitHub, which is pretty much all our security stuff except dependency related things), but you're in safe hands with @feelepxyz and the rest of the team.

[SeanFeldman]

Thank you, @greysteil.

@feelepxyz, could you please confirm that Depedabot respects Directory.Build.props? And if not, clarify what's missing? Thank you.

[feelepxyz]

@SeanFeldman dependabot should fetch and update Directory.Build.props files, the issue is also asking to update .nuspec which isn't currently supported.

[SeanFeldman]

Right. Perhaps considering an update to the issue description to have a list with Directory.Build.propschecked off and . nuspec not would make it easier to see at a glance what’s the status? Or, closing this issue with a link to a specific one for .nuspeconly?
Regardless, thank you @feelepxyz for the clarification.

[Jaxelr]

I'm not sure if i should open a new issue for this, but feel free to point me in the correct direction, i posted it here since this issue seems to be connected to the usability of Directory.build.props

I have this repository that has the following structure:

And inside the OpenCar folder a .csproj:

ive configured the following dependabot.yml file with the structure:

version: 2
updates:
  - package-ecosystem: "nuget"
    directory: "/OpenCar" #OpenCar.csproj
    schedule:
      interval: "weekly"
      day: "monday"
    commit-message:
      prefix: "deps"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
  - package-ecosystem: "nuget"
    directory: "." #Directory.build.props
    schedule:
      interval: "weekly"
      day: "saturday"
    commit-message:
      prefix: "deps"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"

For the csproj it works as intended, but for reading the Directory.builds.props i get the following error message

Which would exclude the .props file from being used as a proper entry file.

[pellared]

I had the same issue as @Jaxelr . Dependabot only bumps Directory.Build.props located in the same directory where .*proj is present.

I came up with following workaround but I find it inconvinent: open-telemetry/opentelemetry-dotnet-instrumentation#698

Can you also bump packages in Directory.Build.props that are located higher in directory structures?