vercellone / vsts-btdf-tasks Goto Github PK

If I have the Destination field empty in the deploy task it says it will default to Program Files(x86) but it goes to the artifact directory. See error message below:

2020-02-14T08:16:08.0510711Z ##[error] BTDF application 'Tools Common' not found at E:\Agent\_work\r3\a\Tools Common. Deploy skipped.

Hi,

MSI Install task has the option to install the MSI to custom path using Destination parameter which works very well.

But after MSI install BTDFDeploy task dose not have custom path parameter and it always looks for Programfiles environment variable and sets ApplicationPath.

So the deploy task fails since it is not able to find artifacts which is installed in custom path.
Similarly the BTDFUndeploy also always looks for Programfiles folder.

I just saw the code in GitHub and found that BTDFDeploy and BTDFUndeploy does not have the parameter to support Custom path. But the Install task has this option.
I think it requires small changes in code as only new parameter Destination can be added and checked before setting the Application path variable.

#$Destination is the custom path for installation
if ([string]::IsNullOrWhiteSpace($Destination)) {
$ApplicationPath = Join-Path $ProgramFiles $Name
}else{
$ApplicationPath = Join-Path $Destination $Name
}

Could you please include this option so that it would be easy to deploy the BizTalk application to custom path.

Thank you

Task '__________' (n.n.n) is using deprecated task execution handler. The task should use the supported task-lib: https://aka.ms/tasklib

Evidently, this requires changing execution from PowerShell to PowerShell3 in the task.json and inclusion of ./ps_modules/VstsTaskSdk with every task.

@trabalder requested related PR #3 mid 2018, and this issue was brought to my attention again by Henrik Hammar via marketplace Q&A 2/13/2020.

This extension unconditionally appends '_settings.xml' to the configured Environment input value. Instead, it should allow the user to specify the full environment settings file name or otherwise override this behavior.

In the last bug i raised(#5) the custom path installation was fixed. But i observed one more issue related to this.
For ex installation folder is F:\applications\applicationname\1.0 (when path ends with other than application name)

MSI installation task works fine but deploy and undeploy fails. Here Destination parameter was sent as F:\applications\applicationname\1.0 from the task.(This task powershell script Install-BTDFApplication.ps1 does not have the logic of appending ApplicationName to Destination when we specify Destination parameter) and install msi works fine.

But in UnDeploy-BTDFApplication.ps1 and Deploy-BTDFApplication.ps1 there is code to append destination ($Destination) and application name ($Name). So when we specify the parameter Destination from task as F:\applications\ the $ApplicationPath will be set to F:\applications\applicationname. So the folder 1.0 will not be set by passing any value to destination.

I think this can be fixed by the same way how MSI install task is implemented. User can send complete installation path always to both deploy and undeploy task when user wants custom install path.
Deploy-BTDFApplication.ps1 and UnDeploy-BTDFApplication.ps1 code can be modified to below approach. This won't cause any issues to user who use ProgramFiles as installation folder(incase of Destination is empty)

if (-Not $Destination) {
$Destination = $ProgramFiles $Name
}
$ApplicationPath = $Destination

So if this is implemented then user can install application to any custom path which will be very helpful.

We have one artifact with a lot of applications with different names and folders.

We would like to use $(System.ArtifactsDirectory)*\Package name.msi. as the path.
Right now I have solved it by doing a powershell script before and saving it to a variable.

$path = Get-ChildItem -Path "E:\Agent\_work\r3\a\**" -Filter "Package Name*.msi" -Recurse -ErrorAction SilentlyContinue -Force

Write-Output ("##vso[task.setvariable variable=MSIPath;]$path")

Requires a different extension id.

Refer to https://stackoverflow.com/questions/56029313/how-to-test-new-azure-devops-extension-version-before-publishing-it-for-everyone for guidance. Since I am using appveyor instead of azdo for this project I'll roll my own scripts as needed.

Before:
$args = [string[]]@(
"/x$InstallGuid"
"/qn"

Needs to be After:
$args = [string[]]@(
"/x $InstallGuid"
"/qn"

# AssociatedInstances include Routing Failure Reports which have no messages to save $AssociatedInstances = Get-WmiObject MSBTS_ServiceInstance -Namespace 'root\MicrosoftBizTalkServer' -Filter 'ServiceClass=1 or ServiceClass=4 or ServiceClass=64' $ServiceInstances,$AssociatedInstances | ForEach-Object { try { $InstanceId = $_.InstanceId [void]$_.Terminate() Write-Host ("Instance termination [{0}]" -f $InstanceId,$_.Exception.Message) } catch { Write-Host ("##vso[task.logissue type=warning;] Instance termination [{0}] FAILED: {1}" -f $InstanceId,$_.Exception.Message) } }

$ServiceInstances and $AssociatedInstances gets the same messages and both is looped over making it try to Terminate the same messages twice and throws a warning.

The undeploy script does not allow for different management database names (alows uses BizTalkMgmtDb):

        $MgmtDBServer = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration' | Select-Object -ExpandProperty 'MgmtDBServer'
        $Catalog.ConnectionString = "SERVER=$MgmtDBServer;DATABASE=BizTalkMgmtDb;Integrated Security=SSPI"

Should pull the database name from the registry (like the Server Name)

        $MgmtDBServer = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration' | Select-Object -ExpandProperty 'MgmtDBServer'
        $MgmtDBName = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration' | Select-Object -ExpandProperty 'MgmtDBName'
        $Catalog.ConnectionString = "SERVER=$MgmtDBServer;DATABASE=$MgmtDBName;Integrated Security=SSPI"