Referencing external DLLs in standalone C# script

I’m looking at using a standalone C# script (i.e. using the ScriptCS integration) to run some custom actions during my deployment. The actions I want to perform are related to provisioning some Azure resources through the Azure SDK. (The specific resources I want to provision are not possible to provision through the Azure PowerShell cmdlets yet, hence me thinking a C# script might be a good option.)

In order to do this, I would need to reference out to the Azure SDK libraries. These are in NuGet, and I know that currently ScriptCS doesn’t allow NuGet references.

My question is: is there another way for me to reference external DLLs from my Octopus C# standalone script? Or am I limited to just referencing assemblies that are in the GAC of the machine executing the script?

Hi there,

Thanks for reaching out! In the ticket below Mark S. shows how to reference libraries from C# scripts.

That said, have you considered using Azure Resource Templates instead of going the C# way? They are quite easy to use, and fully supported by Octopus. You basically create a JSON template of the Azure resource you want to create, then tell Octopus to execute that template and its done. It does have a learning curve, but it’ll be a handy skill, as its the way things are going to work with azure provisioning going forward.

Info about our support for ART:


Thanks for the reply Dalmiro!

I did look into using ARTs but my initial check indicated that I couldn’t achieve what i need to achieve using them (create Azure Scheduler jobs, unless they already exist, in which case don’t overwrite the existing ones). I will look into this a bit more though as I agree it’s good to be on top of the ARM approach.

Also thanks for the info on referencing assemblies - that’s exactly what I was wondering. I had searched through the forums but obviously not with the right keywords!

In my experience ART is quite an undocumented feature. At the begining you basically had to download other people’s templates and tweak your way around them.

But that changed when MS introduced the Template Export featyre. Now the best way to learn if something can be done with ART is to first create the resource from the Azure portal, and then export it as a template to reverse-engineer-learn how the JSON is supposed to look like.

Hope that tip helps

Thanks for the tip - definitely useful! I’ll check it out.