I am working on setting up repository at work. I would like to be able to force the TFS builds to use the latest version of each of our in house packages in a given solution without having to modify each project manually, instead of just using the default package restore behavior. I have seen some things online about using nuget.target to perform this but could not find supporting documents from nuget's website. I am open to just about any approach as long as the ending result is that my build server will ultimately us latest version of our packages automatically. We are using version 3.4.4 of nuget.
The fix was to as Adriano Repetti said which was to add a step to perform nuget update after nuget restore was on the build server using the cmd line directives.
Related
We have dozens of solutions in a repository and we're retargeting every project to net472 from net462. Currently our best bet is to open each and every solution in Visual Studio and execute the following command in the Package Manager Console.
Update-Package -Reinstall -IgnoreDependencies
As far as I'm aware, the PM console cannot be used outside Visual Studio, so this method of course is not very efficient, so what I was thinking about is using the nuget.exe tool for this. However at first glance I could not find any equivalent operation or argument set.
The documentation at this moment says the following
For all packages, delete the package folder, then run nuget install.
For a single package, delete the package folder and use nuget install
to reinstall the same one.
So based on this I tried to delete the packages folder and run nuget install for a project, so I expected it to do a re-install. However, while it installed the package indeed (to packages), it does not touch the packages.config (for retargeting).
Is anyone aware of any kind of possible way to automate this process?
How to achieve full NuGet reinstall using nuget.exe CLI?
That command cannot get what you want.
As far as I know, nuget install should be with packages.config file and it will not update the nuget framework version of packages.config file automatically.
So whenever you change the target framework version of your project, using that command will not update the target framework version of the nuget package.
So only update-package -reinstall command under Package Manager Console will update the target framework version of packages.config file.
And also Package Manager Console cannot access multiple solutions so you have to open each solution to run that command.
Although it may be possible to achieve your expectations with PowerShell scripts, but it is too complex so that it is easier to open each solution and then run the command.
As a suggestion,
1) open each solution on VS to run update-package -reinstall command.
2) And migrating from packages.config to PackageReference may be a good choice. In this case, the nuget packages will automatically adapt to the corresponding project target framework version.
Before doing this,you can make a backup of your project.
3) If these all do not meet your requirements, you could suggest a feature on our User Voice Forum to report your desire for automation. After that, you can share the link here and anyone who is interested in it will vote it so that it will get more attention from Microsoft.
I am using Git and would like it when I merge to my master branch it would automatically stop the process in TeamCity if my nuget-package had references to other dev/beta packages. This way I can be sure that my releases always references other release packages and no pre-releases.
Is there a way to solve this using MSBuild, Nuget or TeamCity?
EDIT:
As I understand it, this does not work out of the box using MSBuild or Nuget. Is it a good way to make a pre-build step for TeamCity that checks if the projects have pre-release references?
In the release branch of the solution that references these packages you have to restrict references to be non-pre-release only and run update references.
You can rebase the dev branch to this later on when you merge release to dev and master, then dev could deviate by using pre-release packages again.
There is nothing special required from your CI server or Nuget to support this.
But there is no real way to stop the build, unless you create a special tool that will check versions in package.config files. You can separate feeds for release and pre-release packages and limit the restore to release only feed during the build but nuget will scan all configurations and eventually will find both feeds. The only solution that I know is to use paket instead of Nuget. Paket allows you to specify feed configuration per solution. It also gives you clear indicator on which versions you have referenced and any pre-release restrictions. It also prevents you from having multiple version of the same package for different projects in one solution.
When using paket, you could check the paket.lock file for any occurrences of -unstable in it (assuming you follow SemVer for your packages). like this:
$ findstr "-unstable" paket.lock
We are using git as source control and we follow the git flow workflow.
We are using Visual Studio 2013
We are using Teamcity v8.1
We have 2 C# solutions. Solution A and solution B. Solution B uses a nuget package that solution A creates.
We are using teamcity as a build server. We have 2 build configurations that creates the Project A nuget package. One build configuration creates a prerelease version of the nuget package, the other one creates the stable version of the nuget package.
The build configuration for creating the prerelease nuget listens on the develop branch. The build configuration for the stable version listens on the master/release/hotfix branches
When we work in the develop branch we use the prerelease version of the nuget package.
But when we create a release branch we want to use the stable version of the nuget package.
What we have tried so far is:
In project B csproj file, we have added an element in the BeforeBuild target that executes nuget.exe to update the prerelease version of the nuget package. That works well, since every time we build project B we will get the latest prerelease version of the nuget package.
But when we are in the release/master/hotfix branch we don't want the prerelease version, we want the stable one.
I've created a powershell script that is executed from project B csproj file in the BeforeBuild target
In the powershell script I can find which git branch we are in, but I haven't found a way to update the nuget package to the latest stable version using nuget.exe. If I could use the nuget cmdlets in the powershell script I could run the update-package with the version flag, but that is not supportered when using nuget.exe
Do you do something similar and how have you solved this?
I while back I also tried to automate updating and installing packages with Powershell. As far as I know there is no way to use the Visual Studio cmdlets outside Visual Studio.
You could do everything yourself. Update packages.config, run nuget update, update csproj file.
It is possible your package has an install.ps1 file. This also uses the Visual Studio cmdlets. For example, the install.ps1 can add a config file to the Visual Studio project and set Copy to Output Directory to Copy if newer.
This means you would have to add these changes to the csproj as well.
Should we put our nightly builds on NuGet daily? Customer asked for this but they are a big number of packages per year. Is NuGet designed for this purpose? How can we mark stable releases instead?
Thanks.
First of all, think from the users point of view.
Even if a customer installs your nightly, he will be able to go back to a more stable nightly if something breaks. For this an absolute requirement is a unique version scheme for every build that you publish.
Let's say your customer has version 1.0.1-nightly.1234 installed which works for hin. Now he does an update to 1.0.1-nightly.1235 which is broken and he can not continue. He should be a able do do
uninstall-package YourPackage
install-package YourPackage -version 1.0.1-nightly.1234 -pre
I understand that you don't want to mess up nuget.org with your nightly builds so you could either use another feed or setup your own sever (maybe your build server already can do this, I use teamcity which can do nuget deploys and has a build in nuget server, even if I never used it so far but am planning to do so).
Maybe you can do a monthly pre-release on nuget.org or manually publish nightly builds that you consider fairly stable.
I would suggest you change your version scheme to include a date in your builds 1.0.1-nightly.20140520 for your own feed and 1.0.1-nightly for the official build.
nuget itself supports versioning schemes like <major>.<minor>.<patch>-<buildname>.<revision> but nuget.org only allows <major>.<minor>.<patch>-<buildname>
http://docs.nuget.org/docs/reference/versioning
There is nothing stopping you from putting your nightly builds on NuGet. Some teams, such as the ScriptCS team and the ASP.NET team use MyGet for nightly builds instead of using the main NuGet feed.
You will probably want to distinguish these builds from stable releases, at least on the main NuGet feed. You would need to mark these builds as pre-release NuGet packages using a version number such as 1.0.1-alpha1 and use 1.0.1 for the stable release. However if you use MyGet you would not need to mark these builds as pre-release if you did not want to.
When I try and build my project in Teamcity (or in a clean repository on my machine), it fails with the error message
The schema version of 'Microsoft.Bcl' is incompatible with version 1.7.30402.9028 of NuGet. Please upgrade NuGet to the latest version from <nuget url>...
I've set my NuGet.Targets to restore packages, and not require user interactions to accept licenses. In addition both my local machine and the build server have the restore packages setting enabled (in the project/env variable as appropriate).
I'm aware of this issue http://blogs.msdn.com/b/dotnet/archive/2013/06/12/nuget-package-restore-issues.aspx. I've tried the second and third options suggested here, but without success.
Does anyone have any suggestions how to resolve this error?
Turns out the version of NuGet that is held in the .nuget folder of my solution was out of date. The version that Visual Studio uses had updated correctly, but the command line version didn't.
I followed the instructions described here Nuget versioning issue with package restore to resolve the problem.
In the solution directory run these commands:
cd .nuget
nuget.exe update -Self
Try updating the nuget that teamcity is using
If you are using version 8.x.x
Administration -> Nuget Settings -> Nuget Commandline -> (click fetch nuget) -> then choose the latest version and install it. Make sure "Set as Default" is checked.