Adds support for triggering PowerShell scripts on build events in Visual Studio. Instead of using the Build Events of visual studio, this allows you to create PowerShell scripts that is called on different build steps.
Licensed using the MIT License.
Developed by Dan Händevik, Meriworks.
- Added BuildEventsRunnerDisable property
- Fixed paths to PowerShell to work better in vscode/mac
- Removed dll from nuget package
- Moved to azure pipelines
- Added support for Extension Variables
- Reduced build time by not executing PowerShell runner when no script exists for the current action
- Don't add default scripts in _msbuild folder if there are any ps1 files present
- Added support for Extension Modules
- Removed unused dll from nupkg file
- Removed scripts and readme from project
- Minor changes in nuspec, license and documentation
- Initial release
When the Meriworks.PowerShell.BuildEvents nuget package is referred to the project, it will scan the _msbuild folder for PowerShell scripts and execute them according to their name.
We support three actions that can be hooked into; Build, Compile and Publish.
To hook into an action, decide if you need to hook Before or After the action.
Name the script accordingly; ie. BeforeBuild.ps1 will be executed before the build action.
You can also specify a script that only will be triggered during a specific configuration by suffixing the configuration name to the script name. ie. AfterBuildRelease.ps1 will only be triggered after a release build.
The script is a standard PowerShell script (.ps1) that will be invoked in the build process.
In addition to the normal PowerShell environment, extensions and variables are available in the global scope. As per default the following variables are available.
- $solutionDir refers to the path to the solution folder.
- $projectDir refers to the path to the project folder.
- $targetPath is the path to the resulting output target that the project produces.
- $configuration is the name of the current build configuration
If you would like to add global variables that are available when running a build event, you can do this using an extension variable.
To make BuildEvents automatically import this variable you need to add the following to the csproj file (this will append the path to the module to the list of already added variables).
<PropertyGroup>
<BuildEventsRunnerVariables>$(BuildEventsRunnerVariables),myVariable=myValue</BuildEventsRunnerVariables>
</PropertyGroup>
You can then use this variable in your build script like below.
Note: No escape sequences for using , or = in the variable value is supported for now.
echo $myVariable
If you would like to add PowerShell modules to the scripts without the need to include them you can let the BuildEvents include them for you. To do that, you first need a module. In this example we store the module in the _msbuild folder but you can include any module you would like._
function Write-HelloWorld(){
Write-Host "Hello World!"
}
To make BuildEvents automatically import this module you need to add the following to the csproj file (this will append the path to the module to the list of already added modules).
<PropertyGroup>
<BuildEventsRunnerExtensions>$(BuildEventsRunnerExtensions),$(ProjectDir)_msbuild\ExampleModule.psm1</BuildEventsRunnerExtensions>
</PropertyGroup>
You can then invoke the functions in the module in any of the BuildEvents scripts, like the example script below.
Write-HelloWorld
If you would like to disable the BuildEventsRunner, you can add this property to a propertyGroup
<PropertyGroup>
<BuildEventsRunnerDisable>True</BuildEventsRunnerDisable>
</PropertyGroup>
or add it as a parameter to the msbuild argument list
/p:BuildEventsRunnerDisable=True