Demonstrates a basic build of a .NET NuGet package using https://cakebuild.net/
MIT License
Package | Release | Pre-release |
---|---|---|
Contoso.Hello.Logic |
||
Contoso.Hello.SuperLogic |
CI | Status | Platform(s) | Framework(s) | Test Framework(s) |
---|---|---|---|---|
AppVeyor | Windows |
netstandard2.0 , net462
|
net8.0 , net462
|
|
Azure DevOps | Linux |
netstandard2.0 |
net8.0 |
|
CircleCI |
Docker : mcr.microsoft.com/dotnet/sdk:8.0
|
netstandard2.0 |
net8.0 |
|
GitHub | Windows |
netstandard2.0 , net462
|
net8.0 , net462
|
Demonstrates a basic build of a .NET
NuGet
package using Cake.
I tried to create a somewhat realistic scenario without writing too much code:
NuGet
packages.
SuperLogic
project depends from Logic
and when packing this project reference will be turned into a NuGet
package reference (handled out of the box by dotnet pack
).Logic
project references a NuGet
package from nuget.org via a PackageReference
, dotnet pack
will turn this into a package reference.netstandard2.0
and net462
so they can be used with the .NET Framework
(net462
and above).SemVer
to version the DLLs
and the NuGet
packages.
SemVer
is implemented via GitVersion
.I wrote a blog post about this experiment.
Pinning the version of Cake
guarantees you'll be using the same version of Cake
on your machine and on the build server.
This is done by using Cake
as a .NET
local tool. The version is specified in .config\dotnet-tools.json
.
.\bootstrap.ps1
./bootstrap.sh
dotnet cake build.cake
*.csproj
and *.nuspec
)NuGet
packages) are resolved automatically. There is no need to tweak a file manually any more!The SuperLogic
project depends on the ExtraLogic
project but we don't want to ship ExtraLogic
as a package. Instead we want to include Contoso.Hello.ExtraLogic.dll
in the SuperLogic
package directly. Currently this is not supported out of the box but the team is tracking it.
Luckily this issue provides a workaround. All the modifications will take place in SuperLogic.csproj
.
<PropertyGroup>
section add the following line:<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);IncludeReferencedProjectInPackage</TargetsForTfmSpecificBuildOutput>
<ProjectReference Include="..\ExtraLogic\ExtraLogic.csproj">
<PrivateAssets>all</PrivateAssets>
</ProjectReference>
DLL
:<Target Name="IncludeReferencedProjectInPackage">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)Contoso.Hello.ExtraLogic.dll" />
</ItemGroup>
</Target>
Each time a commit is pushed to main
or features/*
; AppVeyor
, Azure DevOps
, CircleCI
and GitHub
will build the changes.
In case of a successful build GitHub
will:
main
features/*
When running on a platform that is not Windows, we can't target the .NET
full Framework, hence the build script is calling IsRunningOnLinuxOrDarwin
to detect the available capabilities.
Build status is visible here.
Linux
, macOS
and Windows
hosted agentsGitHub
release and tag
the repository
if requiredAppVeyor
's build number programatically
Cake
integrates with AppVeyor
: publish test results, upload artifacts, update build number...Azure DevOps does not offer a free an unlimited plan for open-source projects any more.
Build status is visible here.
Docker
, Linux
, macOS
and Windows
hosted agentsBuild status is visible here.
Docker
, Linux
, macOS
and Windows
hosted agentsCircleCI
has a few limitations:
JUnit
format, you can use the package JunitXml.TestLogger for a JUnit
loggerBuild status is visible here.
Docker
, Linux
, macOS
and Windows
hosted agentsGitHub
has a few limitations:
I decided to remove Travis CI. Travis CI poorly handled a security vulnerability and security is of paramount importance when it comes to build systems.
The main
branch is protected
:
main
main
cannot be deletedfeatures/*
) cannot be merged into main
until they satisfy:
AppVeyor
passing buildAzure DevOps
passing buildCircleCI
passing buildGitHub
passing buildAfter a branch was configured as protected
, GitHub
will suggest available status checks.