|
| 1 | +# How-To |
| 2 | +This document describes how to develop for `Az.Sql`. |
| 3 | + |
| 4 | +## Building `Az.Sql` |
| 5 | +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. |
| 6 | + |
| 7 | +## Creating custom cmdlets |
| 8 | +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. |
| 9 | + |
| 10 | +## Generating documentation |
| 11 | +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. |
| 12 | + |
| 13 | +## Testing `Az.Sql` |
| 14 | +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. |
| 15 | + |
| 16 | +## Packing `Az.Sql` |
| 17 | +To pack `Az.Sql` 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://learn.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. |
| 18 | + |
| 19 | +## Module Script Details |
| 20 | +There are multiple scripts created for performing different actions for developing `Az.Sql`. |
| 21 | +- `build-module.ps1` |
| 22 | + - Builds the module DLL (`./bin/Az.Sql.private.dll`), creates the exported cmdlets and documentation, generates custom cmdlet test stubs and exported cmdlet example stubs, and updates `./Az.Sql.psd1` with Azure profile information. |
| 23 | + - **Parameters**: [`Switch` parameters] |
| 24 | + - `-Run`: After building, creates an isolated PowerShell session and loads `Az.Sql`. |
| 25 | + - `-Test`: After building, runs the `Pester` tests defined in the `test` folder. |
| 26 | + - `-Docs`: After building, generates the Markdown documents for the modules into the `docs` folder. |
| 27 | + - `-Pack`: After building, packages the module into a `.nupkg`. |
| 28 | + - `-Code`: After building, opens a VSCode window with the module's directory and runs (see `-Run`) the module. |
| 29 | + - `-Release`: Builds the module in `Release` configuration (as opposed to `Debug` configuration). |
| 30 | + - `-NoDocs`: Supresses writing the documentation markdown files as part of the cmdlet exporting process. |
| 31 | + - `-Debugger`: Used when attaching the debugger in Visual Studio to the PowerShell session, and running the build process without recompiling the DLL. This suppresses running the script as an isolated process. |
| 32 | +- `run-module.ps1` |
| 33 | + - Creates an isolated PowerShell session and loads `Az.Sql` into the session. |
| 34 | + - Same as `-Run` in `build-module.ps1`. |
| 35 | + - **Parameters**: [`Switch` parameters] |
| 36 | + - `-Code`: Opens a VSCode window with the module's directory. |
| 37 | + - Same as `-Code` in `build-module.ps1`. |
| 38 | +- `generate-help.ps1` |
| 39 | + - Generates the Markdown documents for the modules into the `docs` folder. |
| 40 | + - Same as `-Docs` in `build-module.ps1`. |
| 41 | +- `test-module.ps1` |
| 42 | + - Runs the `Pester` tests defined in the `test` folder. |
| 43 | + - Same as `-Test` in `build-module.ps1`. |
| 44 | +- `pack-module.ps1` |
| 45 | + - Packages the module into a `.nupkg` for distribution. |
| 46 | + - Same as `-Pack` in `build-module.ps1`. |
| 47 | +- `generate-help.ps1` |
| 48 | + - Generates the Markdown documents for the modules into the `docs` folder. |
| 49 | + - Same as `-Docs` in `build-module.ps1`. |
| 50 | + - This process is now integrated into `build-module.ps1` automatically. To disable, use `-NoDocs` when running `build-module.ps1`. |
| 51 | +- `export-surface.ps1` |
| 52 | + - Generates Markdown documents for both the cmdlet surface and the model (class) surface of the module. |
| 53 | + - These files are placed into the `resources` folder. |
| 54 | + - Used for investigating the surface of your module. These are *not* documentation for distribution. |
| 55 | +- `check-dependencies.ps1` |
| 56 | + - Used in `run-module.ps1` and `test-module.ps1` to verify dependent modules are available to run those tasks. |
| 57 | + - It will download local (within the module's directory structure) versions of those modules as needed. |
| 58 | + - This script *does not* need to be ran by-hand. |
0 commit comments