fix: address sql assembly conflict when creating clean database

[warlof]

❔What, Why & How

This is a workaround for issue #4051
It appears there is an assemblies conflict caused by usage of Invoke-SqlCmd for SMO which prevent container with clean database to be properly created.

$parameters = @{
    containerName = "myContainer"
    licenseFile = "$($pwd)\BC270.bclicense"
    copyTables = @("Add-in", "Report Layout", "Style Sheet")
    Credential = (Get-Credential)
    shortcuts = "None"
    auth = "NavUserPassword"
    artifactUrl = (Get-BcArtifactUrl -type Sandbox -Country fr -version 27)
    useCleanDatabase = $true
    multitenant = $true
    EnableTaskScheduler = $false
    accept_eula = $true
    AdditionalParameters = @("-e defaultTenantHasAllowAppDatabaseWrite=Y")
    isolation = "process"
    useNewDatabase = $true
}

New-BcContainer @parameters

Symptom
When executing Export-NAVApplication Business Central cmdlet, the following exception happens:

Could not load type 'Microsoft.SqlServer.Management.Common.TransferException' (caused by legacy loaded assemblies in upper stack)

Diagnose

However, when commenting the following section, the container creation is completing successfully :

navcontainerhelper/ContainerHandling/New-NavContainer.ps1

Lines 2313 to 2320 in 2171cde

	Export-NAVApplication -DatabaseServer $DatabaseServer -DatabaseInstance $DatabaseInstance -DatabaseName "tenant" -DestinationDatabaseName $databaseName -Force -ServiceAccount 'NT AUTHORITY\SYSTEM' | Out-Null
	Write-Host "Removing Application from tenant"
	Remove-NAVApplication -DatabaseServer $DatabaseServer -DatabaseInstance $DatabaseInstance -DatabaseName "tenant" -Force | Out-Null
	Set-NAVServerConfiguration -ServerInstance $ServerInstance -KeyName "Multitenant" -KeyValue "true" -ApplyTo ConfigFile
	Set-NavserverInstance -ServerInstance $serverInstance -start
	}
	$allowAppDatabaseWrite = ($additionalparameters | Where-Object { $_ -like "*defaultTenantHasAllowAppDatabaseWrite=Y" }) -ne $null
	New-BcContainerTenant -containerName $containerName -tenantId default -allowAppDatabaseWrite:$allowAppDatabaseWrite

Running the following commands afterwhile does not throw the exception :

Invoke-ScriptInBCContainer -containerName $containerName -scriptblock {
    $customConfigFile = Join-Path (Get-Item "C:\Program Files\Microsoft Dynamics NAV\*\Service").FullName "CustomSettings.config"
    [xml]$customConfig = [System.IO.File]::ReadAllText($customConfigFile)
    $databaseServer = $customConfig.SelectSingleNode("//appSettings/add[@key='DatabaseServer']").Value
    $databaseInstance = $customConfig.SelectSingleNode("//appSettings/add[@key='DatabaseInstance']").Value
    $databaseName = $customConfig.SelectSingleNode("//appSettings/add[@key='DatabaseName']").Value

    Write-Host "Exporting NAV Application..."
    Export-NAVApplication -DatabaseServer $DatabaseServer -DatabaseInstance $DatabaseInstance -DatabaseName "tenant" -DestinationDatabaseName $databaseName -Force -ServiceAccount 'NT AUTHORITY\SYSTEM' | Out-Null
    Write-Host "Removing Application from tenant"
    Remove-NAVApplication -DatabaseServer $DatabaseServer -DatabaseInstance $DatabaseInstance -DatabaseName "tenant" -Force | Out-Null
}

The exact same behavior occures when upper commands are executed afterwhile using docker exec -it {containerName} powershell

Resulting Hotfix

Invoke Remove-BcContainerSession is ensuring used session is clean of any previously loaded assemblies - which prevent the exception to happen.

Related to issue: #4051

✅ Checklist

• Add tests (Tests / LinuxTests)
• Update ReleaseNotes.txt
• Add telemetry

[mazhelez]

@warlof Thank you for your contribution! Can you please add release notes as well?

[warlof]

@warlof Thank you for your contribution! Can you please add release notes as well?

@mazhelez done
I know the module is now legacy, but maybe it can be usefull to add a bit of guidelines regarding contribution ?
It could help to keep changelog consistency :)