VSTS – Package Manager with NuGet (Part 2)

Having successfully added NuGet pack  and  push tasks to my Build within VSTS, the next task was to separate out the push from the Build and use it within a Release. The main reason for this is to provide greater control over when a package is pushed to the VSTS package manager rather than after each build.

The first modification is to the Build definition to remove the NuGet push task. Next, I created a new Release definition with a single environment I called Package Manager. The Release definition contained one task and that was the NuGet push command. Since we had already created the package as part of the Build, the path to the NuGet package(s) to publish is available for us to select.

nuget-push

Two points worth mentioning here.

  • The path uses *.nupkg to ensure the Release picks up the latest build of the package and not a specific version.
  • The path, …/Model-Packaged/… is an Artifact source alias defined in the Artifacts tab.
  • artifacts-source-alias

Once the Release environment has been created with the Push task pointing to our pre-existing Target feed we can create a release which will pick up the current NuGet package generated during the Build and push it into the feed in the Package Manager. One other point to remember is that the push will fail if you try to upload a package to feed with the same version number as the current package.

 

Advertisements

VSTS – Package Manager with NuGet

As our project has grown we have identified a number of occurrences where the same assembly is being used across a number of different branches. To improve the management of this single assembly I have been using the VSTS Package Manger to create a NuGet package that we can consume within these projects. This post is about my experience of using PM for the first time and some of the things I learned along the way. At the bottom of the post are links to URLs that I used to help me.

You can create a NuGet package on your machine using the NuGet CLI and upload it to the Package Manager manually. This is a good place to start if you want to get something into the PM and see how it looks when you pull down the package in Visual Studio etc. I found using the NuGet CLI to create the .nupkg file helped me to understand what would be required to make it part of a CI build. The NuGet CLI and VSTS NuGet Task allow you to build from either a .csproj (.vbproj) or .nuspec file. To create a .nuspec file for your project use the NuGet CLI with the spec command. The .nuspec file allows you to set the metadata for your project and include replacement tokens that can be substituted from the CLI. After creating my basic .nuspec file I can then run the following NuGet command to create my first package.

nuget pack MyCompany.MyProject.csproj -Build -Properties configuration=debug;description=My first NuGet Package;author=MyCompany -Verbosity Detailed

The -Properties argument defines what replacement tokens are substituted in the .nuspec file. If your project has an AssemblyInfo file but does not contain an entry for AssemblyCompany or AssemblyDescription you must provide these in the command line or the pack command will fail. (See the Replacement Tokens section for more information). The configuration=debug defines which project configuration will be built with the -Build flag. QUICK TIP – if you run the NuGet commands in PowerShell you need to escape the semi-colons using the opening single quote character (`).

The version number of your .nupkg will be taken from the AssemblyInformationalVersion (if available) or the AssemblyVersion entry within the AssemblyInfo file. If you are using a SharedAssemblyInfoFile (SolutionAssemblyInfoFile) to store common values then these need to be defined in the NuGet pack command -Properties as version=x.x.x.x or using the -Version argument.

At this point you can upload the completed package to the Package Manager following the instructions available here. Having created a .nupkg on my own machine the next  stage was to do this as a task of a build process. The current documentation of creating NuGet Packages during the build is a little out of date at the time of writing this article as it refers to the deprecated NuGet Packager task, however there is now a single NuGet task with the different NuGet commands as an option. When I first tried the NuGet build task the problem was making sure that the NuGet task could find the files to include in the .nupkg. To solve this problem I had to make sure the Visual Studio build task, for the .csproj, placed the files in the right location. This was achieved by adding the following MSBuild Argument /p:OutputPath=$(Build.SourcesDirectory)\MyCompany.MyProject\bin\$(BuildConfiguration) .

The .nuspec file included the source control ensures that common settings for the .nupkg are retained for each build. The NuGet Pack task allows for the setting of Pack Options for versioning, however for my build I set this to off and used the used the version specified in by the AssemblyInformationalVersion. I also specified some additional build properties (-Properties attribute) in the Advanced section.

Once the package has been created as part of the build the next stage is to include the NuGet push command task. Again, the current documentation is a little out of date as it refers to the deprecated NuGet Publisher task. To publish the package use the same NuGet task as before but this time selecting the push command. Since we have already created the Package Manager feed we just need to select this as the Target Feed in the push task. Having completed the NuGet push task, the process now has all the tasks to build the project, create a NuGet package and send it to our Package Manager. Finally, we can access the .nupkg from within Visual Studio.

URLs I have found useful on this journey

Visual Studio 2013 and Visual Studio Online

When I first saw Visual Studio online being advertised I didn’t think it would be something I would use that much. However, in the process of creating a Windows Phone application I was reading about the availability of Team Foundation Server as part of the VS Online package. Since I was creating my application in VS 2013 on my machines at home it was great to find out that I could have my very own TFS setup in the cloud; not only that but its also FREE for the first five users. This allows me to have the useful features of TFS and know that my code follows me where ever I happen to be developing.

I still prefer my ‘on machine’ IDE for doing my development and doing it on my Surface 2 Pro has proved to be very effective. The performance of the machine is fantastic and with the all day battery life I can do as full days work on a single charge. The backlit keyboard on the Type 2 cover also helps when you have ideas in the middle of the night!