I have a NET Standard class library (VS2017) and I created a CI/CD build in VSTS - it gets built, packed into nugget package and pushed to our own nugget feed. Now, I need to have an automated versioning of this library. How can I do this?
ok, how I made it to work:
I added dotnet pack build task v.2.* (preview)
set Automatic package versioning to Use the build number for the task
In Options tab I set Build number format to $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
And now when the project is built it publishes package with version in this format:
Version 2017.9.24.1
So I can now install it this with the command:
nuget install MyCommonLibrary -version 2017.9.24.1
Can't see any drawbacks for now.
Related
I have created simple .NET5 console application which can be successfully run using "dotnet restore" and "dotnet run". Application is using one package Newtonsoft.Json.
I want to restore NuGet packages using NuGetRestore() but in result I get "Could not locate nuget.exe".
I am using Cake .NET Tool in version 1.1.0 and default configuration.
As far as I remember, previously when I was using Cake before version 1.0.0 nuget.exe was downloaded to 'tools' folder.
What am I missing? How to make sure nuget.exe is downloaded/provided by Cake?
In order for the NuGet tool to be downloaded to the tools folder, you need to include the NuGet.CommandLine package in your Cake build script. e.g.
#tool nuget:?package=NuGet.CommandLine&version=5.9.1
Related info:
Example build.cake file referencing NuGet.CommandLine
NuGet.exe related documentation
Cake itself never did download nuget.exe. The example bootstrapper for Cake Runner for .NET Framework does this in certain conditions. Example bootstrapper for Cake .NET Tool does not download nuget.exe and you need to make yourself sure to have it available, either by updating the bootstrapper, using the tool prepocessor directive in your build script, or any other mechanism outside of Cake.
What is the difference between the version one?
.NET Core BUild task (dotnet build) only build the specified project and it's dependencies. It not provide converting .ts to .js and js.map (you can refer TypeScript).
More detail about dotnet build, you can refer dotnet-build.
I'm trying to add a Nuget .core package using
dotnet add package [package name]
but get "No executable found matching command dotnet-add". I've installed Nuget and can use "dotnet" to create applications, restore, build, run, etc.
What am I doing wrong? Thanks.
The dotnet add family of verbs was released in version 1.0.0 of the dotnet cli tooling and is not part of the 1.0.0-preview2-* range of versions previously used for project.json projects.
This means that dotnet add verbs are only available for msbuild based projects (=> .csproj).
I've 4 project structure below:
Core
Infrastructure
Ship
Ship.aspnet
Where when I create a nuget package from ship project, it should contain all the dependent project dlls i.e. 1, 2 and 4.
At the moment when I create a VSTS Nuget Packager Task pointing to ship project, it generates the *.ship nuget package. However, when I consume this package the compiler complains that core, infrastructure and ship.aspnet dlls are missing.
Thanks.
Just include -IncludeReferencedProjects argument.
I don't understood the overall scheme on how NuGet is used on windows platform (because I never saw this, I work with Linux and monodevelop).
In many windows projects, there is a .nuget folder in repository, like
https://github.com/YAFNET/YAFNET/tree/master/yafsrc/.nuget
In this folder there is a nuget.exe executable.
Why it is necessary to add executables to source code control(SCC)?
How NuGet build tool differs from all other binary tools like compilers, which are not included into SCC?
Why other package managers like paludis are not added to SCC, but nuget does?
What are exactly the reasons to put NuGet to SCC?
It is not necessary to add NuGet.exe to source control.
The reason some projects have .nuget/NuGet.exe, with a set of other MSBuild files, is to use the MSBuild based package restore. The MSBuild based package restore will run NuGet.exe at build time to download any missing packages.
The MSBuild based package restore has been deprecated by the NuGet team.
Visual Studio with recent versions of the NuGet Package Manager will automatically restore NuGet packages before building the project. If you need to restore NuGet packages on a build server you can use NuGet.exe to restore the NuGet packages by running a command line similar to:
NuGet.exe restore YourSolution.sln