Grammar correction of Readme.md and other docs (#13269)
This commit is contained in:
parent
6dec823077
commit
7f9b118dc0
|
@ -143,7 +143,7 @@ We have a Gitter Room which you can join below.
|
|||
|
||||
[![Join the chat](https://img.shields.io/static/v1.svg?label=chat&message=on%20gitter&color=informational&logo=gitter)](https://gitter.im/PowerShell/PowerShell?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
|
||||
|
||||
There is also the community driven PowerShell Virtual User Group, which you can join on:
|
||||
There is also the community-driven PowerShell Virtual User Group, which you can join on:
|
||||
|
||||
* [Slack](https://aka.ms/psslack)
|
||||
* [Discord](https://aka.ms/psdiscord)
|
||||
|
@ -230,7 +230,7 @@ The telemetry we collect falls under the [Microsoft Privacy Statement](https://p
|
|||
|
||||
## Governance
|
||||
|
||||
Governance policy for PowerShell project is described [here][].
|
||||
The governance policy for the PowerShell project is described [here][].
|
||||
|
||||
[here]: https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ We use dummy dependencies between projects to leverage `dotnet` build functional
|
|||
For example, `src\powershell-win-core\powershell-win-core.csproj` has dependency on `Microsoft.PowerShell.Commands.Diagnostics.csproj`,
|
||||
but in reality, there is no build dependency.
|
||||
|
||||
Dummy dependencies allows us to build just `$Top` folder, instead of building several folders.
|
||||
Dummy dependencies allow us to build just `$Top` folder, instead of building several folders.
|
||||
|
||||
### Dummy dependencies rules
|
||||
|
||||
|
@ -106,7 +106,7 @@ On Linux/macOS, PowerShell Core depends on the binary `libpsl-native.so/libpsl-n
|
|||
|
||||
Building those native components requires setting up additional dependencies,
|
||||
which could be a burden to those who don't seek to make changes to the native components.
|
||||
At the meantime, the native component code seldom changes,
|
||||
In the meantime, the native component code seldom changes,
|
||||
so it doesn't make sense to always build them with `Start-PSBuild`.
|
||||
Therefore, we decided to wrap the native components into NuGet packages,
|
||||
so that we only need to build them once when changes are made,
|
||||
|
@ -178,12 +178,12 @@ The layout of files should look like this:
|
|||
Have the DLLs signed with `authenticode dual` certificate and run `nuget pack` from the parent of the `runtimes` folder where `psrp.windows.nuspec` resides.
|
||||
Be sure to use the latest recommended version of [nuget.exe](https://www.nuget.org/downloads).
|
||||
|
||||
Publish latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/psrp.windows.
|
||||
Publish the latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/psrp.windows.
|
||||
|
||||
`PowerShell.Core.Instrumentation.dll` NuGet package is created the same way, but in a separate directory following the same layout above.
|
||||
To create a new NuGet package for `PowerShell.Core.Instrumentation.dll`, you will need the `PowerShell.Core.Instrumentation.nuspec` found in the repo under `src\PowerShell.Core.Instrumentation`.
|
||||
|
||||
Publish latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/PowerShell.Core.Instrumentation.
|
||||
Publish the latest nupkg to https://powershell.myget.org/feed/powershell-core/package/nuget/PowerShell.Core.Instrumentation.
|
||||
|
||||
### libpsl
|
||||
|
||||
|
|
|
@ -73,5 +73,5 @@ The `Start-PSBuild` script will output the location of the executable:
|
|||
|
||||
`./src/powershell-unix/bin/Debug/net5.0/linux-x64/publish/pwsh`.
|
||||
|
||||
You should now be running the PowerShell Core that you just built, if your run the above executable.
|
||||
You should now be running the PowerShell Core that you just built, if you run the above executable.
|
||||
You can run our cross-platform Pester tests with `Start-PSPester`, and our xUnit tests with `Start-PSxUnit`.
|
||||
|
|
|
@ -44,7 +44,7 @@ Or you can call `Install-Dotnet` directly:
|
|||
Install-Dotnet
|
||||
```
|
||||
|
||||
It removes the previously installed version of .NET CLI and install the version that PowerShell Core depends on.
|
||||
It removes the previously installed version of .NET CLI and installs the version that PowerShell Core depends on.
|
||||
If you have any problems installing `dotnet`, please see their [documentation][cli-docs].
|
||||
|
||||
[dotnet-cli]: https://github.com/dotnet/cli
|
||||
|
@ -69,7 +69,7 @@ The function `Get-PSOutput` will return the path to the executable;
|
|||
thus you can execute the development copy via `& (Get-PSOutput)`.
|
||||
|
||||
The `powershell` project is the .NET Core PowerShell host.
|
||||
It is the top level project, so `dotnet build` transitively builds all its dependencies,
|
||||
It is the top-level project, so `dotnet build` transitively builds all its dependencies,
|
||||
and emits a `pwsh` executable.
|
||||
The cross-platform host has built-in documentation via `--help`.
|
||||
|
||||
|
|
|
@ -133,7 +133,7 @@ Creators Update. This version of the .NET Framework allows existing applications
|
|||
However, for Windows systems that have not been updated to .NET Framework 4.7.1 such a
|
||||
binary module will not run correctly in Windows PowerShell.
|
||||
|
||||
Let's see what happens when you attempt use this module in **Windows PowerShell** on
|
||||
Let's see what happens when you attempt to use this module in **Windows PowerShell** on
|
||||
Windows 10 CU (1703 or lower) without .NET Framework 4.7.1 installed.
|
||||
|
||||
1. Copy `MyModule.dll` to a folder on a Windows machine.
|
||||
|
|
Loading…
Reference in a new issue