You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Review the `CONTRIBUTING.md` file for instructions to build and test the software.
6
+
* Set the `NBGV_GitEngine` environment variable to `Disabled` before running any `dotnet` or `msbuild` commands.
7
+
8
+
## Software Design
9
+
10
+
* Design APIs to be highly testable, and all functionality should be tested.
11
+
* Avoid introducing binary breaking changes in public APIs of projects under `src` unless their project files have `IsPackable` set to `false`.
12
+
13
+
## Testing
14
+
15
+
* There should generally be one test project (under the `test` directory) per shipping project (under the `src` directory). Test projects are named after the project being tested with a `.Test` suffix.
16
+
* Tests should use the Xunit testing framework.
17
+
* Some tests are known to be unstable. When running tests, you should skip the unstable ones by running `dotnet test --filter "TestCategory!=FailsInCloudTest"`.
18
+
19
+
## Coding style
20
+
21
+
* Honor StyleCop rules and fix any reported build warnings *after* getting tests to pass.
22
+
* In C# files, use namespace *statements* instead of namespace *blocks* for all new files.
23
+
* Add API doc comments to all new public and internal members.
When your repo is hosted by GitHub and you are using GitHub Actions, you should create a GitHub Release using the standard GitHub UI.
59
59
Having previously used `nbgv tag` and pushing the tag will help you identify the precise commit and name to use for this release.
60
60
61
-
After publishing the release, the `.github\workflows\release.yml` workflow will be automatically triggered, which will:
61
+
After publishing the release, the `.github/workflows/release.yml` workflow will be automatically triggered, which will:
62
62
63
-
1. Find the most recent `.github\workflows\build.yml` GitHub workflow run of the tagged release.
63
+
1. Find the most recent `.github/workflows/build.yml` GitHub workflow run of the tagged release.
64
64
1. Upload the `deployables` artifact from that workflow run to your GitHub Release.
65
65
1. If you have `NUGET_API_KEY` defined as a secret variable for your repo or org, any nuget packages in the `deployables` artifact will be pushed to nuget.org.
66
66
@@ -71,7 +71,7 @@ Trigger the pipeline by adding the `auto-release` tag on a run of your main `azu
71
71
72
72
## Tutorial and API documentation
73
73
74
-
API and hand-written docs are found under the `docfx/` directory. and are built by [docfx](https://dotnet.github.io/docfx/).
74
+
API and hand-written docs are found under the `docfx/` directory and are built by [docfx](https://dotnet.github.io/docfx/).
75
75
76
76
You can make changes and host the site locally to preview them by switching to that directory and running the `dotnet docfx --serve` command.
77
77
After making a change, you can rebuild the docs site while the localhost server is running by running `dotnet docfx` again from a separate terminal.
@@ -93,11 +93,11 @@ If Renovate is not creating pull requests when you expect it to, check that the
93
93
### Maintaining your repo based on this template
94
94
95
95
The best way to keep your repo in sync with Library.Template's evolving features and best practices is to periodically merge the template into your repo:
96
-
`
96
+
97
97
```ps1
98
98
git fetch
99
99
git checkout origin/main
100
-
.\tools\MergeFrom-Template.ps1
100
+
./tools/MergeFrom-Template.ps1
101
101
# resolve any conflicts, then commit the merge commit.
0 commit comments