Posted on March 18, 2014
NuGet provides few different methods of restoring missing NuGet packages during application development on in Continuous Integration environment. In this article we’ll review these methods to find out which one to choose for using in AppVeyor CI environment.
After reading the original NuGet Package Restore article on NuGet docs web site we see that today we have three options for restoring packages:
Important note here - not before, but during MSBuild process. This is accomplished by injecting nuget.targets into build pipeline, so you end up with .nuget folder in your solution. This method works in build environment and requires consent which is EnableNuGetPackageRestore environment variable (it’s ON by default starting from NuGet 2.7 but we set it in AppVeyor environment for compatibility with previous NuGet versions). Starting from NuGet 2.7 this method is considered as obsolete as it requires additional folder with nuget.exe, nuget.targets and do not work in some scenarios (remember that chicken/egg problem with BCL packages.
This method is part of NuGet Visual Studio add-in (.vsix), heavily relies on VS events and works in interactive mode, not build environment. Excerpt from that page:
In other words, restore occurs in Visual Studio and before MSBuild process.
The method was always there, but “was improved in NuGet 2.7”. This is exactly what we need and do in AppVeyor build environment! All that you need is to put “nuget restore” command into “Install scripts” or “Before build scripts” box of your project settings:
or in appveyor.yml:
before_build: - nuget restore
Hope that helps.
Posted on February 23, 2014
The vast majority of AppVeyor customers use Git, specifically GitHub. Historically, we’ve been using Mercurial for AppVeyor source control, but recently due to the growing popularity and ecosystem of Git and GitHub we thought maybe it’s time to jump Git train and start using it for AppVeyor projects.
The first problem we faced with was converting existing Mercurial repositories to Git with preserving all history and authors. If you search in Google for converting mercurial to git on Windows you will find some (mostly similar) posts on SO, but none of them worked for us if followed “as is” on Windows. After many trials we found the way that 100% works and could be easily reproduced - everything was done from scratch on a clean Windows Server 2012 machine.
We assume you start from a clean Windows Server 2012 machine.
Open command line prompt and make sure all tools are available in the
PATH: hg, git, python.
We will be doing everything in
Open command prompt.
Clone source Mercurial repository:
hg clone https://bitbucket.org/appveyor/demoapp
Create an empty GitHub repository and clone it to
git clone https://github.com/AppVeyor/DemoApp.git demoapp_git
git clone http://repo.or.cz/r/fast-export.git
c:\projects\fast-export\hg-fast-export.py in Notepad and replace highlighted region with the code below:
#!/usr/bin/env python # Copyright (c) 2007, 2008 Rocco Rutte <firstname.lastname@example.org> and others. # License: MIT <http://www.opensource.org/licenses/mit-license.php> import sys # import mercurial libraries from zip: sys.path.append(r'C:\Program Files (x86)\Mercurial\library.zip') from mercurial import node from hg2git import setup_repo, fixup_user, get_branch, get_changeset from hg2git import load_cache, save_cache, get_git_sha1, set_default_branch, set_origin_name from optparse import OptionParser import re import os
Copy content of
demoapp_git ignoring .git folder.
If you need to map authors to new repository with different name/email create
authors.txt with one mapping per line (old=new), like below:
Feodor Fitsner <email@example.com>=Feodor Fitsner <firstname.lastname@example.org>
Run Python script to import Mercurial repo into Git one (you are running this script from Git repository directory):
hg-fast-export.sh -r c:\projects\demoapp -A authors.txt
Checkout HEAD to check that everything looks good:
git checkout HEAD
Remove conversion files:
git clean -f del /Q hg2git.pyc
Rename .hgignore to .gitignore:
ren .hgignore .gitignore git add .gitignore git commit -m ".hgignore renamed to .gitignore"
Push Git repo to GitHub:
git push -u origin master
Posted on February 21, 2014
NOTE: NuGet support is available in AppVeyor CI 2.0 which is currently in beta. Please see this post for AppVeyor 2.0 announcement and sign up information.
AppVeyor CI has native NuGet support which becomes de-facto a packaging standard for .NET libraries and applications.
Every AppVeyor account comes with following built-in NuGet feeds:
Account NuGet feed aggregates packages from all project feeds and allows publishing of your custom packages. All account feeds are password-protected. You can find account feed URL and its API key on Account → NuGet page:
You can use your AppVeyor account email/password to access password-protected NuGet feeds although we recommend creating a separate user account just for these purposes (Account → Team).
If you use GitHub or BitBucket button to login AppVeyor you can reset your AppVeyor account password using the Forgot password link.
For publishing your own packages to account feed use the command:
nuget push <your-package.nupkg> -ApiKey <your-api-key> -Source <feed-url>
<feed-url> with values from Account → NuGet page.
Project feed collects all NuGet packages pushed to artifacts during the build. Project feed is password-protected if the project references private GitHub or BitBucket repository; otherwise project feed has public access:
You can enable automatic publishing of NuGet packages during the build on Build tab of project settings. When it is enabled AppVeyor calls
nuget pack for every project in the solution having
.nuspec file in the root and then publishes NuGet package artifact in both project and account feeds.
To generate a
.nuspec file for your project run the following command from project root directory:
To push NuGet package as artifact and publish it in both project and account feeds use this command anywhere in your build script:
appveyor PushArtifact <your-nugetpackage.nupkg>
When you delete a project in AppVeyor its corresponding NuGet feed is deleted, however all NuGet packages from that feed remain published in account feed.
To configure custom feed in Visual Studio open Tools → Options → Package Manager → Package Sources and add new feed.
When you first open Manage NuGet packages dialog you will be presented with a dialog box asking for credentials:
To configure private NuGet feed on your development machine run this command:
nuget sources add -Name <friendly-name> -Source <feed-url> -UserName <username> -Password <pass>
You may use account feed to publish your external packages that can be further referenced during AppVeyor builds.
To configure AppVeyor project to use private NuGet feed during build you can use the following approach:
Into Install script box add this command:
nuget sources add -Name MyAccountFeed -Source <feed-url> -UserName %nuget_user% -Password %nuget_password%
<feed-url> with URL of your account feed.
To restore Visual Studio solution NuGet packages before build add this command to Before build script box on Build tab of project settings (provided your
.sln file or
packages.config are in the root of repository):
otherwise if project solution is in sub-directory:
nuget restore <solution-folder>\<solution.sln>
Posted on February 19, 2014
After 4 months of intensive development we are excited to announce a public beta of AppVeyor 2.0! The new release provides you with whole new experience: build environment that is under your full control, large projects support with build matrix and parallel testing, scriptless deployment and release management!
You could see those great features in flagman continuous integration services for Linux such as Travis CI, but not for Windows up until now. Today, I’m really proud to say that AppVeyor is the only CI solution for Windows that offers dedicated build machines with admin access, build matrix with jobs parallelization and integrated deployment.
In AppVeyor 2.0 we are moving away from shared build servers to dedicated VMs. Every build job runs on pristine VM with admin rights! This was probably the main reason for kicking-off this release.
AppVeyor 2.0 has built-in hosting for private and public NuGet feeds.
Every account comes with a private password-protected NuGet feed aggregating packages from all projects and enabling publishing of your custom packages.
Projects have separate NuGet feeds with all NuGet packages pushed as artifacts.
Easily build/test for multiple configurations. Specify which operating systems, build configurations and platforms you would like to include into build matrix and AppVeyor will start a build with multiple jobs for all combinations.
Build matrix supports the following dimensions:
Large projects can contain hundreds and thousands of tests that could run for hours. AppVeyor 2.0 allows to split your tests into groups by categories, assemblies or custom criteria and run them as build jobs in parallel thus drastically reducing overall build time.
AppVeyor 2.0 has scriptless, repetitive one-click deployment to multiple environments! Deploy as part of the build or promote releases later - manually or through API.
Supported deployment providers:
Great Windows software must provide user interface for any function it has. AppVeyor 2.0 follows this tradition and further extends project settings, so you can control build environment and inject custom script logic on any stage of build pipeline without ever touching your repository!
For command-line gurus or those coming from Linux we added fancy YAML configuration support! Add appveyor.yml with project configuration into root of your repository and next time you fork the repo just add a new project in AppVeyor.
AppVeyor 2.0 has completely re-designed UI to get results faster and on the go!
AngularJS, SignalrR and Foundation helped us to build great experience we’re really proud of:
Enjoy the beta!
Feodor Fitsner, AppVeyor founder and developer
Posted on October 01, 2013
In this short presentation I’m talking about AppVeyor CI features and benefits, comparing it to the existing continuous integration solutions and giving some hints about future plans.