dotnet add package ToMEHelper --version 0.1.3
NuGet\Install-Package ToMEHelper -Version 0.1.3
<PackageReference Include="ToMEHelper" Version="0.1.3" />
paket add ToMEHelper --version 0.1.3
#r "nuget: ToMEHelper, 0.1.3"
// Install ToMEHelper as a Cake Addin #addin nuget:?package=ToMEHelper&version=0.1.3 // Install ToMEHelper as a Cake Tool #tool nuget:?package=ToMEHelper&version=0.1.3
[Enter useful description for ToMEHelper]
Make sure the following requirements are installed on your system:
- dotnet SDK 3.0 or higher
- Mono if you're on Linux or macOS.
CONFIGURATIONwill set the configuration of the dotnet commands. If not set, it will default to Release.
CONFIGURATION=Debug ./build.shwill result in
-cadditions to commands such as in
dotnet build -c Debug
GITHUB_TOKENwill be used to upload release notes and Nuget packages to GitHub.
- Be sure to set this before releasing
DISABLE_COVERAGEWill disable running code coverage metrics. AltCover can have severe performance degradation so it's worth disabling when looking to do a quicker feedback loop.
> build.cmd <optional buildtarget> // on windows $ ./build.sh <optional buildtarget>// on unix
The bin of your library should look similar to:
$ tree src/MyCoolNewLib/bin/ src/MyCoolNewLib/bin/ └── Debug └── net50 ├── MyCoolNewLib.deps.json ├── MyCoolNewLib.dll ├── MyCoolNewLib.pdb └── MyCoolNewLib.xml
Clean- Cleans artifact and temp directories.
DotnetRestore- Runs dotnet restore on the solution file.
DotnetBuild- Runs dotnet build on the solution file.
DotnetTest- Runs dotnet test on the solution file.
GenerateCoverageReport- Code coverage is run during
DotnetTestand this generates a report via ReportGenerator.
WatchTests- Runs dotnet watch with the test projects. Useful for rapid feedback loops.
GenerateAssemblyInfo- Generates AssemblyInfo for libraries.
DotnetPack- Runs dotnet pack. This includes running Source Link.
SourceLinkTest- Runs a Source Link test tool to verify Source Links were properly generated.
PublishToNuGet- Publishes the NuGet packages generated in
DotnetPackto NuGet via paket push.
GitRelease- Creates a commit message with the Release Notes and a git tag via the version in the
GitHubRelease- Publishes a GitHub Release with the Release Notes and any NuGet packages.
FormatCode- Runs Fantomas on the solution file.
BuildDocs- Generates Documentation from
docsSrcand the XML Documentation Comments from your libraries in
WatchDocs- Generates documentation and starts a webserver locally. It will rebuild and hot reload if it detects any changes made to
docsSrcfiles, libraries in
src, or the
ReleaseDocs- Will stage, commit, and push docs generated in the
Release- Task that runs all release type tasks such as
GitHubRelease. Make sure to read Releasing to setup your environment correctly for releases.
git add . git commit -m "Scaffold" git remote add origin https://github.com/user/MyCoolNewLib.git git push -u origin master
Add your NuGet API key to paket
paket config add-token "https://www.nuget.org" 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a
or set the environment variable
NUGET_TOKENto your key
- You can then set the environment variable
GITHUB_TOKENto upload release notes and artifacts to github
- Otherwise it will fallback to username/password
- You can then set the environment variable
Then update the
CHANGELOG.mdwith an "Unreleased" section containing release notes for this version, in KeepAChangelog format.
NOTE: Its highly recommend to add a link to the Pull Request next to the release note that it affects. The reason for this is when the
RELEASE target is run, it will add these new notes into the body of git commit. GitHub will notice the links and will update the Pull Request with what commit referenced it saying "added a commit that referenced this pull request". Since the build script automates the commit message, it will say "Bump Version to x.y.z". The benefit of this is when users goto a Pull Request, it will be clear when and which version those code changes released. Also when reading the
CHANGELOG, if someone is curious about how or why those changes were made, they can easily discover the work and discussions.
Here's an example of adding an "Unreleased" section to a
CHANGELOG.md with a
0.1.0 section already released.
## [Unreleased] ### Added - Does cool stuff! ### Fixed - Fixes that silly oversight ## [0.1.0] - 2017-03-17 First release ### Added - This release already has lots of features [Unreleased]: https://github.com/user/MyCoolNewLib.git/compare/v0.1.0...HEAD [0.1.0]: https://github.com/user/MyCoolNewLib.git/releases/tag/v0.1.0
- You can then use the
Releasetarget, specifying the version number either in the
RELEASE_VERSIONenvironment variable, or else as a parameter after the target name. This will:
CHANGELOG.md, moving changes from the
Unreleasedsection into a new
- if there were any prerelease versions of 0.2.0 in the changelog, it will also collect their changes into the final 0.2.0 entry
- make a commit bumping the version:
Bump version to 0.2.0and adds the new changelog section to the commit's body
- publish the package to NuGet
- push a git tag
- create a GitHub release for that git tag
./build.sh Release 0.2.0
macOS/Linux Environment Variable:
RELEASE_VERSION=0.2.0 ./build.sh Release
|.NET||net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows net7.0 net7.0-android net7.0-ios net7.0-maccatalyst net7.0-macos net7.0-tvos net7.0-windows|
- FSharp.Core (>= 5.0.0)
- HtmlAgilityPack (>= 1.11.39)
This package is not used by any NuGet packages.
This package is not used by any popular GitHub repositories.
## [0.1.3] - 2022-01-20
- dogfooding and race/class extrapolation from the character vault