IIS Virtual Directory : deploy to default virtual path "/"

Hello,
I have a problem when using the “IIS Deploy” step template with the “IIS Virtual Directory” deployment type.
My use case is to deploy a package in the “default” virtual directory of an existing website.
I don’t want to use custom directories or a named virtual directory.

In the step configuration, I declare a parent website name equals to “Backoffice” and a virtual path equals to “/”.

My applicationHost.config looks like this :

    <site name="Backoffice" id="8" serverAutoStart="true">
        <application path="/" applicationPool="Backoffice">
            <virtualDirectory path="/" physicalPath=C:\Octopus\Applications\Local Dev\Backoffice\15.0.6399_6" />
        </application>
        <bindings>
            <binding protocol="https" bindingInformation="*:443:devtest.backoffice.com" sslFlags="1" />
        </bindings>
    </site>

The deployment fails with this kind of logs :

    Making sure a Virtual Directory "/" is configured as a child of "Backoffice" at "C:\Octopus\Applications\Local Dev\Backoffice\15.0.6399_7"...

    "/" already exists in IIS and points to an unknown item which seems to be a directory. We will try to convert it to a Virtual Directory. If you used the Custom Installation Directory feature to target this path we recommend removing the Custom Installation Directory feature, instead allowing Octopus to unpack the files into the default location and update the Physical Path of the Virtual Directory on your behalf.

Attempt 1 of 5 failed: Le noeud parent ne possède pas d'enfants de type VirtualDirectory.

Error : New-Item : Le noeud parent ne possède pas d'enfants de type VirtualDirectory. 
Error : Nom du paramètre : path 
Error : Au caractère C:\Octopus\Applications\Local  
Error Dev\Backoffice\15.0.6399_7\Octopus.Features.IISWebSite_BeforePostDeploy.ps1:316 : 5 
Error : + ...             New-Item $fullPathToLastVirtualPathSegment -type VirtualD ... 
Error : +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Error :     + CategoryInfo          : InvalidArgument : (:) [New-Item], ArgumentException 
Error :     + FullyQualifiedErrorId : Le noeud parent ne possède pas d'enfants de type VirtualDirectory. 
Error : Nom du paramètre : path,Microsoft.PowerShell.Commands.NewItemCommand

Hi Benjamin,

Thanks for getting in touch!

I may have mis-understood what you’re aiming for, but I’m guessing that you want something like this:
06%20pm

If that’s what you’re after then I would recommend changing your IIS Deployment Step’s deployment type to be an IIS Web Site (like below)

You can then specify the existing site and it will deploy as my image shows above.

Please let me know if I’ve misunderstood your requirement,

Regards,
Alex

Hi Alex,
Thanks for your quick reply :slight_smile:
Well, I have indeed tried the IIS Web Site deployment type.

My problem is that we would prefer not to put the binding details of our websites in Octopus, but in a separate tool.
Thus the Web site deployment type is not an option, and I don’t see how to deploy on the default web site with the other types of deployment.
I’m wondering if I’m suggesting a feature here?

Benjamin

Hi Alex,
I must ask again, is it possible to do a IIS deployment with these 2 requirements with the current version of Octopus ?

  • deploy a package for a IIS website to the default location “/” (no custom directories)
  • do not declare or change any binding details of a pre-existing configuration (just change the virtual directory XML element in the applicationHost.config file).

Thanks again,
Benjamin

Hi Benjamin,

Thanks for you patience!

At this stage it isn’t possible. Octopus is designed to be the source of truth for your deployments which is why we will overwrite the bindings if they haven’t been supplied via Octopus. This is something that we are considering changing, however it’s not on any of our teams boards for active consideration and won’t be for some time I would guess.

Sorry I don’t have better news for you,

Regards,
Alex

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.