This is an F# Template for:
- creating and publishing libraries targeting
net8.0,net9.0, andnet10.0 - creating and publishing applications with the target framework from the application project
This takes away the ambiguity that developers face when creating an OSS project. Such as:
- How do I structure my project?
- How do I create repeatable builds?
- Which test framework should I use?
- How do I create releases easily?
- What Issue/Pull Request templates should I use?
- How should I go about creating documentation?
- How do I get CI/CD setup easily?
- What's the standard .gitignore file?
- What other things would make it easier for me when starting off creating a project I might not even know about?
- Standard project structure for your dotnet application
- Build Automation tool via FAKE
- Package management tool via Nuget
- Unit Testing via Expecto
- Code Coverage via Altcover
- Also builds an html report with ReportGenerator
- Code formatting style via Fantomas
GitReleasebuild step commits latest CHANGELOG.md in the body and creates a git tag.- If you reference a Pull Request in the
CHANGELOG.mdit will update that Pull Request with the version it was released in.
- If you reference a Pull Request in the
GitHubReleasebuild step publishes a GitHub Release via the CHANGELOG.md and adds any artifacts (nuget/zip/targz/etc).- Continuous integration via GitHub Actions
For Libraries
- Builds for
net8.0,net9.0, andnet10.0- Target Frameworks- To build, install the .NET SDK that
global.jsonspecifies, and the .NET 8.0 runtime for the build project
- To build, install the .NET SDK that
- Sourcelink which enables a great source debugging experience for your users, by adding source control metadata to your built assets
- Documentation Generation - Generates Documentation from markdown files, fsx files, and the XML Documentation Comments from your library.
- Continuous deployment via GitHub Actions
- [Publish to NuGet] - Pushes NuGet packages to NuGet
- Generates Package Version from
CHANGELOG.md - Adds Package Release Notes metadata from
CHANGELOG.md
- Generates Package Version from
- [Documentation Publish] - Publish Documenation to Github Pages
- [Publish to NuGet] - Pushes NuGet packages to NuGet
For Applications
- Basic argument parsing example via Argu
- Builds the target framework from the application project.
- Uses
dotnet publishto create framework-dependent applications forwin-x64,osx-x64,linux-x64,win-arm64,osx-arm64, andlinux-arm64. - Creates six ZIP archives in
dist/with names of the form<product>-<version>-<runtime>.zip. - Places the executable and supporting files at each archive root.
- Requires the corresponding .NET runtime on the destination computer.
Install the dotnet template from NuGet:
dotnet new install "MiniScaffold::*"
Then choose:
dotnet new mini-scaffold -n MyCoolNewLib --githubUsername MyGithubUsername
dotnet new mini-scaffold -n MyCoolNewApp --githubUsername MyGithubUsername -ou console
The scaffold defaults to using the main branch for releases. If you release from a different branch, you can use the --releaseBranch <branch name> parameter to use your release branch instead of the default.
| GitHub Actions |
|---|
 |
| Stable | Prerelease |
|---|---|
The root workflow publishes the MiniScaffold template package through NuGet trusted publishing. Before a release, create a policy with the correct NuGet package owner and package scopes. Use these GitHub policy fields:
| Field | Value |
|---|---|
| GitHub owner | TheAngryByrd |
| Repository | MiniScaffold |
| Workflow filename | publish.yml |
| Environment | nuget |
Add an environment variable named NUGET_USER to the existing nuget environment.
Use the policy creator's actual NuGet profile name, not an email address or an assumed GitHub username.
The NuGet package owner can be an organization with a different name.
NuGet/login@v1 supplies a short-lived API key through the existing NUGET_TOKEN build input.
The workflow has no stored-key fallback.
After an authorized tag-triggered release, verify the NuGet package version and the GitHub release artifacts.
Check the complete run logs for credentials and credential fragments.
Check that NuGet reports the policy as active and permanent.
Only after all verification succeeds, remove the stored GitHub NUGET_TOKEN secret and revoke the old scoped NuGet key.
Keep both credentials until these checks pass.
See the release guide for failure checks and manual emergency recovery.
This is used to automatically configure author information in the NuGet package, as well as configure push urls for repo locations.
Defaults to Library
When set to either Console or Library project and the supporting infrastructure around their respective types.
-bash: ./build.sh: Permission denied
This is because dotnet template loses permissions of files. (#37) added a post hook to address this but this only fixes it for dotnet sdk 2.x users. dotnet sdk 1.x will need to run chmod +x ./build.sh
Appveyor's conventions around generating URLs based on the project name has some nuances. See this issue for details.