MSDeploy (Right click -> Publish) but in Octopus


I’ve just started working with Octopus, and I really like it!
I’ve successfully deployed an application from our buildserver to the IIS on our own, local, hosting server.

However, in another project, we are deploying an ASP.NET project by right clicking the project and hitting publish. Is it possible to perform the same kind of publishing through Octopus, without installing a tentacle on the actual server it should be deployed to? I’m building the project with TeamCity, which then runs OctoPack, Create release and Deploy release. The problem is with the last step, deploy reploy. I don’t what to do here…

Installing a tentacle on the server I want to deploy to would be the easiest fix. However, this is not possible, as I can’t access the server to install the tentacle.

I’ve read about MSDeploy in Octopus but I’m not sure if this is what I’m looking for? I tried to set it up, but I’m getting (unrelated?) errors with it (such as “OperationStopped: No package steps found”).

Basically, I want to perform the same actions that occur when right clicking the project and hitting publish, through Octopus.

Any help pointing me in the correct direction is appreciated!

Hi Adam,

Thanks for getting in touch!

Publishing using the MSDeploy right-click option isn’t something I’ve run through myself so apologies if I’m asking basic questions.

When you perform this normally, is it a case that you supply the Publish URL and other details that appear in the MSDeploy step?

If so, then you should be able to do this by first adding a Deploy a Package step. You may need to install a tentacle to the Octopus Server or another local machine so that Octopus has somewhere to deploy the package to. Then, add the MSDeploy step and add the name of the first step into the Package Step Name field.

If the process that you follow when using the right-click option is completely different from what you see in the MSDeploy step, then the only other option would be to create a Powershell script that can execute the publish, and then run that in Octopus using a Run a Script step.


1 Like

Yes, the details in the MSDeploy step has (most of) the details that I specify when normally publishing.

I wasn’t aware that I had to manually deploy the package with the Deploy a Package step. It was a step in the right direction!

Looking at the source code, I can see that I’ve provided my details in the incorrect way. The MSDeploy step applied the publish url variable to an existing URL: https://$publishUrl/msdeploy.axd?site=$websiteName

I’m pretty sure that the publish step will work now. However, now I’m having some trouble with the Deploy a Package step. I want to transform my *.Staging.config files, but if one attribute isn’t found anywhere, it stops the deployment of the package. More specifically, my staging config has the following transform:

<compilation xdt:Transform="RemoveAttributes(debug,numRecompilesBeforeAppRestart)" />

This throws the following error in Octopus in the Deploy a Package step:

Argument ‘numRecompilesBeforeAppRestart’ did not match any attributes

Unfortunately, that is a limitation of the XML transform, if the attribute isn’t here, Octopus reports it as such.

There are two possible options to work around this.
The first would be to add a project variable Octopus.Action.Package.IgnoreConfigTransformationErrors with a value of True. This will allow the deployment to succeed, but may have the unintended side effect of hiding any other similar errors.

The other option would be to modify the transform file to add this value if it doesn’t exist, and then remove it.

<foo xdt:Transform="InsertIfMissing" />
<foo xdt:Transform="Remove" />


1 Like

As of now, we don’t use that attribute anyway, so I just commented it out.

I successfully deployed the site from the build server, through Octopus, with a slightly modified Web Deploy template. The script could connect to the site, but some files were locked, which hindered the deployment. I set the DoNotDelete option to false in the script, on the $syncOptions variable, as I didn’t have to delete those files anyway.

Without your pointer about the Deploy a Package step, I wouldn’t have succeeded with this, and for that I am grateful! Thank you. :smiley:

1 Like

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