Rename afd command

Author: Chenglong Liu

src/Cdn/Cdn.Autorest/.gitignore

@@ -6,7 +6,6 @@ internal
 exports
 tools
 custom/*.psm1
-custom/autogen-model-cmdlets
 test/*-TestResults.xml
 /*.ps1
 /*.ps1xml

src/Cdn/Cdn.Autorest/README.md

@@ -71,6 +71,12 @@ directive:
       subject: Profile
     hide: true
 
+  - where:
+      subject: Afd(.*)
+    set:
+      subject-prefix: FrontDoorCdn
+      subject: $1
+
   # https://github.com/Azure/autorest.powershell/issues/906
   - where:
       model-name: AfdDomainUpdatePropertiesParameters

src/Cdn/Cdn.Autorest/custom/README.md

@@ -12,7 +12,7 @@ For `Az.Cdn` to use custom cmdlets, it does this two different ways. We **highly
 
 For C# cmdlets, they are compiled with the rest of the generated low-level cmdlets into the `./bin/Az.Cdn.private.dll`. The names of the cmdlets (methods) and files must follow the `[cmdletName]_[variantName]` syntax used for generated cmdlets. The `variantName` is used as the `ParameterSetName`, so use something appropriate that doesn't clash with already created variant or parameter set names. You cannot use the `ParameterSetName` property in the `Parameter` attribute on C# cmdlets. Each cmdlet must be separated into variants using the same pattern as seen in the `generated/cmdlets` folder.
 
-For script cmdlets, these are loaded via the `Az.Cdn.custom.psm1`. Then, during the build process, this module is loaded and processed in the same manner as the C# cmdlets. The fundamental difference is the script cmdlets use the `ParameterSetName` attribute and C# cmdlets do not. To create a script cmdlet variant of a generated cmdlet, simply decorate all parameters in the script with the new `ParameterSetName` in the `Parameter` attribute. This will appropriately treat each parameter set as a separate variant when processed to be exported during the build.
+For script cmdlets, these are loaded via the `Az.Cdn.custom.psm1`. Then, during the build process, this module is loaded and processed in the same manner as the C# cmdlets. The fundemental difference is the script cmdlets use the `ParameterSetName` attribute and C# cmdlets do not. To create a script cmdlet variant of a generated cmdlet, simply decorate all parameters in the script with the new `ParameterSetName` in the `Parameter` attribute. This will appropriately treat each parameter set as a separate variant when processed to be exported during the build.
 
 ## Purpose
 This allows the modules to have cmdlets that were not defined in the REST specification. It also allows combining logic using generated cmdlets. This is a level of customization beyond what can be done using the [readme configuration options](https://github.com/Azure/autorest/blob/master/docs/powershell/options.md) that are currently available. These custom cmdlets are then referenced by the cmdlets created at build-time in the `../exports` folder.
@@ -32,10 +32,10 @@ These provide functionality to our HTTP pipeline and other useful features. In s
 ### Attributes
 For processing the cmdlets, we've created some additional attributes:
 - `Microsoft.Azure.PowerShell.Cmdlets.Cdn.DescriptionAttribute`
-  - Used in C# cmdlets to provide a high-level description of the cmdlet. This is propagated to reference documentation via [help comments](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_comment_based_help) in the exported scripts.
+  - Used in C# cmdlets to provide a high-level description of the cmdlet. This is propegated to reference documentation via [help comments](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help) in the exported scripts.
 - `Microsoft.Azure.PowerShell.Cmdlets.Cdn.DoNotExportAttribute`
   - Used in C# and script cmdlets to suppress creating an exported cmdlet at build-time. These cmdlets will *not be exposed* by `Az.Cdn`.
 - `Microsoft.Azure.PowerShell.Cmdlets.Cdn.InternalExportAttribute`
-  - Used in C# cmdlets to route exported cmdlets to the `../internal`, which are *not exposed* by `Az.Cdn`. For more information, see [README.md](../internal/README.md) in the `../internal` folder.
+  - Used in C# cmdlets to route exported cmdlets to the `../internal`, which are *not exposed* by `Az.Cdn`. For more information, see [readme.md](../internal/readme.md) in the `../internal` folder.
 - `Microsoft.Azure.PowerShell.Cmdlets.Cdn.ProfileAttribute`
   - Used in C# and script cmdlets to define which Azure profiles the cmdlet supports. This is only supported for Azure (`--azure`) modules.

src/Cdn/Cdn.Autorest/docs/README.md

@@ -1,5 +1,5 @@
 # Docs
-This directory contains the documentation of the cmdlets for the `Az.Cdn` module. To run documentation generation, use the `generate-help.ps1` script at the root module folder. Files in this folder will *always be overridden on regeneration*. To update documentation examples, please use the `../examples` folder.
+This directory contains the documentation of the cmdlets for the `Az.Cdn` module. To run documentation generation, use the `generate-help.ps1` script at the root module folder. Files in this folder will *always be overriden on regeneration*. To update documentation examples, please use the `../examples` folder.
 
 ## Info
 - Modifiable: no
@@ -8,4 +8,4 @@ This directory contains the documentation of the cmdlets for the `Az.Cdn` module
 - Packaged: yes
 
 ## Details
-The process of documentation generation loads `Az.Cdn` and analyzes the exported cmdlets from the module. It recognizes the [help comments](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_comment_based_help) that are generated into the scripts in the `../exports` folder. Additionally, when writing custom cmdlets in the `../custom` folder, you can use the help comments syntax, which decorate the exported scripts at build-time. The documentation examples are taken from the `../examples` folder.
+The process of documentation generation loads `Az.Cdn` and analyzes the exported cmdlets from the module. It recognizes the [help comments](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help) that are generated into the scripts in the `../exports` folder. Additionally, when writing custom cmdlets in the `../custom` folder, you can use the help comments syntax, which decorate the exported scripts at build-time. The documentation examples are taken from the `../examples` folder.

src/Cdn/Cdn.Autorest/examples/readme.md

@@ -0,0 +1,11 @@
+# Examples
+This directory contains examples from the exported cmdlets of the module. When `build-module.ps1` is ran, example stub files will be generated here. If your module support Azure Profiles, the example stubs will be in individual profile folders. These example stubs should be updated to show how the cmdlet is used. The examples are imported into the documentation when `generate-help.ps1` is ran.
+
+## Info
+- Modifiable: yes
+- Generated: partial
+- Committed: yes
+- Packaged: no
+
+## Purpose
+This separates the example documentation details from the generated documentation information provided directly from the generated cmdlets. Since the cmdlets don't have examples from the REST spec, this provides a means to add examples easily. The example stubs provide the markdown format that is required. The 3 core elements are: the name of the example, the code information of the example, and the description of the example. That information, if the markdown format is followed, will be available to documentation generation and be part of the documents in the `../docs` folder.

src/Cdn/Cdn.Autorest/how-to.md

@@ -2,19 +2,19 @@
 This document describes how to develop for `Az.Cdn`.
 
 ## Building `Az.Cdn`
-To build, run the `build-module.ps1` at the root of the module directory. This will generate the proxy script cmdlets that are the cmdlets being exported by this module. After the build completes, the proxy script cmdlets will be output to the `exports` folder. To read more about the proxy script cmdlets, look at the [README.md](exports/README.md) in the `exports` folder.
+To build, run the `build-module.ps1` at the root of the module directory. This will generate the proxy script cmdlets that are the cmdlets being exported by this module. After the build completes, the proxy script cmdlets will be output to the `exports` folder. To read more about the proxy script cmdlets, look at the [readme.md](exports/readme.md) in the `exports` folder.
 
 ## Creating custom cmdlets
-To add cmdlets that were not generated by the REST specification, use the `custom` folder. This folder allows you to add handwritten `.ps1` and `.cs` files. Currently, we support using `.ps1` scripts as new cmdlets or as additional low-level variants (via `ParameterSet`), and `.cs` files as low-level (variants) cmdlets that the exported script cmdlets call. We do not support exporting any `.cs` (dll) cmdlets directly. To read more about custom cmdlets, look at the [README.md](custom/README.md) in the `custom` folder.
+To add cmdlets that were not generated by the REST specification, use the `custom` folder. This folder allows you to add handwritten `.ps1` and `.cs` files. Currently, we support using `.ps1` scripts as new cmdlets or as additional low-level variants (via `ParameterSet`), and `.cs` files as low-level (variants) cmdlets that the exported script cmdlets call. We do not support exporting any `.cs` (dll) cmdlets directly. To read more about custom cmdlets, look at the [readme.md](custom/readme.md) in the `custom` folder.
 
 ## Generating documentation
-To generate documentation, the process is now integrated into the `build-module.ps1` script. If you don't want to run this process as part of `build-module.ps1`, you can provide the `-NoDocs` switch. If you want to run documentation generation after the build process, you may still run the `generate-help.ps1` script. Overall, the process will look at the documentation comments in the generated and custom cmdlets and types, and create `.md` files into the `docs` folder. Additionally, this pulls in any examples from the `examples` folder and adds them to the generated help markdown documents. To read more about examples, look at the [README.md](examples/README.md) in the `examples` folder. To read more about documentation, look at the [README.md](docs/README.md) in the `docs` folder.
+To generate documentation, the process is now integrated into the `build-module.ps1` script. If you don't want to run this process as part of `build-module.ps1`, you can provide the `-NoDocs` switch. If you want to run documentation generation after the build process, you may still run the `generate-help.ps1` script. Overall, the process will look at the documentation comments in the generated and custom cmdlets and types, and create `.md` files into the `docs` folder. Additionally, this pulls in any examples from the `examples` folder and adds them to the generated help markdown documents. To read more about examples, look at the [readme.md](examples/readme.md) in the `examples` folder. To read more about documentation, look at the [readme.md](docs/readme.md) in the `docs` folder.
 
 ## Testing `Az.Cdn`
-To test the cmdlets, we use [Pester](https://github.com/pester/Pester). Tests scripts (`.ps1`) should be added to the `test` folder. To execute the Pester tests, run the `test-module.ps1` script. This will run all tests in `playback` mode within the `test` folder. To read more about testing cmdlets, look at the [README.md](examples/README.md) in the `examples` folder.
+To test the cmdlets, we use [Pester](https://github.com/pester/Pester). Tests scripts (`.ps1`) should be added to the `test` folder. To execute the Pester tests, run the `test-module.ps1` script. This will run all tests in `playback` mode within the `test` folder. To read more about testing cmdlets, look at the [readme.md](examples/readme.md) in the `examples` folder.
 
 ## Packing `Az.Cdn`
-To pack `Az.Cdn` for distribution, run the `pack-module.ps1` script. This will take the contents of multiple directories and certain root-folder files to create a `.nupkg`. The structure of the `.nupkg` is created so it can be loaded part of a [PSRepository](https://docs.microsoft.com/powershell/module/powershellget/register-psrepository). Additionally, this package is in a format for distribution to the [PSGallery](https://www.powershellgallery.com/). For signing an Azure module, please contact the [Azure PowerShell](https://github.com/Azure/azure-powershell) team.
+To pack `Az.Cdn` for distribution, run the `pack-module.ps1` script. This will take the contents of multiple directories and certain root-folder files to create a `.nupkg`. The structure of the `.nupkg` is created so it can be loaded part of a [PSRepository](https://docs.microsoft.com/en-us/powershell/module/powershellget/register-psrepository). Additionally, this package is in a format for distribution to the [PSGallery](https://www.powershellgallery.com/). For signing an Azure module, please contact the [Azure PowerShell](https://github.com/Azure/azure-powershell) team.
 
 ## Module Script Details
 There are multiple scripts created for performing different actions for developing `Az.Cdn`.

src/Cdn/Cdn.Autorest/test/loadEnv.ps1

@@ -1,5 +1,6 @@
 # ----------------------------------------------------------------------------------
-# Copyright (c) Microsoft Corporation. All rights reserved.
+#
+# Copyright Microsoft Corporation
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
 # You may obtain a copy of the License at
@@ -9,8 +10,6 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-# Code generated by Microsoft (R) AutoRest Code Generator.Changes may cause incorrect behavior and will be lost if the code
-# is regenerated.
 # ----------------------------------------------------------------------------------
 $envFile = 'env.json'
 if ($TestMode -eq 'live') {