I wanted to use Windows Task Scheduler to create a small XML file, which is written to a disk directory tied to a BizTalk receive location. Receipt of a file starts an orchestration, which I wanted to schedule to run at a certain time each day. I used to do this kind of thing in VBScript, but decided to try PowerShell. The file needed the current date substituted as the value for an XML element.

# Name: FlightStats_Create_Daily_Jumpstart_File.ps1
# Author: Neal Walters
# Date: 01/15/2013
# Purpose: Allow <b>task scheduler</b> to create a small XML file to trigger a 
#          <i>BizTalk</i> orchestration to load flight schedule from FlightStats 
#          web service

#$today = (Get-Date)     
#The above date is not formatted the way I wanted for XML, so used .NET ToString below
$xmlDate = (Get-Date).ToString("yyyy-MM-dd")

#Create the XML Template
$xmlTemplate = @'

$xmlTemplate = $xmlTemplate -replace "&amp;FlightOriginationDate", $xmlDate

#Root File Path
$filePath = "d:FileDrop/FlightStats/FlightStatsSchedImportJumpstart"

#Create XML Object and load in the template

$xml = New-Object xml

#save XML document

PowerShell Alternative – C# Script

You might want to run a similar program in C# instead of PowerShell and instead of VB/Script. But maybe you don’t want to maintain and deploy an .EXE. If so, consider C# Script http://www.csscript.net. It basically allows you to write C# “scripts”, i.e. C# code that can be stored and executed from a text file.

Why might you want to try C# Script instead?

1) Sometimes you need to change the output path, and it’s easier to just open the code and change it with “Notepad” or your favorite editor (such as NotePad_++). C# Script is a .EXE that you run, that reads your C# Script, parses it, compiles it (using reflection), then executes it. An “Admin” type could open the script, modify and change it, without having to check out the code from your source control system, recompile, put  it through Quality Assurance (QA), etc…  NOTE: I still recommend you check your scripts in your source control.

2) You might be 100% fluent with C#, and 10% comfortable with PowerShell or VB/Script.  You might was well code the language you know, rather than then go through the pain of learning a new language.