2

What is the best way to declare input variables that we want to use in a script?

As of now I either declare all the needed variables above the script or create a separate VariableDeclaration.ps1 and dot-source it in the main script.

Is there a better way to get this done?

Reason I want to do this is because I want to make it easy for my peers to use the script without having much knowledge of scripting. They can easily edit the variables defined in a separate file (maybe INI or XML) without touching the main script.

Any suggestions?

Variables declaration sample:

#Customer_details
$CustomerID = '100'
$CustomerName = "ABCorp"
$vCenterName = "vCenter.ABCorp.com"
$vCenterUserName = "administrator@vsphere.local"
$vCenterPassword = ConvertTo-SecureString -String "ABCorp123" -AsPlainText -Force;
$CustomerPODLocation = "VW1"
$DatacenterName = "ABCorpDC"
$ClusterName = "ABCorpcluster"
$InfraResourcePoolName = $CustomerID + "-" + $CustomerName + "-" + "Infrastructure"
$FolderName = $CustomerID + "-" + $CustomerName
$ConnectionType = "S2S"
$VLANID = '237'
$PortGroupName = $ConnectionType  + "-" + $CustomerID + "-" + $CustomerName + "-" + $VLANID
$NumberofPorts = '1024'
Ansgar Wiechers
  • 193,178
  • 25
  • 254
  • 328
Javed Eqbal
  • 63
  • 1
  • 2
  • 11
  • `Best` is subjective. For whom? Do they change it often? Are there any problems currently? – wOxxOm Jan 31 '17 at 09:46
  • Yes , peers need to change it every time they run @wOxxOm : The problem now is that the variable are defined in the main script file so that feels like unsafe for the main coding part . I don't want any unintended person to make any changes there . An example/sample would be a good help – Javed Eqbal Jan 31 '17 at 10:03
  • Well, for some people an Excel file might be much better. Quite a plausible option I'd say. – wOxxOm Jan 31 '17 at 10:08

1 Answers1

0

The "best way" is quite subjective. It really depends on what you want to achieve and who will be editing the file. Dot-sourcing a .ps1 file basically means that you're executing that script (in the current context instead of a child context like regular execution would). Which is required for your sample file, because it contains not only data, but also code (ConvertTo-SecureString, concatenation operations).

Having code in a configuration file may prove problematic, because anyone who is able to edit the file could put arbitrary code in it. Other formats don't have this disadvantage, but might require additional code for parsing (INI) or are more difficult to edit for humans (XML).

Perhaps the best compromise is to use a flat file with key=value entries and parse it via ConvertFrom-StringData:

$config = Get-Content 'C:\path\to\config.txt' -Raw | ConvertFrom-StringData

That will create a hashtable from the key/value pairs in the config file. The file format is similar to INI, but not quite the same (no sections allowed, comments start with # instead of ;).

Configurations files aren't the best place for all kind of data, though. Normally you'd put static information in a configuration file, and make information that is bound to change frequently a parameter to the script.

Example:

config.ps1:

$foo = 'something'   # static information, unlikely to change between script runs
...

script.ps1:

[CmdletBinding()]
Param(
  # required value that is likely to change between script runs
  [Parameter(Mandatory=$true)]
  [string]$Bar,

  # default value that works most of the time, but which you want to
  # be able to override on the fly
  [Parameter(Mandatory=$false)]
  [int]$Baz = 42,

  ...
)

# read static configuration
. .\config.ps1

...

Note that it's usually bad practice to store plaintext credentials in a file. If your scripts are intended for interactive use you may want to consider prompting for credentials instead of putting them in a file.

Community
  • 1
  • 1
Ansgar Wiechers
  • 193,178
  • 25
  • 254
  • 328