Set the version number in the appveyor.yml

[kevinkuszyk]

@artiomchi what are your thoughts on this change?

We can now set the version number in the appveyor.yml and it will update the App Veyor build number, the nuget package version and version numbers in the built DLLs.

This is in preparation for the next PR which will:

1. Only add the -ci.{build number} suffix for builds which don't come from master.
2. Push the ci nuget packages to MyGet.

Later I'll add a step which will push tags from master to nuget.org.

[artiomchi]

I guess there are both upsides and downsides to this approach.. The main downside, as I see it is that any local builds lose any versioning whatsoever. That's why I kept them in the .csproj file. Plus the csproj is easy to update, both using VS or a text editor, and defines the version as part of the project, and not the build system configuration, which is another strong point as well.

Secondly, I like your idea of pushing master builds to NuGet, and other branches to MyGet with the -ci.{build} suffix. The issue is - you'll probably need two .yml files for that, which will keep the version in two places.

Here's my thoughts. After some research (and testing), I realised that the AssemblyVersion and FileVersion will fall back to the numeric part of the Version property, which in turn is based on VersionPrefix and VersionSuffix.

As such, we only need to set the VersionPrefix in the csproj, and that will set the version in all three fields (assembly, file and project version). Since we're in alpha, we can actually set the VersionPrefix setting to 1.0.0-alpha.1. If the suffix is left blank - then that will be the version of the package. But for CI builds, we can add the version suffix, which will mark the version as 1.0.0-alpha.1-ci.123

In summary, I prefer keeping the version in the .csproj file (using only the VersionPrefix field), and then have two (almost identical) deployment files (appveyor.yml and appveyor-ci.yml), with the only difference being the --version-suffix parameter used in the ci file. This will keep the version in a single place, linked to the code, and the build configuration will only affect ci versioning. It's also an easy way to implement #49 (Automate deployment to MyGet and NuGet.org) without duplicating logic or version information

What do you think?

[kevinkuszyk]

I think we may be able to get the best of both. After I pushed this I had a quick look at the MVC repro. They set the version number in the csproj and override the suffix on the build server.

From looking at the AppVeyor docs I think we should be able to do this with a single AppVeyor.yml file.

I'll see what I can come up with.

[artiomchi]

That sounds good.

The reason I suggested putting the alpha suffix in csproj too was to tag the codebase as v1.0.0 but also mark it as unfinished. Otherwise, just looking at the code it looks like it's "stable". Also, I'd prefer if we didn't have to touch the build scripts at all once you finished them, I.e. I think it would be bad practice if we had to change the build scripts / AppVeyor config every time we change the version modifiers. Keeping that in the csproj would mean we only change the project file every time we make a release, and the build config is set in stone

I'm curious to know how you'll make both build configs run off a single .yml. I haven't used AppVeyor extensively, so that's good to hear that it's possible - one .yml file is definitely better than two! Looking forward to this

[artiomchi]

As it's now superseeded by #60. I'm guessing you don't mind if I close this?