NuGet packages should be updated on successful Appveyor build.

[atheken]

https://github.com/tgjones/dynamic-image/blob/master/appveyor.yml Indicates that the package should be published to NuGet based on a successful build. However, the package appears to be @ v3.1.1 on the NuGet site: http://www.nuget.org/packages/DynamicImage/

[tgjones]

At the moment, NuGet packages are only published to AppVeyor's own feed, which you can add to Visual Studio as a custom NuGet feed: https://ci.appveyor.com/nuget/dynamic-image-sbekf7l3coym

I should update the readme to include that URL.

I know I could push pre-release packages to NuGet on every successful build, but I felt it would clutter up NuGet too much. What do you think? (I remember your name from NoRM, which I used a lot back in the day, so thank you!)

It is about time for a new release though.

[atheken]

I think AppVeyor allows you to build when commits are tagged? What do you think about causing tagged commits to publish to both AppVeyor and NuGet.org feeds? Seems like this would allow "automatic" releases for builds that you'd want on both feeds. (I'd be happy to work on the config for this in a fork)

Separately, it's pretty awesome that you were able to leverage NoRM. And, thanks for continuing to maintain this package, which works great for my needs! :+1:

[tgjones]

Hi @atheken - sorry for the delay, this slipped off my radar.

I've had a look at setting up appveyor.yml to push to NuGet after a tagged commit, but I can't figure out how to do use one appveyor.yml file to do both:

• push to AppVeyor for every build, with a 3.2.0-ci{build}-style version number
• push to NuGet after a tagged commit with a 3.2.0-style version number

I think the key must be to use the actual tag name, which AppVeyor puts into an environment variable, as the build number - but only for tagged builds. It's that last bit that I can't figure out.

If your offer of having a look at this is still on the table, then I'd appreciate any input you may have. Ideally, I'd like to keep using one AppVeyor project, with one appveyor.yml, and no custom PowerShell scripts, but maybe that's not possible.

This is the closest I've found to what we're trying to do - but they use a couple of PowerShell scripts: https://github.com/SEEK-Jobs/pact-net/blob/master/appveyor.yml

[atheken]

Hey Tim,

I just had to battle with this a few days ago, here's what came up with:

https://github.com/wildbit/postmark-dotnet/blob/master/appveyor.yml

(And it works)

[atheken]

@tgjones - I guess I should mention that this does unfortunately require a very short script to "poke" the version in the Nuspec, but I am not even 100% sure this is the best way to go to update the version. I also don't customize the version number when posting to the AppVeyor feed, as this seems like it's primarily "private/CI-ish" to begin with.

[tgjones]

Awesome, thank you.

Customising the version number when posting to the AppVeyor feed seemed like a nice idea at the time - "these are the pre-release packages for 3.2.0, and then here's the actual release" sort of thing, as opposed to pre-release package versions that can't easily be matched up with proper releases. I also link to the AppVeyor feed in the DynamicImage readme, so I have some motivation to use a sensible versioning scheme. It does seem difficult to automate though.

If I understand poke-nuget-version.ps1 correctly, you end up with AssemblyVersion / AssemblyInformationalVersion numbers different from the NuGet package version? And for CI builds, the AppVeyor NuGet feed just has a single integer for the version number?

(I just installed the Postmark NuGet package; the DLL version for the 2.0.0 NuGet package is 1.6.1.0?)

[tgjones]

(I don't know how important DLL version numbers are; I don't care about them myself, but I have historically tried to match them up with the NuGet version number. I guess it helps when trying to debug a version mismatch.)

[atheken]

@tgjones Yes, I want to match the version numbers with the public packages, too.. I guess I thought I had resolved this in the Postmark packaging. I'll need to spend some time resolving this in that DLL, and then I will point you at the fix, no need for us to duplicate effort to achieve the same goal.

With respect to the CI build version matching, another way to (partially) handle this is to include the git-sha in the assembly info. This, again, is something that I want to do on the Postmark DLL.

I'll probably have a chance to fiddle with this in the next day or two and will get back to you.

[tgjones]

Thank you! I'll look forward to seeing how you get on.

One gotcha with the CI build version number is making it sequential from a NuGet point of view, where "3.2.0-ci10" < "3.2.0-ci2". I know they've fixed that in NuGet 3.0, but I don't think that's been released yet. In DynamicImage, I workaround the issue by resetting the AppVeyor build number to 1000 for each new Major.Minor.Patch version number. It's another thing to remember to do, and would be nice to remove from the build process!