Pester and DLL locking

[indented-automation]

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

[gaelcolas]

btw, not ignoring this one... just no opinion on that... we're on the same page.
My current workaround is to not delete modules in my Clean function.

[indented-automation]

That's fine for modules dragged in to complete the build, but those aren't my problem. This exhibits only when building a module which contains a binary component (compiles something into a dll during build). The build is not repeatable unless the session is restarted if testing is executed in the same app domain.

[gaelcolas]

oh yeah good point!
I think building in fresh session is the way to go, but as you say the effort to get the formatting right is non-negligible (and probably out of scope here).
I feel like it'd be a good feature to re-display the Pester output based on, say, the NUnit XML.
So that you can re-view previous build output with greater UI than the XML file.
Is that something that could be easily plugged-in into pester?

[indented-automation]

It may be difficult to rebuild it based on nunit, but I doubt it's difficult to do so based on the passthru object. Certainly worth looking into (at least from my point of view :) I'll have a bit of a dig at time permits :)

…

On 27 April 2017 at 09:10, Gael ***@***.***> wrote: oh yeah good point! I think building in fresh session is the way to go, but as you say the effort to get the formatting right is non-negligible (and probably out of scope here). I feel like it'd be a good feature to re-display the Pester output based on, say, the NUnit XML. So that you can re-view past build output with greater UI. Is that something that could be easily plugged-in into pester? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMO6DhdujbKm_ycLR0fnvJvf8p9dxnJ6ks5r0E1ggaJpZM4NAJNu> .

[indented-automation]

I think I finally found a way to resolve this problem. It really should have occurred to me sooner.

I invoke my tests using Start-Job which has complete isolation so when it's done unfriendly dll's unlock quite happily.

[gaelcolas]

Actually, you mentioned it to me on slack (a while ago) :)
Just that it's relatively low-pri as:

1. on a build server it's not an issue
2. vscode killing and restarting a terminal very easily

I'll probably add this at some point... unless someone sends a PR before then 🙄