Minor typo fixes.

docs/appendix/msbuild-props.md

@@ -1,6 +1,6 @@
 # MSBuild Properties
 
-The Mobile.BuildTools additionally provides a number of MSBuild Properties to futher assist advanced developers in creating advanced build pipelines.
+The Mobile.BuildTools additionally provides a number of MSBuild Properties to further assist advanced developers in creating advanced build pipelines.
 
 | PropertyName | Description |
 |:------------:|:-----------:|

docs/config/app.config/index.md

@@ -13,7 +13,7 @@ By default Mobile.BuildTools will look for any file in the root of the head proj
 }
 ```
 
-!!! note Note
+!!! note
     By default the Mobile.BuildTools will only bundle the transformed app.config into your project. You can optionally set the strategy to `BundleAll` or `BundleNonStandard` if you require runtime transformations.
 
 ### App Config Strategy
@@ -40,13 +40,13 @@ By default Mobile.BuildTools will look for any file in the root of the head proj
 | Xamarin.TVOS* | Yes |
 | Tizen* | Yes |
 
-!!!! note Note
-    Platform's with an asterik have not been tested explicitly.
+!!! note
+    Platform's with an asterisk have not been tested explicitly.
 
 ## F.A.Q.
 
 Q. Can I use the ConfigurationManager without using the Mobile.BuildTools?
 A. Yes you absolutely can. The [AppConfigSample](https://github.com/dansiegel/Mobile.BuildTools/tree/master/samples) project in the samples folder does exactly that!
 
-Q. How do I use the Enviornments?
+Q. How do I use the Environments?
 A. By default Environments are disabled. This means that we will only copy the transformed app.config into your project and the ConfigurationManager will only read the primary app.config.

docs/config/app.config/transformations.md

@@ -15,7 +15,7 @@ A basic app config may look like:
 </configuration>
 ```
 
-A Trasnsformation config may look like:
+A Transformation config may look like:
 
 ```xml
 <?xml version="1.0" encoding="utf-8" ?>

docs/config/secrets/basics.md

@@ -10,4 +10,4 @@ The Secrets class is autogenerated from a `secrets.json` file. This must be a si
 ```
 
 !!! danger "Critical Note"
-    Be sure to add the secrets.json to your .gitignore. If this is accidently checked into source control it negates the entire purpose of use the Secrets from the Mobile.BuildTools!
+    Be sure to add the secrets.json to your .gitignore. If this is accidentally checked into source control it negates the entire purpose of use the Secrets from the Mobile.BuildTools!

docs/credits.md

@@ -8,4 +8,4 @@ While the Mobile.BuildTools does not add any external dependencies to your proje
 | SixLabors.ImageSharp | Apache | [SixLabors/ImageSharp/](https://github.com/SixLabors/ImageSharp/) |
 
 !!! note Note
-    Microsoft.Web.Xdt is the only reference added to projects, if using the Mobile.BuildTools.Configuration pacakge. There is never any bloat added by the core Mobile.BuildTools pacakge to your applications. Despite being from the aspnet team this package does not bring in any additional references.
+    Microsoft.Web.Xdt is the only reference added to projects, if using the Mobile.BuildTools.Configuration package. There is never any bloat added by the core Mobile.BuildTools package to your applications. Despite being from the aspnet team this package does not bring in any additional references.

docs/faq.md

@@ -2,7 +2,7 @@
 
 #### Should every value in my Secrets be "Secret"?
 
-The Secrets Class is a great way to prevent security vulnerbilities created from checking into source control things like Client Id's, Consumer Secrets, or Connection Strings. But it really doesn't have to stop there. In fact the Secrets class is a great way of setting the configuration environment for your application at build. Should your build point to the Dev, Stage, or Production API? This is also a great way of being very intentional about it.
+The Secrets Class is a great way to prevent security vulnerabilities created from checking into source control things like Client Id's, Consumer Secrets, or Connection Strings. But it really doesn't have to stop there. In fact the Secrets class is a great way of setting the configuration environment for your application at build. Should your build point to the Dev, Stage, or Production API? This is also a great way of being very intentional about it.
 
 #### Does the Secrets class have to be in the Helpers namespace or named Secrets?
 
@@ -14,4 +14,4 @@ We try to be smart about what we will and will not do. There is an initializatio
 
 #### I installed the Mobile.BuildTools why can't I access the ConfigurationManager?
 
-We explicitly seperated the ConfigurationManager from the Mobile.BuildTools as we recognize that not everyone will want to use this feature. In order to get the build time transformations you will need to have the Mobile.BuildTools installed in your platform projects, however you will need the Mobile.BuildTools.Configuration package installed in any project where you want to use the ConfigurationManager.
+We explicitly separated the ConfigurationManager from the Mobile.BuildTools as we recognize that not everyone will want to use this feature. In order to get the build time transformations you will need to have the Mobile.BuildTools installed in your platform projects, however you will need the Mobile.BuildTools.Configuration package installed in any project where you want to use the ConfigurationManager.

docs/index.md

@@ -1,6 +1,6 @@
 # Getting Started
 
-The Mobile.BuildTools is an easy to use NuGet package that adds new MSBuild targets to your build pipeline. In essenence it teaches MSBuild some new tricks to help make your DevOps easier and help you follow better practices while developing your application. The bulk of support is around Xamarin.Android and Xamarin.iOS and it will work regardless of whether you are using the native tooling, Xamarin.Forms, or Uno to create your UI.
+The Mobile.BuildTools is an easy to use NuGet package that adds new MSBuild targets to your build pipeline. In essence it teaches MSBuild some new tricks to help make your DevOps easier and help you follow better practices while developing your application. The bulk of support is around Xamarin.Android and Xamarin.iOS and it will work regardless of whether you are using the native tooling, Xamarin.Forms, or Uno to create your UI.
 
 The Mobile.BuildTools are a collection of MSBuild Tasks that help make MSBuild smarter in handling the build process for CI/CD with Mobile Applications. The library was born from a desire to share build processes from one app to the next without having to copy and paste a bunch of build scripts each of which could easily end up out of date. Because the Mobile.BuildTools simply provides MSBuild Tasks, this adds nothing to the size of your application and if being used on a project that will be packed and shared, you can set the PackageReference's PrivateAssets to all.
 

docs/manifests/versioning.md

@@ -1,6 +1,6 @@
 # Build Versioning
 
-Build versioning can be extremely important for analytics and dianostics. What's more is that Mobile development requires unique builds. No longer can you be lazy and ship apps for 15 years at Version 1.0.0.0. Ok technically all of your binaries in the application all will show that version, but the app itself must have a unique build number to allow you to upload to the App Store and Google Play.
+Build versioning can be extremely important for analytics and diagnostics. What's more is that Mobile development requires unique builds. No longer can you be lazy and ship apps for 15 years at Version 1.0.0.0. Ok technically all of your binaries in the application all will show that version, but the app itself must have a unique build number to allow you to upload to the App Store and Google Play.
 
 ```json
 {