standard-version icon indicating copy to clipboard operation
standard-version copied to clipboard

Could this work on .NET projects?

Open gh0st opened this issue 5 years ago • 8 comments

I know most of this is dependent on your git commits. But where it tracks your version depends on if you have a package.json or composer.json. So what if you wanted to use standard-version on a .NET C#, VB.net, or even SQL project? These projects use a .vbproj, .csproj, .sqlproj, file for tracking version numbers. Is there a possibility of standard-version supporting these types of projects too?

gh0st avatar Jul 17 '19 14:07 gh0st

Hey! Thanks for the report. This has been asked for a few times (in slightly different ways), it's a feature (support for any file/project type) that I'd love to get implemented and have started to work toward in #372

jbottigliero avatar Jul 18 '19 14:07 jbottigliero

Hello @jbottigliero. There are to many project types to support :) Is there an option to print/set variable with version number without doing any updates or commits? It will be ideal option for all CI scenarios as this systems already have tasks for bumping version numbers for various projects, but as I found, they still don't support Semantic Commits.

FixRM avatar Jul 19 '19 07:07 FixRM

@FixRM – if I'm not mistaking, I think what you are looking for would be a combination of the existing --release-as flag along with the configuration of the upcoming feature to allow your version to be both read and written to any file (or files) of choice.

Your specific mention of "[...] already have tasks for bumping version numbers for various projects [...]" does have me thinking of potentially broadening support for executables instead of just Javascript-based "package file updaters".

jbottigliero avatar Jul 19 '19 17:07 jbottigliero

You can set this up manually by using the post-bump hook in standard-version config to modify the desired {project-name}.csproj and sync it with the package.json file. Though what is being put together in the PR mentioned above is nicer.

If anyone's interested the implementation I've got so far is detailed below.

Note The below assumes a folder structure like:

├──┬╴ src/
│  └───┬╴ {project-name}/
│      └──── {project-name}.csproj
│ 
├──┬╴ scripts/
│  └─── sync-version.js
│
├── package.json
└── .versionrc
  1. Setup a package.json file with standard-version and replace-in-file as dev dependencies (also ensure node and npm are installed on the machine).
  2. Add .versionrc file as follows (replacing {path-to-project}/{project-name} with relevant values):
{
  "scripts": {
    "postbump": "node ./scripts/sync-version.js && git add src/{project-name}/{project-name}.csproj"
  }
}
  1. Add a file called sync-version.js to a top level scripts/ folder with the following contents:
/**
 * sync-version.js: Utility script to sync version changes from package.json --> csharp project.
 */

const replace = require("replace-in-file");
const npm = require("../package.json");

// Configure replace-in-file options.
const options = {
  files: "src/**/*.csproj",
  from: /<Version>(.+)<\/Version>/g,
  to: `<Version>${npm.version}</Version>`
};

// Perform the replacement.
replace(options).catch(error => {
  console.error("Failed to synchronize npm version:", error);
});

console.log("[INFO] finished synchronizing version");

And that should do it. A working implementation of this can be found in one of my current projects Muster.Core if you want something concrete. If we do get support for doing this through standard-version then there shouldn't be a need to go through this process, but a single extra js file and a line of config is acceptable for me at the moment.

isaac-brown avatar Jul 20 '19 11:07 isaac-brown

Thanks @isaac-brown,

Not sure how can it help to avoid tagging and pushing something to master.

FixRM avatar Jul 21 '19 16:07 FixRM

@isaac-brown, now i see, you are sending skip parameters. By the way, you don't need .versionrc file, you can put scripts to package.json under "standard-version" node

FixRM avatar Jul 23 '19 08:07 FixRM

You could use a custom updater. Here's what I did for my .net core 3.1 C# projects:

  1. In the same folder as your .versionrc file, add a file named dotnet-version-updater.js:
module.exports.readVersion = function (contents) {
  const regEx = /<Version>(.*)<\/Version>/g;
  const arr = regEx.exec(contents);
  if (arr !== null && arr.length === 2) {
    return arr[1];
  }

  return "";
}

module.exports.writeVersion = function (contents, version) {
  return contents.replace(/<Version>.*<\/Version>/, '<Version>' + version + '</Version>');
}
  1. Then in your .versionrc file:
{
...
  "bumpFiles": [
      ...
      { "filename": "PATH_TO_YOUR_CSPROJ_1", "updater":"dotnet-version-updater.js" },
      { "filename": "PATH_TO_YOUR_CSPROJ_2", "updater":"dotnet-version-updater.js" },
      ...
      { "filename": "PATH_TO_YOUR_CSPROJ_N", "updater":"dotnet-version-updater.js" },
      ...
  ]
  ...
}
  1. Make sure all your .csproj files have a Version tag, ex:
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <Version>1.2.3</Version>
  </PropertyGroup>

The dotnet-version-updater.js is simply using a regex, so if the Version tag doesn't exist, it won't be able to bump the file and won't create the Version tag. One improvment would be to make dotnet-version-updater.js add the Version tag if it doesn't exist.

I hope that helps.

Yanal-Yves avatar Sep 17 '20 17:09 Yanal-Yves

We are using it for .NET here: https://github.com/GetStream/stream-chat-net/blob/master/.github/workflows/initiate_release.yml

peterdeme avatar Apr 15 '22 14:04 peterdeme