Add C# project support

[supermomonga]

This Pull Request adds support for C# projects (.csproj files).

.csproj files may contain not only the Version attribute but also the VersionPrefix and VersionSuffix. These Version, VersionPrefix, and VersionSuffix tags are interdependent, and when dealing with prerelease versions (e.g., v0.0.1-beta.1), all of these attributes must be considered. However, as my understand, bump-request action is currently not concerned with prerelease versions. so this Pull Request only handles the Version attribute.

ref:

• https://learn.microsoft.com/ja-jp/nuget/reference/msbuild-targets#pack-target
• https://learn.microsoft.com/ja-jp/dotnet/core/tools/dotnet-pack?tabs=netcore2x#options

[r7kamura]

I have no idea about csproj, but I am positive about supporting it 👍

[r7kamura]

I'm not sure if this code will really work. Sorry to take your time., but can you provide some sort of sample project where we can verify that this works correctly?

[r7kamura]

In the case of gem, we need to update the Gemfile.lock when we change the version (by running bundle install),
but in the case of csproj, is there no need to add such a process? Is it that there is no culture to include such files that define dependencies to Git?

bump-request/src/changeVersion.ts

Lines 42 to 49 in 8f0fb42

	function changeGemVersion(version: string) {
	replaceContent(
	fs.expandGlobSync("lib/**/version.rb").next().value.path,
	/VERSION = (['"]).*?\1/,
	`VERSION = '${version}'`,
	);
	exec.exec("bundle", ["install"]);
	}

---

(btw, this is totally unrelated to this pull request, but for some reason this gem support is not working properly at the moment, and I'm still investigating the cause...)

[supermomonga]

I'm not sure if this code will really work. Sorry to take your time., but can you provide some sort of sample project where we can verify that this works correctly?

Yeah, of course! I'll create a sample repository.

In the case of gem, we need to update the Gemfile.lock when we change the version (by running bundle install),
but in the case of csproj, is there no need to add such a process? Is it that there is no culture to include such files that define dependencies to Git?

There is opt-in lockfile. When we define RestorePackagesWithLockFile as true in csproj file, packages.lock.json file will be generated, and used by dotnet restore command (equally to Ruby's bundle install command)

ref: https://learn.microsoft.com/ja-jp/azure/devops/pipelines/artifacts/caching-nuget?view=azure-devops

I added restore command at f3e4ba6 cd7f2c5.

[supermomonga]

@r7kamura I created a sample repository. Could you check it?

https://github.com/supermomonga/bump-request_CSharpDemo

I created a demo branch and apply temporally change to action.yml for demo use, and sample repository use this.

• supermomonga@204ebc2
• https://github.com/supermomonga/bump-request_CSharpDemo/blob/6987863d8984dfc3f02a514c0ef27d243b575099/.github/workflows/bump-request.yml#L22-L23

PRs created by bump-reqeust workflow

• with RestorePackagesWithLockFile disabled csproj
  • manual input: Change version to 0.0.2 supermomonga/bump-request_CSharpDemo#1
  • "patch" selected: Change version to 0.0.3 supermomonga/bump-request_CSharpDemo#2
  • "minor" selected: Change version to 0.1.0 supermomonga/bump-request_CSharpDemo#3
• with RestorePackagesWithLockFile enabled csproj
  • "minor" selected: Change version to 0.1.0 supermomonga/bump-request_CSharpDemo#4

[r7kamura]

Looks generally good.

In the case of gem, we need to update the Gemfile.lock when we change the version (by running bundle install),
but in the case of csproj, is there no need to add such a process?

I made the above comment because I thought it was supposed to include its own version in packages.lock.json, like Gemfile.lock, so I thought we needed to run some command to update the embedded version. But in fact, that is not how packages.lock.json works, is it? If so, there may be no benefit to running dotnet restore here at all. What do you think about this?

[supermomonga]

Ah, I got your point now.

I made the the above comment because I thought it was supposed to include its own version in packages.lock.json, like Gemfile.lock, so I thought we needed to run some command to update the embedded version. But in fact, that is not how packages.lock.json works, is it? If so, there may be no benefit to running dotnet restore here at all. What do you think about this?

Yes, you right.

Just to be sure, I also checked the specifications for NuGet Package (equivalent to a gem in Ruby), but it seems that the version of the library itself is not used.

I removed dotnet restore command.

[r7kamura]

Just released v0.5.0, thank you!

• https://github.com/r7kamura/bump-request/releases/tag/v0.5.0

[supermomonga]

@r7kamura Thanks ✨