I'm looking on creating NuGet packages as part of my CI builds. My intent is to be able to deploy the final application for testing, and once passed, allow that build to be promoted to a release version by removing the -prerelease designation. How can I take an existing NuGet prerelease package and convert it to a non prerelease?
I wonder if the package contain the hash file that is causing an issue. I think your only choice is to generate a new package.
Just open the nupkg file in Package Explorer and edit the version number.
I have done that many times to covert a -rc to production.
Works fine
Related
We have a project with a dependency on a custom NuGet feed (also hosted in VSTS).
I'm trying to put together a new phase to generate code coverage reports, as in this blog post. My new phase looks like this:
And is made up of the following steps:
.NET Core Tool Installer - use SDK 2.0.0
dotnet restore with my custom feed selected in the "Use packages from this VSTS/TFS feed" drop-down
dotnet test with the relevant arguments to collect code coverage
A custom step using ReportGenerator
A step to publish the results
The problem is that dotnet test insists on trying to restore the packages itself. As I can't find a way to tell it to use a custom feed, it fails when trying to restore these packages:
D:\a\1\s\MyProject\MyProject.csproj : error NU1101: Unable to find package My.Package. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org
My main build process works fine and is able to restore the package from the custom feed. The difference is that uses the Visual Studio (i.e. not dotnet) versions of the commands:
What's the right way to handle this?
Do I need to find some way to tell dotnet test about my custom feed?
Or (given that I'm running restore immediately prior) do I need to persuade it to skip the restore altogether?
In case anyone else has this problem, I'm sorry to say our route to resolution was to merge the two repos, effectively negating the need to use the private Nuget feed.
We did have a bit of back and forth with a rep from MS, but didn't get to the bottom of it.
I had similar problem with dotnet test and custom nuget feed.
The solution was using two steps:
dotnet restore --source (my feed sources)
dotnet test --no-restore
See Implicit restore
What's the right way to handle this?
In step dotnet restore, make sure field Path to project(s) specifies all relevant projects. (It's easy to forget a project and that would result in the behavior you experience.) For instance, you can specify the value **/*.csproj. If you do this correctly, other steps such as dotnet test should not even try to restore packages since they have already been restored.
Do I need to find some way to tell dotnet test about my custom feed?
No (assuming step dotnet restore has already restored the packages)
Or (given that I'm running restore immediately prior) do I need to persuade it to skip the restore altogether?
No. It will automatically skip restoring (assuming step dotnet restore has already restored the packages)
I had the same error on a self hosted build agent. Once I changed the star syntax (get latest version) in the project file to a fixed version the problem went away. I am bit sad that I cant use the version syntax.
We have a large solution with many projects, and many developers working together.
We need a way to validate Nuget package versions to insure no developer accidentally breaks the build with a package update.
Ideally, is there a way to validate and interupt/stop during Nuget package installation if it is a known incompatible package? We know we can do a validation at build time, but Ideally I'd like to actually be able to stop/inform the developer the newer version is not supported in the build to prevent them from going off and building with the newer package, only at build time to discover they've wasted time on a new package that might have differing calls etc.
If this is not possible, what would be the easiest way to do this at build time? I'm thinking a pre-build script but interested in other ideas. Effectively, the script would look across other project package versions to compare and inform if an incorrect version (and stop a publish to a shared location during build).
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
First, I will describe our setup (it is an extremely simplified version of the corporate development pipeline). We develop a .NET application, which is dependent on some shared components. The shared components typically develop together with the application. We want turn these shared component to NuGet packages.
So, I publish version 1.0.0.4 of package A and want to consume it in my application. My packages.config looks like this.
<package id="A" version="1.0.0.4"/>
So far so good. I probably commit packages.config to version control at this point to remember my dependencies. Now I run the next build of package A, which publishes the version 1.0.0.5. Now I want my application to automatically update package A to 1.0.0.5 before the build.
However, my packages config now contains an exact verion 1.0.0.4 and it's version-controlled. My questions are:
Can I somehow specify that I want version 1.0 or higher in packages config? In other words, can I avoid change of packages.config with every new build of every package?
Can I somehow update the dependencies before build to the the newest version? Can I do it automatically using a script?
I am quite new to NuGet and I come from the ant+ivy/maven world, where this feature is kinid of automatic, so I am still hoping I am missing something obvious in NuGet, although scanning through the discussions on stackoverflow doesn't sound too encouraging.
I've found Using Nuget in development environment - best practices / how to and How to automatically update NuGet packages to latest available version and NuGet issues with packages.config, project references and the solutionwide packages folder, which do not give clear answers.
You can use the allowedVersions attribute to automatically use newer package versions within a range, like this:
<packages>
<package id="SomePackage" version="2.1.0" allowedVersions="[2,3)" />
</packages>
In this example, any package from the 2.x series will be used, but not from the 3.x series. You can be more specific with the contraint e.g. `allowedVersions="[2.1,2.4)" if you wanted to take any package from 2.1, 2.2, and 2.3 but not 2.4.
See http://docs.nuget.org/docs/reference/versioning for more details
I don't think you can change the packages.config to implicitly allow a higher version. Also, the project files have references to the packages folder which include the package version in the path, so those need to be changed after a package update.
You can perform an update of the packages.config and the projects files by running nuget update.
You could automate this in the nightly builds and checking in the resulting changes as well. However, it's debatable whether that's a good idea. At the minimum, you should gate the update operations by running a build to make sure the new version doesn't cause a build break.
Our development team has been fairly small and, until now, all working on a single Visual Studio 2012 solution. We are growing and wanting to create better separation with multiple solutions for different project teams.
However, there are occasions where the code in one solution will want to utilize code from another. We have decided using internal (i.e. private) NuGet packages will be a good way to manage these dependencies.
However, the question has come up on how to deal with multiple versions of the same package that are in different SDLC stages (e.g. Development, QA, Staging, Production, etc.)
Example: If we have these three solutions...
CoreStuff
CoolProject1
CoolProject2
If working in CoolProject1, and we need to utilize code from CoreStuff, we can add the NuGet package. Presumably this package will be the latest Production (stable) version of CoreStuff.
However, what if a developer working on CoolProject2 is aware of some changes in CoreStuff that are currently in Development and wants to utilize that version?
Not sure if the best approach is to create separate packages for each (seems to require changing your package references back and forth depending on what stage the solution is in) or somehow utilize multiple versions of the same package (not sure if that's easy to manage with NuGet).
Anyone tackle something like this?
The first thing to remember is that NuGet will not automatically update your package references, so if you have already 'linked' your solution to the latest stable package of CoreStuff (say 1.2.2) then there won't be any problems if a newer (unstable) version is provided (assuming that the package you're using doesn't disappear from the package repository). Obviously if you upgrade your package reference then you will get the unstable package.
So the simplest solution is to make sure that you 'link' your project to the stable package by getting it via the NuGet package manager before the other package is released. While the UI only allows you to get the latest version, the Package Manager Console can get any version of a package so you could use that to explicitly provide the version number, e.g.:
Install-Package CoreStuff -Version 1.2.2 -Project CoolProject1
If that is not a solution then there are several other options to tackle this problem:
Give the development version a different semantic version that indicates it is a unstable version, e.g. 1.2.3-alpha. In this case CoolProject1 could pull in package CoreStuff.1.2.2 (which should be latest stable version in your repository) and CoolProject2 could pull in CoreStuff.1.2.3-alpha (which would be the latest unstable version).
Have multiple repositories, e.g. one for stable (released) packages and one for unstable (development) versions. Then you can select your packages from the desired repositories. If you wanted to you could make it so that only your release process can push packages up to the stable repository and your CI build pushes up to the unstable one (so that you always have the latest packages available)
If the developer of CoolProject2 just wants to develop against the latest version (but will wait to release CoolProject2 until after CoreStuff v.next has been released) then he could potentially create a local package repository (i.e. a directory on his drive) and put the new package of core stuff there. That way other developers won't even see the package.
The most important thing will be to make sure that you don't get CoreStuff.1.2.2 and CoreStuff.v-next in the same repository if CoreStuff.v-next simply has a higher version number, because in that case the NuGet UI won't let you pick v1.2.2 (but the Package Manager Console does!).
If you would want to switch from one package type to another you'd have to do a manual update (which you always have to do when changing to the next package version anyway), but that's not a bad thing given that this forces a developer to at least check that the update of the package doesn't break anything.