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.
Related
I'm getting started with a Continuous Integration Nuget feed for my team using a network share. After each build to the dev environment, a package will be created on the network share using the versioning scheme Major.Minor.Patch.BuildNumber. Example: "MyPackage.1.1.3.16338.nupkg".
I was planning to have apps reference these packages on the local feed, and whichever package version is released to Production is published to Artifactory and considered the latest "stable" package/build.
The problem is, I know the versioning scheme doesn't conform to Semantic Versioning and I don't like the ugly build number at the end of the version.
Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?
Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?
I think the best way to do that is using versioning scheme Major.Minor.Patch instead of Major.Minor.Patch.BuildNumber, otherwise, you have to manually change the package version from 1.1.3.16338 to 1.1.3. Because there is no such option or task that we could change the package version after creation.
As an alternative, you could use nuget task NuGet custom to create the nuget package:
NuGet task:
Command: custom
Command and arguments:
pack $(Build.SourcesDirectory)\Package.nuspec -Version $(version) -OutputDirectory $(build.artifactstagingdirectory)
In this case, you can specify the nuget package version in the command line.
See This thread for some more details.
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.
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
I was testing the Asp.NET Core authentication features. The project.json is copied from the GitHub exmaple. here
NU1001 The dependency Microsoft.AspNetCore.Server.Kestrel >= 1.0.0-* could not be resolved.
Other dependencies can be successfully resolved. And I also double checked my dnvm version.
The IntelliSense in Visual Studio also shows there is no Microsoft.AspNetCore... package in dependencies.
So if I want to add
app.UseOAuthAuthentication("Google-AccessToken", options =>...);
in Startup.cs, what is the correct dependency to use?
If you want to use the nightly builds, you need to add the nightly package repositories to do so.
First you will need to use the latest rc2 nightly runtime dnvm upgrade -u latest. Beware, it will fail to restore packages really often!!
You need to add the proper nuget feeds. The official nuget feed (https://www.nuget.org/api/v2) do not contain this packages, as they are nightly builds and pretty unstable. Official nuget feed only has rc1-final packages
From my experience these feeds worked well for rc2 for me
Old (now deprecated) DNX runtime: https://www.myget.org/F/aspnetvnext/api/v3/index.json
New dotnet-cli tooling: https://dotnet.myget.org/F/cli-deps/api/v3/index.json
If you want to try out dotnet-cli you need to install it and follow the instructions in my previous answer on how to run ASP.NET MVC on dotnet-cli found here.
That being said, Microsoft.AspNetCore.Server.Kestrel uses the new naming scheme, which means it's RC2 since Microsoft.AspNet.* packages where renamed to Microsoft.AspNetCore.* some time during RC2 cycle.
If you need a stable base to play around, use rc1-final and it's versions, as they won't be updates at any time and your package restore won't fail multiple times a week due to upgrade to the runtime or packages.
The samples in the dev branch always target the nightly builds, that's some RC2 nightly build at the time of the writing. You either have use the sample in rc1-final branch or switch to rc2 nightly (runtime and packages) and wait for rc2 to be released (hopefully soon).
You can find the rc1-final version of project.json in the rc1-final tag or directly here.
At my work place, we are not allowed to install packages from Nuget, so I am just wondering is there any place to download installer instead, so an internal packaging team can distribute it across the firm.
And is the package production ready?
Unfortunately, Microsoft.Bcl.Async is only distributed via NuGet. You would need to use the package manager to get the assemblies, though you could then just copy the assemblies manually into your system.
And is the package production ready?
Yes, it is now production ready. The BCL Team just announced that this package is now considered Stable. From their post:
Being stable means the owner of that package states that API and functionality are unlikely to change and therefore suitable for use in production.
You could just download the package from another PC (out of work) and then copy the assemblies. Of course you don't get the extra benefits from NuGet, but it's still a viable option.
EDIT Just saw that a few days ago the package was declared stable as Reed correctly indicated.