theangrybyrd / miniscaffold

F# Template for creating and publishing libraries targeting .NET 6.0 `net6.0` or console apps .NET 6.0 `net6.0`.

MiniScaffold

What is MiniScaffold?

This is an F# Template for:

• creating and publishing libraries targeting .NET 6.0 net6.0
• creating and publishing applications targeting .NET 6.0 net6.0

Why use MiniScaffold

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?

What does this include in the box?

All project types

• Standard project structure for your dotnet application
• Build Automation tool via FAKE
• Package management tool via Paket
• Unit Testing via Expecto
• Code Coverage via Altcover
  • Also builds an html report with ReportGenerator
• Code formatting style via Fantomas
• GitRelease build step commits latest CHANGELOG.md in the body and creates a git tag.
  • If you reference a Pull Request in the CHANGELOG.md it will update that Pull Request with the version it was released in.
• GitHubRelease build 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 net6.0 - Target Frameworks
  • To build for net6.0 .NET 6.0 installed
• 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
  • [Documentation Publish] - Publish Documenation to Github Pages

For Applications

• Basic argument parsing example via Argu
• Builds a net6.0 application - Target Frameworks
  • To build for net6.0
    • Have .NET 6.0 installed
• Builds for win-x64, osx-x64 and linux-x64 - Runtime Identifiers. Bundles the application via dotnet-packaging
  • Bundles the win-x64 application in a .zip file.
  • Bundles the osx-x64 application in a .tar.gz file.
  • Bundles the linux-x64 application in a .tar.gz file.

---

Getting started quickly

Install the dotnet template from NuGet:

dotnet new install "MiniScaffold::*"

Then choose:

• I want to build a Library

dotnet new mini-scaffold -n MyCoolNewLib --githubUsername MyGithubUsername

• I want to build an Application

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.

---

Builds

GitHub Actions

NuGet

Stable	Prerelease

---

Options

githubUserName

This is used to automatically configure author information in the NuGet package, as well as configure push urls for repo locations.

outputType

Defaults to Library

When set to either Console or Library project and the supporting infrastructure around their respective types.

---

Known issues

Permission denied

-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 badge not scaffolded correctly

Appveyor's conventions around generating URLs based on the project name has some nuances. See this issue for details.

---

Example Projects using this template:

• Chessie.Hopac
• Marten.FSharp
• FSharp.Control.WebSockets
• FSharp.Control.Redis.Streams
• FsLibLog
• Giraffe.HotReload
• EFCore.FSharp

This project uses the following projects:

• Heavily inspired by Project Scaffold
• Paket
• FAKE
• Expecto
• Buildstats.info
• Source Link
• AltCover
• ReportGenerator
• Fantomas
• Argu
• dotnet-packaging
• FSharp.Formatting

miniscaffold's Issues

Expecto

Move from Xunit to Expecto https://www.nuget.org/packages/Expecto/5.0.0-beta1

Coveralls

Description

We should integrate into coveralls instead of committing the code coverage reports

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Update FAKE to work on mono 5.0

https://github.com/fsharp/FAKE/blob/master/RELEASE_NOTES.md#4600---27042017

Pull request template mention Appium instead of ProjectName

Description

The scaffolded pull request template mention: Appium. This should perhaps be replaced by something else.

Expected Behavior

As a user of MiniScaffold I would assume that it would use the entered project name when I do

dotnet new mini-scaffold -n MyCoolNewLib --githubUsername MyGithubUsername

i.e. MyCoolNewLib

Known workarounds

A known workaround is simply to change it after scaffolding.

Upload release notes and nuget package to github

Allow uploading your RELEASE_NOTES.md and nuget package to the release tag of github

Request: different Expecto log names for each target framework (needs a new feature in Expecto)

Description

Once haf/expecto#224 gets merged (solving haf/expecto#223), I'd suggest that the mini-scaffold's build.fsx should put the target framework name into Expecto's new --log-name parameter, so that instead of each test run logging as "Expecto", they can log as "Expecto.net461", "Expecto.netcoreapp2.0", etc. That way if a test run fails on some frameworks but it succeeds on the other framework(s), it's easy to tell which framework the failed test run was running on.

Error messages, screenshots

Because the tests for all three frameworks are run at once, the log messages can end up interwoven like this:

[10:29:27 INF] EXPECTO? Running tests... <Expecto>
[10:29:28 INF] EXPECTO! 1 tests run in 00:00:00.0955849 – 1 passed, 0 ignored, 0 failed, 0 errored. ᕙ໒( ˵ ಠ ╭͜ʖ╮ ಠೃ ˵ )७ᕗ <Expecto>
watch : Exited
watch : Waiting for a file to change before restarting dotnet...
[10:29:28 INF] EXPECTO? Running tests... <Expecto>
[10:29:28 INF] EXPECTO? Running tests... <Expecto>
[10:29:28 INF] EXPECTO! 1 tests run in 00:00:00.1374021 – 1 passed, 0 ignored, 0 failed, 0 errored. ᕙ໒( ˵ ಠ ╭͜ʖ╮ ಠೃ ˵ )७ᕗ <Expecto>
[10:29:28 INF] EXPECTO! 1 tests run in 00:00:00.0931585 – 1 passed, 0 ignored, 0 failed, 0 errored. ᕙ໒( ˵ ಠ ╭͜ʖ╮ ಠೃ ˵ )७ᕗ <Expecto>
watch : Exited
watch : Waiting for a file to change before restarting dotnet...
watch : Exited
watch : Waiting for a file to change before restarting dotnet...

If one of those tests had failed, I would not have been able to tell which .Net framework the failing test was running on; so if it was a bug in .Net Core that was not reproducible in Mono, or a bug in Mono not reproducible in .Net Core, I won't be able to tell. Once haf/expecto#224 is merged, I'd like to add something to the mini-scaffold's build.fsx so that the tests will be run with --log-name Expecto.net461, and so on.

.editorconfig

Missed MyLib replacements

Description

There's still a bunch of places that didn't get MyLib replaced.

Add github template

Add WatchTests target

Add a WatchTests target. This will use dotnet watch to watch the test projects and rerun when either the lib or the tests change.

FAKE 5

Description

We should investigate what it will take to migrate to FAKE 5.

Error messages, screenshots

N/A

Failing test, failing github repo, or reproduction steps

n/a

Expected Behavior

n/a

Known workarounds

n/a

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

"dotnet new mini-scaffold" on Linux strips execute bit from build.sh

The build.sh file checked into the Git repo has the execute bit properly set, but after I run dotnet new -i "MiniScaffold::*" and then dotnet new mini-scaffold, the resulting files have build.sh without the execute bit. This is just a minor annoyance as it's easy to immediately run chmod +x build.sh, but if it can be fixed in the template that would be nice.

I rather suspect, though, that this is a limitation in the dotnet templating engine, in which case you can't fix it in the template. If that's the case, feel free to just close this issue. :-)

System info:

Dotnet version: 2.0.0-preview2-006497
OS version: Linux Mint 18.1 (based on Ubuntu Xenial 16.04)

Add Sourcelink

Add Sourcelink https://github.com/ctaggart/SourceLink

Unwanted Console.Clear() happens when I run WatchTests, but only on net461 framework target

Description

When I run ./build.sh WatchTests, then modify a test file and save it, tests for all three .Net targets (net461, netcore1.1, and netcore2.0) are re-run as they should be. However, the net461 target causes the terminal to be cleared before Expecto produces its output. Since all three of the targets are run in a non-deterministic order, sometimes this results in the net461 test running first, in which case all three test results get printed to the newly-cleared console. But sometimes the net461 test runs second or third, so at least one test result is printed before the console is cleared, which is less than desirable. I can still see the test results by scrolling back through the console, but I'd rather get rid of the Console.Clear() behavior entirely.

Now for the strange part, and why I'm reporting this here rather than in the issue tracker(s) for dotnet-watch, dotnet-mono, or Expecto. If I cd to the tests/foo.Tests directory and then run dotnet watch mono -f net461 -c Release, then the console-clearing behavior does not happen. It only happens if I run the WatchTests target from build.fsx. If I remove the netcoreapp1.1 and netcoreapp2.0 targets from foo.Tests.fsproj, so that it's only running the net461 target, then the console-clearing starts happening again. I can only trigger this unwanted behavior via the combination of having net461 as a target framework in the .fsproj file, and running the WatchTests target in build.fsx.

To reproduce

1. dotnet new mini-scaffold -lang F# -n foo -o foo
2. cd foo
3. ./build.sh WatchTests
4. Edit tests/foo.Tests/Tests.fs
5. Add a new test, save the file
6. dotnet watch triggers, re-running tests for all three target frameworks
7. Immediately before Expecto starts logging for net461, the console is cleared

If ./build.sh WatchTests is replaced by cd tests/Foo.Tests && dotnet watch mono -f net461 -c Release, then the unwanted console-clearing does not occur.

Error messages, screenshots

After the screen clears, I usually see the characters 070;1R just before the Expecto log. E.g., at the top of the just-cleared screen, I see the following:

070;1R[17:01:39 INF] EXPECTO? Running tests... <Expecto>
[17:01:39 INF] EXPECTO! 2 tests run in 00:00:00.0902618 – 2 passed, 0 ignored, 0 failed, 0 errored. ᕙ໒( ˵ ಠ ╭͜ʖ╮ ಠೃ ˵ )७ᕗ <Expecto>
[17:01:39 INF] Ended: mono - 16974 <dotnet-mono>
[17:01:39 INF] Handling AssemblyLoadContext Unloading... <dotnet-mono>
[17:01:39 INF] Killing all processes that are created by dotnet-mono and are still running. <dotnet-mono>
watch : Exited
watch : Waiting for a file to change before restarting dotnet...
watch : Started

Except that once, it wasn't 070;1R that printed, but 828;1R instead:

828;1R[17:13:00 INF] EXPECTO? Running tests... <Expecto>
[17:13:00 INF] EXPECTO! 3 tests run in 00:00:00.0527439 – 3 passed, 0 ignored, 0 failed, 0 errored. ᕙ໒( ˵ ಠ ╭͜ʖ╮ ಠೃ ˵ )७ᕗ <Expecto>
[17:13:00 INF] Ended: mono - 18039 <dotnet-mono>
[17:13:00 INF] Handling AssemblyLoadContext Unloading... <dotnet-mono>
[17:13:00 INF] Killing all processes that are created by dotnet-mono and are still running. <dotnet-mono>
watch : Exited
watch : Waiting for a file to change before restarting dotnet...

Those look like VT102 control codes (without the ESC [ part of the control code) but I haven't been able to find a reference that tells me what ESC [###;1R would mean. But this might be a clue that will help track this down.

Note that all the rest of the text appears like it should: the right colors appear in the console output (e.g., in the various parts of Expecto's console logging messages, where certain bits are supposed to be colored blue or green instead of white, they are blue or green as they're supposed to be), so this is not a case where my terminal color codes are malfunctioning. There's just the one unexplained partial code that shows up, and it always shows up immediately after the console has been cleared.

Expected Behavior

I'd like the terminal to not be cleared before the net461 test results are displayed, so that the other test results won't be hidden.

Known workarounds

I can remove the net461 framework from the .fsproj and just develop for netcoreapp2.0 for a while, then restore the net461 framework when I'm ready to run all the tests, which is a good enough workaround for now since I'm still in heavy development of my project and nowhere near releasing. But it would be nice to figure out what's going on.

Other information

This is on Linux Mint 18, with .Net Core 2.1.4 SDK and Mono 5.8.0.

I've looked through the source for dotnet-watch and dotnet-mono and can't find anything that clears the console. I've also looked through the Expecto source code and likewise haven't found any console-clearing code, so it's a bit of a mystery where this interaction is coming from. I'll continue looking, and will post any information I find on this issue.

Feel free to move this over to https://github.com/TheAngryByrd/dotnet-mono if you believe it belongs over there.

Use buildstats.info for badges

https://github.com/dustinmoris/CI-BuildStats

Add Decent Defaults for nuget package config

Sourcelink seems to break without a remote git repo

Sourcelink seems to break without a remote git repo. Should try to figure out if there's a way to disable it until a remote has been used.

Starting Target: DotnetPack (==> DotnetTest)
dotnet "pack" "/Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj" --configuration Release --output /Users/username/Documents/GitHub/someproj/dist /p:PackageVersion=0.1.0 /p:PackageReleaseNotes="Initial release" /p:SourceLinkCreate=true
Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restoring packages for /Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj...
  Restore completed in 370.9 ms for /Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj.
  fatal: Not a git repository (or any of the parent directories): .git
/Users/username/.nuget/packages/sourcelink.create.commandline/2.7.3/build/SourceLink.Create.CommandLine.targets(21,5): error MSB3073: The command "git rev-parse --show-toplevel" exited with code 128. [/Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj]
  fatal: Not a git repository (or any of the parent directories): .git
/Users/username/.nuget/packages/sourcelink.create.commandline/2.7.3/build/SourceLink.Create.CommandLine.targets(21,5): error MSB3073: The command "git rev-parse --show-toplevel" exited with code 128. [/Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj]
  fatal: Not a git repository (or any of the parent directories): .git
/Users/username/.nuget/packages/sourcelink.create.commandline/2.7.3/build/SourceLink.Create.CommandLine.targets(21,5): error MSB3073: The command "git rev-parse --show-toplevel" exited with code 128. [/Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj]

Or without remote

/Users/username/.nuget/packages/sourcelink.create.commandline/2.7.3/build/SourceLink.Create.CommandLine.targets(24,5): error MSB3073: The command "git config --get remote.origin.url" exited with code 1. [/Users/username/Documents/GitHub/someproj/src/someproj/someproj.fsproj]

Initial build after template installation fails because FAKE package not restored

Linux Mint 18 (based on Ubuntu Xenial), F# 4.1, .Net Core 2.1.4. To reproduce:

1. dotnet new mini-scaffold -n MyCoolNewLib -lang F#
2. cd MyCoolNewLib
3. ./build.sh

Result: Paket restore did not restore packages/build/FAKE/tools/FAKE.exe, so the build naturally failed.

BTW, when I ran mono .paket/paket.exe -v restore, Paket said, "Last restore is still up to date". So this might be a Paket bug; I'm still trying to track down why Paket thinks the last restore is still up to date when there's no packages folder at all.

Append Release notes to nuget package

sprintf "/p:PackageReleaseNotes=\"%s\"" (String.Join("\n",release.Notes))

Gitlab CI and Circle CI support

Is your feature request related to a problem? Please describe.
Appveyor/Travis might now be suitable for everyone

Describe the solution you'd like
Add gitlab and circle ci templates

Describe alternatives you've considered
n/a

Additional context
n/a

build.fsx getTargetFrameworksFromProjectFile null reference exception

Description

If the .fsproj file contains a TargetFramework element instead of a TargetFrameworks element, then running build.cmd results in a null reference exception.

Error messages, screenshots

https://gist.github.com/ScottHutchinson/beb9fc65b9258d87c5409312469e713c#file-miniscaffold-gettargetframeworksfromprojectfile-null-reference-exception-txt-L86

Other information

• Operating System:
  • windows [10]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: 0.8.0

Use Paket instead of nuget

Paket is finally at a point where I think it's suitable to use for the new sdk.

Update AltCover

Description

Please insert a description of your problem or question.

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Code coverage threshold

Description

Add a default code coverage threshold

/p:AltCoverThreshold="percentage statement coverage required"

https://github.com/SteveGilham/altcover/wiki/%60dotnet-test%60-integration

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Paket bootstrapper needs updated to handle TLS 1.2

Description

GitHub disabled TLS 1.0 and 1.1 and paket bootstrapper is failing.

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

fsprojects/Paket#3066

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

CodeCov support

Description

It would be great to have CodeCov support added. Once Expecto gets support we should add it. haf/expecto#219. Here's an example repo doing it in C#/F# https://github.com/codecov/example-csharp/ https://github.com/codecov/example-fsharp

sh files might be rewritten with bad new lines,

Description

sh files might be rewritten with bad new lines, ensure *.sh text eol=lf in .gitattributes

Running build.cmd on newly-created scaffold failed to restore

Description

Immediately after running dotnet new mini-scaffold -lang f# -n fsharp-data-sample --githubUsername ScottHutchinson, running .\build.cmd in the newly-created folder resulted in the error shown in the gist linked below.

Error messages, screenshots

https://gist.github.com/ScottHutchinson/ed54de9714c92aa105d9702870b26150#file-miniscaffold-0-8-0-restore-error-txt-L59

• Operating System:
  • windows [10]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: 0.8.0

Use better travis ci defaults

https://github.com/haf/expecto/blob/master/.travis.yml has a good setup. Since osx tends to fail, putting in the allowed failures is a good idea. Also more versions of mono because why not.

Paket as dotnet tool

Is your feature request related to a problem? Please describe.
Paket has finally become a dotnet tool and it's worth investigating if it's stable enough to use. This means a user only needs mono for building net framework dependencies.

Describe the solution you'd like
Paket as dotnet tool

Describe alternatives you've considered

Additional context

Code formatting

Description

Add a target to format code with https://www.nuget.org/packages/dotnet-fantomas/

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Drop netstandard1.6 and netcoreapp1.1

Description

With logary dropping support for netstandard1.6 haf/expecto@6429c66 and talking with people in the community we should just drop netstandard1.6 and netcoreapp1.1.

Error messages, screenshots

N/A

Failing test, failing github repo, or reproduction steps

N/A

Expected Behavior

N/A

Known workarounds

N/A

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: master

Start with a benchmarking project too

Description

It might be worth considering starting people of right with a BenchmarkDotnet project in the tests folder. This might people thinking early about trying to benchmark particular parts of their library early on.

Error messages, screenshots

n/a

Failing test, failing github repo, or reproduction steps

n/a

Add super simple lib

Miniscaffold might be too much, let's have a super simple lib version available that just supplies paket, fake 5 and class lib with a simple structure

https://twitter.com/k_cieslak/status/1040606250332037121

Add build/release steps to README under Content

Description

Should add build/release steps in the readme under the Content folder so people know what to do after using dotnet new

Error messages, screenshots

N/A

Failing test, failing github repo, or reproduction steps

N/A

Expected Behavior

Same as description.

Known workarounds

N/A

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: master

New issue templates

Github allows for multiple templates for issues now. We should support them https://help.github.com/articles/about-issue-and-pull-request-templates/

Put release notes in git commit

Bump dotnet-mono

Description

dotnet sdk 2.1.101 causes issues with dotnet mono so need to bump the version

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

TheAngryByrd/dotnet-mono#38

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

dotnet test

Description

Now that YoloDev/YoloDev.Expecto.TestSdk#9 has mono support we might be able to just use dotnet test instead of dotnet mono or dotnet run

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Deduplicating files and introducing flags

Is your feature request related to a problem? Please describe.

It's clear that we have a lot of files that are just the same between the Console/Library templates and we should consider consolidating them. Additionally we should probably hide these behind flags. So if you don't want ISSUE_TEMPLATEs you could turn that off. I might split that into a separate issue though.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Better FrameworkPathOverride

Description

dotnet/sdk#335 (comment)

Instead of the build.sh environment variable

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Please provide a description of any known workarounds.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

WIndows build via appveyor

Remove `--restore` from mono run

Via TheAngryByrd/dotnet-mono#1 you no longer need to run --restore

Docs Generation

Description

Like project scaffold, it would be nice to have document generation. Need to research more into this.

Error messages, screenshots

n/a

Failing test, failing github repo, or reproduction steps

n/a

Expected Behavior

n/a

Known workarounds

/na

Paket in magic mode

NETSDK1061 error

Describe the bug
After creating a template, I get an error in ionide

NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.5, but with current settings, version 2.1.0 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish

To Reproduce
Steps to reproduce the behavior:

1. Create a new template
2. Open with ionide
3. Project load fails

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Release notes should be in YYYY-MM-DD format

If you look at the source for FAKE's ReleaseNotesHelper, you'll see that the parseDate format expects dates in ISO 8601 format, e.g. YYYY-MM-DD (with multiple possible separators between the numbers). The template's RELEASE_NOTES.md file should demonstrate how to do dates right so that FAKE will parse them correctly.

AppVeyor badge nuances

Description

Appveyor seems to "normalize" projects.

For example if you started a project called MyLib.SomethingElse, appveyor links should be
(https://buildstats.info/appveyor/chart/TheAngryByrd/MyLib-SomethingElse) (https://ci.appveyor.com/project/TheAngryByrd/MyLib-SomethingElse)

but are

(https://buildstats.info/appveyor/chart/TheAngryByrd/MyLib.SomethingElse) (https://ci.appveyor.com/project/TheAngryByrd/MyLib.SomethingElse)

which leads to no project being found when clicking the badges.

However

https://ci.appveyor.com/api/projects/status/github/TheAngryByrd/MyLib.SomethingElse?svg=true

is perfectly valid.

sigh

Error messages, screenshots

Please add any error logs or screenshots if available.

Failing test, failing github repo, or reproduction steps

Please add either a failing test, a github repo of the problem or detailed reproduction steps.

Expected Behavior

Please define what you would expect the behavior to be like.

Known workarounds

Fixing them manually.

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Assembly Version not listed

Description

Currently the libraries do not generate Assembly versions.

Error messages, screenshots

Assembly info "0.0.0.0"

Failing test, failing github repo, or reproduction steps

Can test with (typedefof<Foo>.GetTypeInfo().Assembly.GetName().Version.ToString())

Expected Behavior

Version info is embedded in the assembly

Known workarounds

It doesn't look like you can easily pass it on the CLI dotnet/sdk#1098 so we might need to just generate the AssemblyInfo with FAKE instead of the dotnet autogenerate. Or modify the fsproj (I'd rather not).

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

Only generate AssemblyInfo on Release

Description

The AssemblyInfo generation adds the current git hash to the assembly which can cause a lot of churn for version control. It would be better to only generate them upon release time. Between dotnet restore and dotnet build if release is called.

Error messages, screenshots

N/A

Failing test, failing github repo, or reproduction steps

N/A

Expected Behavior

N/A

Known workarounds

Setting something like:

"Clean" ?=> "DotnetRestore"
"Clean" ==> "DotnetPack"

"DotnetRestore" ?=> "AssemblyInfo"
"AssemblyInfo" ?=> "DotnetBuild"
"AssemblyInfo" ==> "Publish"

"DotnetRestore"
  ==> "DotnetBuild"
  ==> "DotnetTest"
  ==> "DotnetPack"
  ==> "Publish"
  ==> "Release"

"DotnetRestore"
 ==> "WatchTests"

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version: