Pester and DLL locking

Adding the discussion in case there's a better suggestion floating around.

If a module incorporates an assembly, DLL files containing the assembly are loaded and locked. DLL files cannot be unloaded without restarting PowerShell.

In Indented.Build I invoke module tests using the snippet at the bottom, where "IsAdministrator" is the usual role check. However, I'm not keen on the administrator requirement this introduces.

A possible alternative is to invoke pester via Start-Process. The downside to this approach is that it squashes any prettified output.

This issue does not apply when using a build server. A build is typically executed in a spawned session which is destroyed after the build. Repeated building is really a feature of working in a development environment.

Any thoughts?
```
$invokePester = {
param (
$buildInfo
)

Import-Module $buildInfo.ReleaseManifest -Global -ErrorAction Stop
$params = @{
Script = Join-Path $buildInfo.Source 'test'
CodeCoverage = $buildInfo.ReleaseRootModule
OutputFile = Join-Path $buildInfo.Output ('{0}.xml' -f $buildInfo.ModuleName)
PassThru = $true
}
Invoke-Pester @params
}
if ($buildInfo.IsAdministrator) {
$pester = Invoke-Command $invokePester -ArgumentList $buildInfo -ComputerName $env:COMPUTERNAME
} else {
$pester = & $invokePester $buildInfo
}

$path = Join-Path $buildInfo.Output 'pester-output.xml'
$pester | Export-CliXml $path
```

Commencez par l’invocation de test du module Indented.Build présentée dans l’issue, notamment Invoke-Pester, Invoke-Command et l’alternative Start-Process. Déterminez comment des builds de développement répétés peuvent éviter les fichiers DLL verrouillés sans nécessiter d’accès administrateur, tout en conservant une sortie Pester utile ; l’issue est terminée lorsque cette approche a été convenue et documentée ou implémentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.