Custom path Deploy and Undeploy fails when installation path does not end with application name

[navaneetkgd]

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.

[navaneetkgd]

@vercellone @twinpiloot Could you please look into it. It would be helpful if this is implemented.

[twinpiloot]

Hi navaneetkgd. I agree with you that the behaviour is not consistent. However, if we would implement your suggestion, existing pipelines might break for cases where Destination is nonempty.

But you could try to include the version number in the Name parameter, for example "Application for BizTalk 1.0.0\1.0".
Please let us know if this solves your problem.

[twinpiloot]

I ran into the same problem at another customer who uses a different path, so I decided to implement this suggestion. To avoid a breaking change i've incremented the major number. This means that you have to select version 2 of the tasks to use this functionality.

[navaneetkgd]

I ran into the same problem at another customer who uses a different path, so I decided to implement this suggestion. To avoid a breaking change i've incremented the major number. This means that you have to select version 2 of the tasks to use this functionality.

But i see that version 2 is still not released, in Release pipeline i can see only version 1 tasks. Can you please help on this.

[twinpiloot]

Until the PR has been approved, the only option is to take the PowerShell scripts from my fork and use those.