[ASPNETCORE] Add support for central package version management

[wing328]

based on #20192

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[Urganot]

I fixed it and opened up a new pr #20403 #20403

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/12636467556/job/35208601636?pr=20401

@Urganot can you please review the build errors when you've time?

[wing328]

FYI. Tested with optout and the output built locally without errors.

[Urganot]

I know what happens here.
Because there is no version in the csproj file, it tries to use the lowest possible. this obviously doesnt work.
In this case this is the correct behaviour though. when using centralized version management, you need to have a Directory.Packages.props file in your solution folder. in there you set the version of your packages. Without this file, it will fail. The problem is that generating this file into the generated project would defeat the purpose of this change because I want to control my versions from my non generated solution.
When using optout, it will put in the package versions. that is why it work in that case
I am not sure how this should be handled.

[wing328]

Without this file, it will fail. The problem is that generating this file into the generated project would defeat the purpose of this change because I want to control my versions from my non generated solution.

how do you use it in your non-generated solution?

maybe creating a simple HelloWorld C# project/app that depends on or consumes samples/server/petstore/aspnetcore-8.0-use-centralized-package-version-management ?

[Urganot]

Without this file, it will fail. The problem is that generating this file into the generated project would defeat the purpose of this change because I want to control my versions from my non generated solution.

how do you use it in your non-generated solution?

maybe creating a simple HelloWorld C# project/app that depends on or consumes samples/server/petstore/aspnetcore-8.0-use-centralized-package-version-management ?

You mean as demo or to fix the error?

[Urganot]

I created a simple repo showing how it works: https://github.com/Urganot/OpenApi-Centralized-Package-Demo

It doesnt matter how I use the generated project. What matters is that there is a Directory.Packages.props file somwhere between root and the .csproj file in question.
If you want to test it, you can just delete the Directory.Packages.props and try to build. It wont work

[wing328]

what about manually adding Directory.Packages.props to samples/server/petstore/aspnetcore-8.0-use-centralized-package-version-management so that the build passes?

[Urganot]

If that is ok for you, I can do that.

[Urganot]

#20486