Missing StartupServicesFile parameter needed to call Deploy-FabricApplication.ps1

I seem to have a spot of bother deploying SF packages via Octo where in the past it had worked flawlessly so I am reaching out for any guidance/help.

Ever since I’ve updated Visual Studio to 2022, it looks like Microsoft SF has now updated the package structure slightly where it now requires an extra argument (-StartupServicesFile) that is passed to Deploy-FabricApplication.ps1. This StartupServicesFile argument is suppose to point to an xml file within the StartupServiceParameters folder, and that appropriate environment version of the xml file contains parameters specifically for the services to use.

Because the StartUpServiceParameters argument not passed to the powershell, it resulted an SF Application created but no services created within it.

In octopus process Editor under “Deployment” I see various parameters like “Publish Profile File”, “Deploy Only”, etc and no “Startup Service Parameters” parameter to specify so that it can pass to the powershell script.

My question is… how do I add a new parameter (-StartupServicesFile) the process Editor ?


Hi @darren.tweedale,

Thanks for reaching out, and welcome to the Octopus Deploy community!

I’m sorry you’re running into this issue with your Service Fabric deployment process, but I’m happy to help investigate.

In doing some initial research I found that Microsoft recently released some updates around StartupServices.xml, and I’m wondering if this might be related to the issues you’re now seeing.

In order to shed some light on this, I’ve reached out to the appropriate internal team on our side and will let you know as soon as I have any updates.

Also, just so I can provide the team with a level of priority on this, can you let me know if you are able to work around this issue in any way, or is this completely blocking your deployment process?

Looking forward to hearing back, and thank you for your patience while our team takes a closer look at this.

Best regards,


Hi @darren.tweedale,

Our engineering team was able to take a look at this and confirmed this parameter cannot currently be set via the default step template, but it looks like you could potentially work around this by modifying the default script that is run via the Service Fabric step template to allow for the additional -StartupServicesFile parameter.

In taking a look at the script, it does provide some default instructions for swapping a custom script into the Service Fabric deployment process:

## If you want to customize the Azure deployment process, simply copy this script into
## your deployment package as DeployToServiceFabric.ps1. Octopus will invoke it instead of the default
## script.

Once you’ve modified the default script to meet your needs and have it configured to be included in your deployment package then this new parameter will be read in and things should work as expected.

Hopefully this helps get you unblocked, but let me know if I can be of any more assistance.



Great news, it did work after tweaking the DeployToServiceFabric.ps1 and it now pass the important startup service arguments correctly to “Publish-NewServiceFabricApplication”. Thanks for leading me to the right place!

To anyone needing this code fix, I forked that project and updated DeployAzureServiceFabricApplication.ps1. Not done a pull request yet. Can be viewed at
(added lines 97-98, 170-176, 208-214)

Couple of gotchas

  1. the PublishProfile*.xml files should have
<ApplicationParameterFile Path="..\ApplicationParameters\xxx.xml" />
<StartupServiceParameterFile Path="..\StartupServiceParameters\xxx.xml" />

(where xxx is the environment to use)

  1. I used “OctoSFPackage.target” script so it needs updating but you may have different method to pack your project. Either way, your packing routine should be coping the following files to nupkg
\Scripts\DeployToServiceFabric.ps1 to the root of package

Hope that helps anyone.

Big thanks for support to lead me the right place and quickly responded even during bank holiday weekend!

1 Like

Hi @darren.tweedale,

Awesome, I’m glad you were able to get this working, and also thanks for providing the additional details of your workaround to the community! :grin:

Hope you have a good rest of your week and happy deployments!


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