This repository contains multiple dotnet samples using Fake CLI as a build system
fake-cli
is not used as a global
install on purpose. It uses a cmd
to install it in a .fake
folder so that the build would fetch everything it depends on
The idea is that a build system should not required pre-installed artifacts to run
A wildcard resolution is used/needed for --version
until Fake 5 release, once release the version could be deleted
SET BUILD_PACKAGES=.fake
SET FAKE_CLI="%BUILD_PACKAGES%/fake.exe"
IF NOT EXIST %FAKE_CLI% (
dotnet tool install fake-cli --tool-path ./%BUILD_PACKAGES%
)
This folder contains a really simple scenario :
> dotnet new console
> dotnet new xunit
> dotnet new sln
tasks.json
allow you to runFakeBuild
launch.json
allow you to debug thefsx
scriptclean
andbuild
Target are using thesln
based dotnet behaviortest
look for every single*.Tests.csproj
in thetest
folder and rundotnet xunit
in every single of their parent folder. This step runs them all in parallel, to understand why just add fewxunit
project to the test folder and replacewith!!("test/**/*.Tests.csproj") |> Seq.toArray |> Array.Parallel.map ... |> Array.Parallel.map (fun ...
!!("test/**/*.Tests.csproj") |> Seq.map ... |> Seq.map (fun ...
The following are just guidelines
Intended to show the use of a solution containing multiple nugets to produce :
dotnet pack
sourcelink
dotnet nuget push
(Not sure were to push for now and where to get credential)
dotnet build
dotnet test
dotnet publish
- Deploy to (local ?) iis
Using Fake with Npm stuff (to prepare a more complex scenario)
- Npm install
- Npm build
- Npm test
- maybe some vscode/webpack integration for debug
- Web Api (hosted in IIS / Azure)
- Front App
- Console to run a backend (the idea is to get multiple package out of it)
- Test
- Sonar
- Deploy front to a CDN ?
- Deploy back to Azure ?