⬆️ ⬇️

Automatic publication of a new version of the library using TFS 2010 and NuGetter

Given



  1. One small, but very useful library. Includes general functionality - logging, working with Windows Azure, etc.
  2. A large number of projects (solutions), where this library is used.
  3. A distributed development team, part of which the library writes and maintains, and the other part only uses.


Problems you want to solve


  1. The need to copy source / binaries from a project to a project is inconvenient, for a long time, there is a high probability of an error when updating.
  2. The inability to use different versions for different projects - finding and building a specific version “from the past” is inconvenient, again there is a high probability of an error when updating.
  3. The need to keep track of the relevance of library dependencies - especially the Azure SDK, which is now regularly updated, not always all developers have the latest version, and updating the SDK is not always possible.
  4. Using an existing project on different machines is another “thin” place, generating a lot of unnecessary errors. To work correctly, a complete coincidence of paths for projects is needed, which is very difficult to achieve.


Solution and problems encountered


It immediately became clear that getting the package with the latest / specific version of the library when building a solution is the easiest way to do it through NuGet - working with the Azure SDK has a similar approach.



However, after deploying the repository, it turned out that it would not be possible to set up the publication in NuGet just like that - I had to write a separate project that would assemble the package for publication and fill it with the repository.

It also turned out that the version number in the AssemblyInfo file is not very convenient - the numbering by default does not include the publication date, which makes it somewhat difficult to solve problems that appear after updating the library (it is not always easy to catch when this or that part of the functionality stops working) ).



As a result, it was decided to transfer the publishing process to the TFS server by adding Build Definition (build) for the library. All these actions were performed in Team Explorer VS 2010, but I did not notice any particular differences when switching to VS 2012.

')

Search for the best


As an auxiliary project, NuGetter was selected (for automatic publication to the repository during the build on the server) with the addition of TFSVersioning (for editing the AssemblyInfo file during the build on the server), the author had only one project and no integration problems should arise.



Step by step description of personal experience of implementation


I would like to immediately note that everything written below is following the documentation from both projects, plus a description of some of the side effects I encountered.

I didn’t have to set up a build personally before, so all the steps will be described in sufficient detail and boring.



0. Preparing for configuration - upload to server.



Both projects contain libraries with specific Custom Actions for the build workflow on the server and xaml files with workflow templates that extend the default build capabilities. All this is required to upload to the server: project templates to be able to select them when creating a new build, and libraries - to be able to find them the next time this particular build is executed.



It is recommended to lay out workflow templates in the folder for storing default templates $/(Solution Name)/BuildProcessTemplates .

Libraries and the NuGet.exe file with its settings are recommended to be put in a separate folder (on our server it has a very original name .nuget - but always at the top, which is convenient when setting up the build).



In order for these libraries to be found in the build process, you need to configure the build controller (Build Controller) for this solution. This is done like this:

Team Explorer -> (Solution Name) -> Builds -> right click -> Manage Build Controllers ...





Controller selection:





Editing controller for (Solution Name):





In the Version control path to custom assemblies field, you must specify the path to your folder with shared libraries.



Here I had the first small problem - I tried to edit the properties of not the controller, but one of its build agents . Be careful.

Just in case, check the connection to the folder ( Test Connection button).

After checking the connection, save the changes.



1. Adding a new build based on a template.



Now you need to add a new build on the template that was loaded in the previous step. This is done like this:

Team Explorer -> (Solution Name) -> Builds -> right click -> New Build Definition ...





Name and description of the build:





Schedule to run the build:



Options:



Code to be compiled during the build:



Sometimes there are too many projects here - remove unnecessary ones. You can also specify which project to which folder should be copied during the build.



Defining default parameters for a build:



You must select:



Build settings:



The first three items are the settings that are always available for any build. Now only the first block is of interest to us - the choice of projects or solutions for assembly ( Projects to Build ).



You should also pay attention to the Build number format - this parameter is responsible for the folder name with the result of the build (for projects with a large nesting of folders it should not be very long).



Build results save settings:





2. Select a template for the build.



On the Process tab at the top of the drop-down list, select the desired template. If the required list is not visible in the drop-down list, it means that it will be used for the first time, and it must be “shown” to the server using the New... button (select or copy the file already downloaded to the TFS server). Pudding, this is Alice, Alice, this is pudding.



Template selection:





Options:





3. Set up replacements in the AssemblyInfo.cs file.



If you selected a template with TFSVersioning, in the build settings will appear

item number 4:



What and what for:



If you build more than one project, or you create a NuGet package as a result of the build, you can put templates for version numbers into a separate XML file , upload it to the server and enable its use on the seventh line, indicating the path to it in the eighth .

XML looks like this:

 <?xml version="1.0" encoding="utf-8" ?> <VersionSeed> <Solution name="Default"> <AssemblyVersionPattern>1.8.jb</AssemblyVersionPattern> <AssemblyFileVersionPattern>1.8.jb</AssemblyFileVersionPattern> </Solution> <NuGetPackage id="ServiceLib"> <VersionPattern>1.8.jb</VersionPattern> </NuGetPackage> </VersionSeed> 




If you are using a build template for TFSVersioning 1.5, you will also be available

tab with additional features AutoCorrect in the AssemblyInfo file:





4. Setting up a publication in NuGet.



When using the template for NuGetter, three more tabs are available.

NuGetter (A) - Pre-Packaging:



The first tab is responsible for preparing the assembled project for packaging and publication. If necessary, you can add your PowerShell script to the server (for creating folders specified in the NuGet specification, for example).



Be careful: executable PowerShell scripts may not be allowed to be executed on the server. In this case, the build will not give an error , but simply try to run NuGet as if the script worked correctly.

The policy regarding the execution of PowerShell scripts can be checked and corrected through commands

 Get-ExecutionPolicy Set-ExecutionPolicy 


NuGetter (B) - Package:



What and what for:



I didn’t manage to set up the workflow so that the NuGet file caused an update of itself before execution - I just had to upload a new version of NuGet.exe to the server. I think you need to create your own template based on the provided, where to add a Custom Action with another NuGet call. Although, perhaps, I reinvent the wheel, and everything is made much easier.



NuGetter (C) - Push and Publish:



What and what for:

We use the standard NuGet Server , without any additions.



To successfully publish to the NuGet repository, you must have write access to the packages folder for the user running the Application Pool. The memory on the server should also suffice, since the error when there is not enough disk space in the EventLog is very strange and completely uninformative.



5. Run the build.



In addition to automatically starting the build according to the settings in point 1 , the build can be started by hand.

Team Explorer -> (Solution Name) -> Builds -> Build to run -> right click -> Queue New Build ...





The table of running builds with the current status:





6. Total.



The task was solved, and much faster than this article was written. Moreover, after becoming familiar with the technique of creating TFS builds, it turned out that it was not so difficult to set up Continious Integration. It is important to remember that the build builds on the server , so the project settings, files and other changes should not be forgotten to upload to the repository.



If the build fails, TFS automatically creates a bug, with the urgency of Critical, and hangs it on the developer who has downloaded the code to the server last. After the “fix”, the bug is assigned to the Network Service , so this particular user needs to be granted write permission.



I hope the article will save someone time and nerves.

Thanks for attention.

Source: https://habr.com/ru/post/157155/



All Articles