Running an MSI - says path not found when it actually does

Hi,

I’m trying to deploy and install an MSI file as part of a server configuration deployment. I’m using the standard “Run Windows Installer” and passing it the correct path from the previous step. Whenever the step executes it errors with

Resolve-Path : Cannot find path 'C:\Octopus\Applications\International -  Stage\HTTP_Platform_Handler\1.2.0_6\httpPlatformHandler_amd64.msi' because it 
does not exist

Yet pasting the path into explorer on the target machine navigates to the path perfectly.

I’m aware the filename has spaces and have tried enclosing it in speech marks, but this has no effect. I even created a simple Powershell script that took a path parameter and it worked perfectly.

Does anyone have any idea why this isn’t working?

Hi Andy,

Thanks for getting in touch! Could you attach a full deployment log containing the error? It could be that the script is executing too early.

You could try using the “dir” command in your PowerShell script to print out the contents of the directory before you call the command.

http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

Paul

Hi Paul,

Thanks for the reply. Attached is the log as requested. I don’t think the script is executing too early as the log chronology matches the step order.

The Powershell script is the Run Windows Installer from the Octopus Deploy Library (the only difference is I commented out the Test-Path (which was failing because of the same problem).

Thanks in advance.

Cheers,

Andy

ServerTasks-5865.log.txt (15 KB)

Hi Andy,

Thanks for the reply. It looks correct to me. Could you change the step template to include:

$parentDirectory = [System.IO.Path]::GetDirectoryName($MsiFilePath)
clear
dir $parentDirectory

Just before the call to Resolve-Path $MsiFilePath?

It does look like everything is running in the right order, so all I can think of is that the directory structure on disk isn’t what we expect.

Also, do you have any virus scanning software running? Sometimes they detect files like MSI’s and temporarily hide/quarantine them - perhaps adding an exception could help.

Paul

Hi Paul,

Thanks for the prompt response. As you can see from the attached output, the file is indeed there! I really have no clue why it’s not working!

Cheers,

Andy

ServerTasks-5895.log.txt (15 KB)

Hi Andy,

In the log you attached, the file name appears to have a space before the file extension:

09:25:27   Info     |       Mode                LastWriteTime     Length Name
09:25:27   Info     |       ----                -------------     ------ ----
09:25:27   Info     |       -a---        26/01/2016     09:25     552960 httpPlatformHandler_amd64 .msi
                                                                                                  ^

Is this just a problem with the log file output or could the file name really have a space in it? I guess it would explain why it isn’t being found.

Paul Stovell

Hi Paul,

I hadn’t noticed the space at the end of the file name! It’s how the file came when it was downloaded from Microsoft. I guess it’s possible that the space is significant, but the file name is passed from a previous step template so I would have assumed that it should still handle it without any difficulty. There’s no manual intervention or user input as regards the file name. As an experiment, I’ll remove the space, rebuild the nuget package and see what happens. I’ll post back my findings here.

Cheers,

Andy

It was the space!! Bizarrely, removing the space from the installer made everything work.

Thanks for the spot and help, Paul! :slight_smile:

Cheers,

Andy