diff --git a/Documentation/core-repos.md b/Documentation/core-repos.md index df519440..41197f05 100644 --- a/Documentation/core-repos.md +++ b/Documentation/core-repos.md @@ -25,7 +25,7 @@ |Repository |Description | |------------------------------------------------------------------|------------| -|[Dev Community](https://developercommunity.visualstudio.com/spaces/61/index.html) |Report isssues to .NET Framework Developer Community| +|[Dev Community](https://developercommunity.visualstudio.com/spaces/61/index.html) |Report issues to .NET Framework Developer Community| |[microsoft/dotnet-framework-docker](https://github.com/microsoft/dotnet-framework-docker) |.NET Framework Docker images| ## .NET Standard diff --git a/Documentation/microsoft-team.md b/Documentation/microsoft-team.md index cfab31f8..103cb16c 100644 --- a/Documentation/microsoft-team.md +++ b/Documentation/microsoft-team.md @@ -24,17 +24,17 @@ After you join the teams: ## Configure your GitHub account as a Microsoft employee (recommended) * Publicly associate yourself with dotnet and Microsoft orgs - * For Microsoft, go to https://github.com/orgs/Microsoft/people - * For dotnet, go to https://github.com/orgs/dotnet/people - * Search for your GitHub handle in the list - * Choose `Public` from the drop-down list of organization visibility - * Note: Everyone will now see an org badge on your GH profile in the Organizations section + * For Microsoft, go to . + * For dotnet, go to . + * Search for your GitHub handle in the list. + * Choose `Public` from the drop-down list of organization visibility. + * Note: Everyone will now see an org badge on your GH profile in the Organizations section. * Update your profile - * Go to https://github.com/settings/profile - * Match your **Name** on GitHub with full name in address book (so other employees can find you and contact you internally when needed) - * Set `@Microsoft` as your **Company** - * Upload your **picture**, ideally showing your face - * Hint: You can grab your GAL picture from https://microsoft-my.sharepoint.com + * Go to . + * Match your **Name** on GitHub with full name in address book (so other employees can find you and contact you internally when needed). + * Set `@Microsoft` as your **Company**, + * Upload your **picture**, ideally showing your face. + * Hint: You can grab your GAL picture from . ## Install Microsoft open source tools (recommended) @@ -48,9 +48,10 @@ The browser extension is recommended. The VS code extension is optional. ## Get write permissions to repos (optional) Join teams to gain write access to repos: - * Request team membership via https://repos.opensource.microsoft.com/teams - * Ask someone if you don't know which team(s) to join. - * Select `Request to join this team` on the right side - it will send email request to maintainers of the team + +* Request team membership via . +* Ask someone if you don't know which team(s) to join. +* Select `Request to join this team` on the right side - it will send email request to maintainers of the team. ## Security best practices @@ -60,7 +61,7 @@ The following best practices are required for org owners, and recommended for re * Do register a [security key(s)](https://www.yubico.com/works-with-yubikey/catalog/github/) as a two factor method. * Do register an authenticator app -- registering a one-time-password with an app like 1Password is recommended (not tied to your phone). -* Do store recorvery codes in a safe place, like [OneDrive Vault](https://www.microsoft.com/microsoft-365/onedrive/personal-vault), 2FA-protected OneNote or in a password vault like 1Password. +* Do store recovery codes in a safe place, like [OneDrive Vault](https://www.microsoft.com/microsoft-365/onedrive/personal-vault), 2FA-protected OneNote or in a password vault like 1Password. * Do register your GitHub account with your 2FA-protected Facebook account for GitHub account recovery. This is the absolute last recovery option and is considered secure (even if your Facebook account is breached). * Do not use SMS for 2FA or as a recovery fallback. @@ -71,7 +72,7 @@ A few more notes on hardware keys: * You should have at least one hardware key that does not travel with you, but is stored in a secure location (like at home) as a last resort in case you lose access to other factors. * If you have a FIDO2 key, it can be used with [mysignins](https://mysignins.microsoft.com/). * If you have USB-C and USB-A only devices, and want to use hardware keys for them, then you need [separate keys](https://www.yubico.com/works-with-yubikey/catalog/github/). This explains why the example below has three keys registered (one securely stored at home, and two keys for daily use for USB-C and USB-A only devices). -* You can use Windows Hello to signin as a hardware key. This is fine to use, but doesn't replace the need for hardware key that you store in a secure location.Your Windows Hello key is not tied to you, but the machine. It won't survive hardware failures or re-installing Windows. +* You can use Windows Hello to sign in as a hardware key. This is fine to use, but it doesn't replace the need for hardware key that you store in a secure location. Your Windows Hello key is not tied to you, but the machine. It won't survive hardware failures or re-installing Windows. A correctly configured account should look similar to the following: diff --git a/release-notes/1.0/1.0.0-manifest.md b/release-notes/1.0/1.0.0-manifest.md index 934e6e14..2cc300fa 100644 --- a/release-notes/1.0/1.0.0-manifest.md +++ b/release-notes/1.0/1.0.0-manifest.md @@ -1,4 +1,4 @@ -# .NET Core 1.0 mainfest +# .NET Core 1.0 manifest The following is a comprehensive manifest of packages released for .NET Core 1.0. diff --git a/release-notes/1.0/1.0.1-manifest.md b/release-notes/1.0/1.0.1-manifest.md index 8e862958..51ed1ae5 100644 --- a/release-notes/1.0/1.0.1-manifest.md +++ b/release-notes/1.0/1.0.1-manifest.md @@ -1,4 +1,4 @@ -# .NET Core September 2016 Update for .NET Core 1.0 mainfest +# .NET Core September 2016 Update for .NET Core 1.0 manifest The following is a comprehensive manifest of packages released with September 2016 Update for .NET Core 1.0. diff --git a/release-notes/1.0/1.0.11.md b/release-notes/1.0/1.0.11.md index 690157c0..9620ee49 100644 --- a/release-notes/1.0/1.0.11.md +++ b/release-notes/1.0/1.0.11.md @@ -19,7 +19,7 @@ The [.NET Core Docker images](https://hub.docker.com/r/microsoft/dotnet/) have b ## Azure AppServices -Deployment of this update to Azure AppServices is in process. Because AppServices is a high availability service, the deployment is carfully staged across regions over a period of time. Deployment will begin in the West US 2 and North Central US regions with remaining regions following over a few days. +Deployment of this update to Azure AppServices is in process. Because AppServices is a high availability service, the deployment is carefully staged across regions over a period of time. Deployment will begin in the West US 2 and North Central US regions with remaining regions following over a few days. ## Known Issues diff --git a/release-notes/1.0/1.0.13.md b/release-notes/1.0/1.0.13.md index 3cf80a73..96c6d2ca 100644 --- a/release-notes/1.0/1.0.13.md +++ b/release-notes/1.0/1.0.13.md @@ -24,7 +24,7 @@ The [.NET Core Docker images](https://hub.docker.com/r/microsoft/dotnet/) have b See [.NET Core Supported OS Lifecycle Policy](https://github.com/dotnet/core/blob/main/os-lifecycle-policy.md) to learn about Windows, macOS and Linux versions that are supported for each .NET Core release. -As .NET Core 2.1 has become LTS (anounced in [August 2018 blog post](https://blogs.msdn.microsoft.com/dotnet/2018/08/21/net-core-august-2018-update)), 1.0 and 1.1 have entered their maintenance phase and will only get critical security fixes going forward till their end of support on June 27, 2019. +As .NET Core 2.1 has become LTS (announced in [August 2018 blog post](https://blogs.msdn.microsoft.com/dotnet/2018/08/21/net-core-august-2018-update)), 1.0 and 1.1 have entered their maintenance phase and will only get critical security fixes going forward till their end of support on June 27, 2019. ## Notable Changes in 1.0.13 diff --git a/release-notes/1.0/1.0.3-manifest.md b/release-notes/1.0/1.0.3-manifest.md index 0e997c73..d6582cdd 100644 --- a/release-notes/1.0/1.0.3-manifest.md +++ b/release-notes/1.0/1.0.3-manifest.md @@ -1,4 +1,4 @@ -# .NET Core December 2016 Update for .NET Core 1.0 mainfest +# .NET Core December 2016 Update for .NET Core 1.0 manifest The following is a comprehensive manifest of packages released with December 2016 Update for .NET Core 1.0. diff --git a/release-notes/1.0/1.0.3.md b/release-notes/1.0/1.0.3.md index b50db66a..3c3b5201 100644 --- a/release-notes/1.0/1.0.3.md +++ b/release-notes/1.0/1.0.3.md @@ -24,4 +24,4 @@ The fix list below includes a number of components under the .NET Core umbrella ### ASP.NET Core -* Please see the [ASP.NET Core release page](https://github.com/aspnet/home/releases/1.0.3) for details on fixes from ASP.NET Core, MVC, Entitiy Framework Core and others. +* Please see the [ASP.NET Core release page](https://github.com/aspnet/home/releases/1.0.3) for details on fixes from ASP.NET Core, MVC, Entity Framework Core and others. diff --git a/release-notes/1.0/manual-shared-update.md b/release-notes/1.0/manual-shared-update.md index 58ba48f1..2a9e076f 100644 --- a/release-notes/1.0/manual-shared-update.md +++ b/release-notes/1.0/manual-shared-update.md @@ -9,7 +9,7 @@ Again, this process should be done only in the event that required updates are a 3. Back up existing files to be updated 4. Copy new files to the target directory -## Download NuGet packages containing the udpated files ## +## Download NuGet packages containing the updated files ## Download the updated CoreCLR and JIT NuGet package which correspond to your system. Links below will download the packages directly. @@ -31,7 +31,7 @@ JIT ## Rename and Extract ## -If your system doesn't recognize *nupkg files as archives, rename them to *.zip or *.tar.gz and extract the `/runtimes` directory to a temporary location. For CoreCLR there will be `/native` and `/lib/netstandard1.0` directories under `/runtimes`. JIT will have only a `/native` directory. Here's an example of what the tmp location should look like when you are done if the Debian 8 packages were used. The list of binaries will be different for other distros. +If your system doesn't recognize \*nupkg files as archives, rename them to \*.zip or \*.tar.gz and extract the `/runtimes` directory to a temporary location. For CoreCLR there will be `/native` and `/lib/netstandard1.0` directories under `/runtimes`. JIT will have only a `/native` directory. Here's an example of what the tmp location should look like when you are done if the Debian 8 packages were used. The list of binaries will be different for other distros. ``` ~/tmp-update/ @@ -51,7 +51,7 @@ If your system doesn't recognize *nupkg files as archives, rename them to *.zip ## Back up existing files ## -Since we'll be updating files in-place it's a good idea to make a backup. First you need to locate the `Microsoft.NETCoreApp/1.0.0` directory. If you used the installers for Ubuntu, 1.0.0 will be found under `/usr/share/dotnet/shared/Microsoft.NETCore.App/`. Other distro installations are still manual extraction from archives so it's whereever you copied the directory structure. Something like `/opt/dotnet/shared/Microsoft.NETCore.App` would not be uncommon. +Since we'll be updating files in-place it's a good idea to make a backup. First you need to locate the `Microsoft.NETCoreApp/1.0.0` directory. If you used the installers for Ubuntu, 1.0.0 will be found under `/usr/share/dotnet/shared/Microsoft.NETCore.App/`. Other distro installations are still manual extraction from archives so it's wherever you copied the directory structure. Something like `/opt/dotnet/shared/Microsoft.NETCore.App` would not be uncommon. Now that `Microsoft.NETCore.App/1.0.0` has been located, the easiest way to make the backup will be to copy the entire directory which will be updated. `sudo rsync -r 1.0.0/ 1.0.0-backup/` will create the backup directory and copy the entire contents of the source directory. diff --git a/release-notes/1.1/1.1.0-preview1.md b/release-notes/1.1/1.1.0-preview1.md index 275d1463..0828734f 100644 --- a/release-notes/1.1/1.1.0-preview1.md +++ b/release-notes/1.1/1.1.0-preview1.md @@ -33,7 +33,7 @@ Changes to the .NET Core API surface are can be seen in the [1.0-1.1-api-diff](1 ### ASP.NET Core -* Please see the [ASP.NET Core release page](https://github.com/aspnet/home/releases/1.1.0-preview1) for details on fixes from ASP.NET Core, MVC, Entitiy Framework Core and others. +* Please see the [ASP.NET Core release page](https://github.com/aspnet/home/releases/1.1.0-preview1) for details on fixes from ASP.NET Core, MVC, Entity Framework Core and others. ### Commits for 1.1 Preview 1 diff --git a/release-notes/1.1/1.1.10.md b/release-notes/1.1/1.1.10.md index c7cc7bf0..7ae1f6d8 100644 --- a/release-notes/1.1/1.1.10.md +++ b/release-notes/1.1/1.1.10.md @@ -24,7 +24,7 @@ The [.NET Core Docker images](https://hub.docker.com/r/microsoft/dotnet/) have b See [.NET Core Supported OS Lifecycle Policy](https://github.com/dotnet/core/blob/main/os-lifecycle-policy.md) to learn about Windows, macOS and Linux versions that are supported for each .NET Core release. -As .NET Core 2.1 has become LTS (anounced in [August 2018 blog post](https://blogs.msdn.microsoft.com/dotnet/2018/08/21/net-core-august-2018-update)), 1.0 and 1.1 have entered their maintenance phase and will only get critical security fixes going forward till their end of support on June 27, 2019. +As .NET Core 2.1 has become LTS (announced in [August 2018 blog post](https://blogs.msdn.microsoft.com/dotnet/2018/08/21/net-core-august-2018-update)), 1.0 and 1.1 have entered their maintenance phase and will only get critical security fixes going forward till their end of support on June 27, 2019. ## Notable Changes in 1.1.10 diff --git a/samples/YoctoInstructions.md b/samples/YoctoInstructions.md index fe174fef..9f4ee2cf 100644 --- a/samples/YoctoInstructions.md +++ b/samples/YoctoInstructions.md @@ -1,42 +1,43 @@ # .NET Core on Yocto distribution -This document describes how to get .Net apps running on Yocto distribution. -At this momment the focus is on getting standalone applications running. -Unless explicitly mentioned, x86_64 and ARM platforms are supported. +This document describes how to get .Net apps running on Yocto distribution. +At this moment, the focus is on getting standalone applications running. +Unless explicitly mentioned, x86_64 and ARM platforms are supported. ## Getting started with base OS image -Instructions below assume familiarity with Yocto build process. -Initial testing as been done on 2.2 Morty but it is probably applicable to -other versions as well. .NET Core 2.0 Preview2 or later should be used. +Instructions below assume familiarity with Yocto build process. +Initial testing as been done on 2.2 Morty but it is probably applicable to +other versions as well. .NET Core 2.0 Preview2 or later should be used. add the following lines your local.conf or custom recipe. * .NET dependencies + ``` CORE_IMAGE_EXTRA_INSTALL += "libunwind icu libcurl openssl" ``` -* It is strongly recommended to use curl with OpenSSL backend. +* It is strongly recommended to use curl with OpenSSL backend. To do that, you can add something like this: ``` PACKAGECONFIG_pn-curl = 'zlib ipv6 ssl' ``` -Check curl recipe for comple set of options. For debugging you may also add +Check curl recipe for complete set of options. For debugging you may also add ``` CORE_IMAGE_EXTRA_INSTALL += "curl" to get command line tool. ``` -* Some extra space will be needed for the app. Adjust number below to fit the need. -This simply adds 1G of extra space. +* Some extra space will be needed for the app. Adjust number below to fit the need. +This simply adds 1 GB of extra space. ``` IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 1000000" ``` -On x86_64 .NET uses /lib64/ld-linux-x86-64.so.2. However Yocto defaults everything to /lib. +On x86_64 .NET uses /lib64/ld-linux-x86-64.so.2. However, Yocto defaults everything to /lib. This can be solved by adding symbolic link `mkdir -p /lib64; ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2` or adding following lines to force multi-lib layout similar to desktop Linux distributions. ``` @@ -45,7 +46,7 @@ MULTILIBS = "multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib64 = "x86" ``` -# Getting the app ready +## Getting the app ready Write and debug your app. When ready to publish, use: @@ -53,13 +54,10 @@ Write and debug your app. When ready to publish, use: dotnet publish -r ``` -the identifier is 'linux-x86', 'linux-x64' or 'linux-arm' depending on your target architecture. +the identifier is 'linux-x86', 'linux-x64' or 'linux-arm' depending on your target architecture. For ARM and more details you can take a look at [RaspberryPiInstructions](RaspberryPiInstructions.md). Package `bin/Debug/netcoreapp2.0//publish` to your image. -That directory has the native executable binary as well as all needed runtime dependencies. - -After following these steps to configure Yocto, .NET Core applications should run just like they do on other supported Linux distros. - - +That directory has the native executable binary as well as all needed runtime dependencies. +After following these steps to configure Yocto, .NET Core applications should run just like they do on other supported Linux distros. \ No newline at end of file diff --git a/samples/linker-instructions.md b/samples/linker-instructions.md index 9f39d053..ac9a48dc 100644 --- a/samples/linker-instructions.md +++ b/samples/linker-instructions.md @@ -37,7 +37,7 @@ The instructions assume you are using [.NET Core 2.0](https://github.com/dotnet/ ## Linker Switches -The linker can be controlled with the following commandline switches. +The linker can be controlled with the following command-line switches. * `/p:LinkDuringPublish=false` -- Disable the linker. * `/p:ShowLinkerSizeComparison=true` -- Displays a table of size reductions for the application.