Merge branch 'release/0.38.4'

* release/0.38.4: (48 commits)
  (GH-77) Add build badges * fixes #77
  (GH-77) Update SDK/Framework/Studio versions * fixes #77
  Move common MSBuild properties to Shared.msbuild
  (GH-75) Template PackAsTool & nuspec->csproj
  (GH-71) Remove publishing of snupkg file
  (GH-72) Ensure deterministic dll genration
  (GH-71) Switch to embedded pdb
  (GH-77) Update badges
  Revert "(GH-72) Ensure deterministic dll genration"
  (GH-72) Ensure deterministic dll genration
  (build) Fix build error
  (build) Only publish when on Windows in AppVeyor
  (maint) Fix name of template
  (GH-99) Add pull request template
  (build) Bump to newest version of Cake.Frosting
  (GH-100) Add RunWorkingDirectory property
  (GH-97) Add contributing information
  (GH-96) Harmonize build.ps1 arguments with build.sh / .NET CLI * fixes #96
  (GH-95) Update test references to from version 15.x to 16.x * fixes #95
  (GH-88) Add GitHub Actions build * fixes #88
  ...

.editorconfig

@@ -1,14 +1,36 @@
 ; This file is for unifying the coding style for different editors and IDEs.
 ; More information at http://EditorConfig.org
 
+
 root = true
 
 [*]
-end_of_line = CRLF
+charset = utf-8
+end_of_line = lf
+indent_size = 4
+indent_style = space
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.{sln,csproj}]
+end_of_line = crlf
+
+[*.md]
+trim_trailing_whitespace = false
 
 [*.ps1]
 indent_style = space
 indent_size = 2
+charset = utf-8-bom
+end_of_line = crlf
+
+[*.{yml,yaml}]
+indent_size = 2
+indent_style = space
+
+# Files that need to be crlf eol to work
+[tasks.json]
+end_of_line = crlf
 
 [*.cs]
 indent_style = space

.gitattributes

@@ -0,0 +1,63 @@
+###############################################################################
+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto
+
+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp
+
+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following 
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary
+
+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary
+
+###############################################################################
+# diff behavior for common document formats
+# 
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the 
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,13 @@
+<!--
+BEFORE YOU CREATE A PULL REQUEST:
+
+Ensure you have read over CONTRIBUTING - https://github.com/cake-build/frosting/blob/develop/CONTRIBUTING.md. We provide VERY defined guidance (as such, we strongly adhere to it).
+
+A summary of our expectations:
+ - You are not submitting a pull request from your MASTER branch.
+ - Do not reformat code, it makes it hard to see what has changed. Leave the formatting to us.
+
+THANKS! We appreciate you reading the entire Contributing document and not just scanning through it.
+
+DELETE EVERYTHING IN THIS COMMENT BLOCK
+-->

.github/workflows/build.yml

@@ -0,0 +1,31 @@
+name: Build
+on:
+  pull_request:
+  push:
+    branches:
+      - master
+      - develop
+jobs:
+  build:
+    name: Build
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [windows-latest, ubuntu-latest, macos-latest]
+    steps:
+      - name: Get the sources
+        uses: actions/checkout@v2
+
+      - name: Fetch all history for all tags and branches
+        run: git fetch --prune --unshallow
+
+      - name: Install .NET Core SDK 3.1.301
+        uses: actions/setup-dotnet@v1
+        with:
+          dotnet-version: '3.1.301'
+
+      - name: Run Frosting Build
+        env:
+          DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX: 2
+        run: |
+          dotnet run --project ./build/Build.csproj

.gitignore

@@ -70,3 +70,5 @@ packages
 
 # Windows
 Thumbs.db
+
+.DS_Store

CODE_OF_CONDUCT.md

@@ -0,0 +1,24 @@
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery
+- Personal attacks
+- Trolling or insulting/derogatory comments
+- Public or private harassment
+- Publishing other's private information, such as physical or electronic addresses, without explicit permission
+- Other unethical or unprofessional conduct
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer at [[email protected]](mailto:[email protected]). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.
+
+This Code of Conduct is adapted from the Contributor Covenant, version 1.3.0, available from http://contributor-covenant.org/version/1/3/0/

CONTRIBUTING.md

@@ -0,0 +1,164 @@
+# Contribution Guidelines
+
+* [Prerequisites](#prerequisites)
+* [Definition of trivial contributions](#definition-of-trivial-contributions)
+* [Code](#code)
+  * [Code style](#code-style)
+  * [Dependencies](#dependencies)
+  * [Unit tests](#unit-tests)
+* [Contributing process](#contributing-process)
+  * [Get buyoff or find open community issues or features](#get-buyoff-or-find-open-community-issues-or-features)
+  * [Set up your environment](#Set-up-your-environment)
+  * [Prepare commits](#prepare-commits)
+  * [Submit pull request](#Submit-pull-request)
+  * [Respond to feedback on pull request](#respond-to-feedback-on-pull-request)
+* [Other general information](#other-general-information)
+* [Acknowledgement](#acknowledgement)
+
+## Prerequisites
+
+By contributing to Cake, you assert that:
+
+* The contribution is your own original work.
+* You have the right to assign the copyright for the work (it is not owned by your employer, or
+  you have been given copyright assignment in writing).
+* You [license](https://github.com/cake-build/cake/blob/develop/LICENSE) the contribution under the terms applied to the rest of the Cake project.
+* You agree to follow the [code of conduct](https://github.com/cake-build/cake/blob/develop/CODE_OF_CONDUCT.md).
+
+## Definition of trivial contributions
+It's hard to define what is a trivial contribution. Sometimes even a 1 character change can be considered significant.
+Unfortunately because it can be subjective, the decision on what is trivial comes from the maintainers of the project
+and not from folks contributing to the project.
+
+What is generally considered trivial:
+
+* Fixing a typo.
+* Documentation changes.
+* Fixes to non-production code - like fixing something small in the build code.
+
+What is generally not considered trivial:
+
+ * Changes to any code that would be delivered as part of the final product.
+   This includes any scripts that are delivered, such as the PowerShell bootstrapper.
+   Yes, even 1 character changes could be considered non-trivial.
+
+## Code
+### Code style
+
+Normal .NET coding guidelines apply.
+See the [Framework Design Guidelines](https://msdn.microsoft.com/en-us/library/ms229042%28v=vs.110%29.aspx) for more information.
+
+### Unit tests
+
+Make sure to run all unit tests before creating a pull request.
+Any new code should also have reasonable unit test coverage.
+
+## Contributing process
+### Get buyoff or find open community issues or features
+
+ * Through GitHub, or through the [Gitter chat](https://gitter.im/cake-build/cake) (preferred),
+   you talk about a feature you would like to see (or a bug), and why it should be in Cake.
+   * If approved through the Gitter chat, ensure an accompanying GitHub issue is created with
+     information and a link back to the discussion.
+ * Once you get a nod from one of the [Cake Team](https://github.com/cake-build?tab=members), you can start on the feature.
+ * Alternatively, if a feature is on the issues list with the
+   [Up For Grabs](https://github.com/cake-build/frosting/labels/up-for-grabs) label,
+   it is open for a community member (contributor) to patch. You should comment that you are signing up for it on
+   the issue so someone else doesn't also sign up for the work.
+
+### Set up your environment
+
+ * You create, or update, a fork of cake-build/frosting under your GitHub account.
+ * From there you create a branch named specific to the feature.
+ * In the branch you do work specific to the feature.
+ * Please also observe the following:
+    * No reformatting
+    * No changing files that are not specific to the feature.
+    * More covered below in the **Prepare commits** section.
+ * Test your changes and please help us out by updating and implementing some automated tests.
+   It is recommended that all contributors spend some time looking over the tests in the source code.
+   You can't go wrong emulating one of the existing tests and then changing it specific to the behavior you are testing.
+ * Please do not update your branch from the develop unless we ask you to. See the responding to feedback section below.
+
+### Prepare commits
+This section serves to help you understand what makes a good commit.
+
+A commit should observe the following:
+
+ * A commit is a small logical unit that represents a change.
+ * Should include new or changed tests relevant to the changes you are making.
+ * No unnecessary whitespace. Check for whitespace with `git diff --check` and `git diff --cached --check` before commit.
+ * You can stage parts of a file for commit.
+
+### Submit pull request
+Prerequisites:
+
+ * You are making commits in a feature branch.
+ * All code should compile without errors or warnings.
+ * All tests should be passing.
+
+Submitting PR:
+
+ * Once you feel it is ready, submit the pull request to the `cake-build/frosting` repository against the `develop` branch
+   unless specifically requested to submit it against another branch.
+   * In the case of a larger change that is going to require more discussion,
+     please submit a PR sooner. Waiting until you are ready may mean more changes than you are
+     interested in if the changes are taking things in a direction the maintainers do not want to go.
+ * In the pull request, outline what you did and point to specific conversations (as in URLs)
+   and issues that you are resolving. This is a tremendous help for us in evaluation and acceptance.
+ * Once the pull request is in, please do not delete the branch or close the pull request
+   (unless something is wrong with it).
+ * One of the Cake team members, or one of the maintainers, will evaluate it within a
+   reasonable time period (which is to say usually within 1-3 weeks). Some things get evaluated
+   faster or fast tracked. We are human and we have active lives outside of open source so don't
+   fret if you haven't seen any activity on your pull request within a month or two.
+   We don't have a Service Level Agreement (SLA) for pull requests.
+   Just know that we will evaluate your pull request.
+
+### Respond to feedback on pull request
+
+We may have feedback for you to fix or change some things. We generally like to see that pushed against
+the same topic branch (it will automatically update the Pull Request). You can also fix/squash/rebase
+commits and push the same topic branch with `--force` (it's generally acceptable to do this on topic
+branches not in the main repository, it is generally unacceptable and should be avoided at all costs
+against the main repository).
+
+If we have comments or questions when we do evaluate it and receive no response, it will probably
+lessen the chance of getting accepted. Eventually, this means it will be closed if it is not accepted.
+Please know this doesn't mean we don't value your contribution, just that things go stale. If in the
+future you want to pick it back up, feel free to address our concerns/questions/feedback and reopen
+the issue/open a new PR (referencing old one).
+
+Sometimes we may need you to rebase your commit against the latest code before we can review it further.
+If this happens, you can do the following:
+
+ * `git fetch upstream` (upstream would be the mainstream repo or `cake-build/frosting` in this case)
+ * `git checkout develop`
+ * `git rebase upstream/develop`
+ * `git checkout your-branch`
+ * `git rebase develop`
+ * Fix any merge conflicts
+ * `git push origin your-branch` (origin would be your GitHub repo or `your-github-username/cake` in this case).
+   You may need to `git push origin your-branch --force` to get the commits pushed.
+   This is generally acceptable with topic branches not in the mainstream repository.
+
+The only reasons a pull request should be closed and resubmitted are as follows:
+
+ * When the pull request is targeting the wrong branch (this doesn't happen as often).
+ * When there are updates made to the original by someone other than the original contributor.
+   Then the old branch is closed with a note on the newer branch this supersedes #github_number.
+
+## Other general information
+If you reformat code or hit core functionality without an approval from a person on the Cake Team,
+it's likely that no matter how awesome it looks afterwards, it will probably not get accepted.
+Reformatting code makes it harder for us to evaluate exactly what was changed.
+
+If you do these things, it will be make evaluation and acceptance easy.
+Now if you stray outside of the guidelines we have above, it doesn't mean we are going to ignore
+your pull request. It will just make things harder for us.
+Harder for us roughly translates to a longer SLA for your pull request.
+
+## Acknowledgement
+
+This contribution guide was taken from the [Chocolatey project](https://chocolatey.org/)
+with permission and was edited to follow Cake's conventions and processes.

GitReleaseManager.yaml

@@ -0,0 +1,28 @@
+issue-labels-include:
+- Breaking change
+- Feature
+- Bug
+- Improvement
+- Documentation
+issue-labels-exclude:
+- Build
+issue-labels-alias:
+    - name:    Documentation
+      header:  Documentation
+      plural:  Documentation
+create:
+  include-sha-section: true
+  sha-section-heading: "SHA256 Hashes of the release artifacts"
+  sha-section-line-format: "- `{1}\t{0}`"
+close:
+  use-issue-comments: true
+  issue-comment: |-
+    :tada: This issue has been resolved in version {milestone} :tada:
+
+    The release is available on:
+
+    - [GitHub Release](https://github.com/{owner}/{repository}/releases/tag/{milestone})
+    - [NuGet Package](https://www.nuget.org/packages/Cake/{milestone})
+
+    Your **[GitReleaseManager](https://github.com/GitTools/GitReleaseManager)** bot :package::rocket:
+