Support for dotnet (prev. DNX) / .NET Core projects

[sunsided]

In DNX / .NET Core projects the version is set via the project.json file described here in the Metadata section. AssemblyInfo.cs on the other hand is gone. I'd like to use GitVersion with such projects.

[gep13]

Out of the box support for the project.json file seems like a natural extension for GitVersion.

There is nothing to stop you using GitVersion today though, you could execute the GitVersion.exe on your repository, establish what the asserted Semantic Version is, and then manually update the project.json file using perhaps a regular expression.

[pascalberger]

Should it really be the task of GitVersion to update versions in all possible project types? If this is in the scope of GitVersion I would suggest to introduce some kind of interface like it is already done for the build server which easily can be extended to other project types (we use GitVersion for example for SharePoint Add-ins which also have their own XML file which contains the version number)

[dazinator]

You would potentially need a composite of these updaters to run. For example if you had a solution containing a library (assembly info), a vsix package (xml), and an asp.net 5 website (project.json) you would want possibly all 3 to be updated.. or maybe just one. This would complicate things a bit for gitversion.

There must be existing tools out there for updating xml / json files..

[sunsided]

On a side note, project.json is really not just ASP.NET, but rather sort of the upcoming standard project type for .NET. With the framework multi-targeting it's a safe bet that sooner or later all NuGet projects will adapt to that one.

[gep13]

On a side note, project.json is really not just ASP.NET, but rather sort of the upcoming standard project type for .NET.

This was really my reasoning for including it within GitVersion. We have already included Assemblnfo.cs/.vb, which is the default .Net way of versioning a project. If project.json is becoming the new defacto, then IMO, this should also be included OOTB.

If we can setup something in the YAML file to make it more scalable, i.e. look for files matching this pattern, and replace entries with this pattern, with this GitVersion variable, then I would be all for that approach as well.

[sunsided]

You might want to know that DNX uses a versioning feature where a 1.0.0-* project version in project.json is rendered as 1.0.0 normally, but as 1.0.0-whatever when DNX_BUILD_VERSION=whatever is set in the environment. There also seems to exist DNX_ASSEMBLY_FILE_VERSION.

Also, commands defined in the project.json are directly executed by the DNX and this is generally done with the test command at the moment (see here):

"dependencies": {
        "xunit": "2.1.0-*",
        "xunit.runner.dnx": "2.1.0-*"
    },
"commands": {
        "test": "xunit.runner.dnx"
    }

Here xunit.runner.dnx (→ GitHub) is installed via NuGet. The canonical behavior seems to be to look for project.json files that contain this command and then execute dnx test in that directory as part of the build process (see below).

I could imagine hooking GitVersion in there with a version command.

"Default" build system

It's not necessarily directly related and I understand that not every scenario in the world has to be addressed by GitVersion, but this might be something you want to have an eye on.

The ASP.NET 5 team apparently uses KoreBuild and Sake as their self-contained cross-platform build system (which interestingly also has TeamCity integration) and it's getting some love in the community, e.g. here and here. There's a minimal example here, however there seems to be nada documentation available, like everywhere in the ASP.NET 5 world right now.

A very simple makefile.shade would look like this:

var VERSION='0.1'
var FULL_VERSION='0.1'
var AUTHORS='Contributors'

use-standard-lifecycle
k-standard-goals

From _use-standard-goals.shade it would seem that VERSION and FULL_VERSION are used to update AssemblyInfo.cs files if found, FULL_VERSION is in addition passed to nuget pack as the package version. The _k-standard-goals.shade in the Universe repo linked above skips that part and does not seem to patch project.json, however. There are git commands in the standard shadefiles, so this might be an interesting approach to integrate GitVersion in the build process as a use-gitversion step.

[clairernovotny]

There are now support for pre/post build script commands in beta 8 of the DNX tooling. This may be possible now....

[olivier-spinelli]

Unfortunately not. I tried to use prebuild to alter the project.json file with the semver version computed from the repository. The issue is that project.json is NOT read again after prebuild commands have been executed (same for prepack).
(Note: the generation of the AssemblyInfo.cs is okay: the Version, FileVersion and InformationalVersion are correctly compiled).

[sunsided]

Crap, sorry, accidentally hit the close button.