Calling .Net Assemblies from PowerBuilder Classic Win32 via PowerShell

Recently someone asked me how they could get the output from PBDOM used from a PowerBuilder Classic Win32 application formatted with white space as PBDOM doesn't include it.  I gave them a number of options, particularlyMSXML through OLE Automation or using a .Net class like XmlTextWriter.  Normally if you were going to try to access a .Net assembly from a PowerBuilder Classic Win32 application, you would do it via a COM Callable Wrapper.  However, for something this simple I thought there had to be a more lightweight way to accomplish it.  One particular lighterweight way that occurred to be would be to have the application launch a Windows PowerShell script that would then use the .Net class in question.  We're going to look at an example of how that's done.

The first thing we'll need is the PowerShell script to do the work. This is what I came up with (referenced as prettyprint.ps1 in the later code):

1. param(  
2.     [string]$filein,  
3.     [string]$fileout  
4. )  
5. [void][System.Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")  
6. [System.Xml.Linq.XDocument]::Load($filein).Save($fileout)  
7. # If running in the console, wait for input before closing.  
8. if ($Host.Name -eq "ConsoleHost")  
9. {   
10.     Write-Host "Press any key to continue..."  
11.     $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp") > $null  
12. }  

The script declares a couple of parameters (the input xml file and the output xml file).  It then loads the System.Xml.Linq .Net assembly via reflection.  Finally, we load the file and then write it back out again with white space.  The last few lines are just for debugging from a command line prompt, as it displays a "Press any key to continue..." prompt before closing the PowerShell process window.

To test it through a batch file, I used this:

1. @ECHO OFF  
2. SET ThisScriptsDirectory=%~dp0  
3. SET PowerShellScriptPath=%ThisScriptsDirectory%prettyprint.ps1  
4. SET SourceFile=%ThisScriptsDirectory%config.xml  
5. SET DestFile=%ThisScriptsDirectory%.config.new.xml  
6. %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' -filein '%SourceFile%' -fileout '%DestFile%'";  
7. pause  

The assumption here is that the batch file, the PowerShell script and the input xml file are all in the same directory.  I've got a pause statement in this script, so you actually get two "Press any key to continue..." prompts.  If it works properly, that's all you should see.  Otherwise you should see the error message from PowerShell or the batch file.

Once you know it's working, it's time to call it from PowerBuilder.  I'm going to cheat a bit in the following example.  I'm using the PowerScript Run function and have hard coded the location of the PowerShell executable.  In actual usage, you might query the operating system for the location of the SystemRoot, or use the ShellExecute, ShellExecuteEx orCreateProcess Windows API functions to invoke the process rather than Run.  Also note that the code assumes that the PowerShell script file is located in the same directory as the PowerBuilder Classic Win32 application.

1. int li_rc   
2. string ls_sourcepath  
3. string ls_sourcefile  
4. string ls_destpath  
5. string ls_destfile  
6. string ls_command  
7. string ls_directory  
8. ls_directory = GetCurrentDirectory()  
9. ls_command = 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "&'  
10. ls_command += " '" + ls_directory + "\prettyprint.ps1' "  
11. li_rc = GetFileOpenName ( "Select source file", ls_sourcepath, ls_sourcefile, "XML", "XML File (*.xml),*.xml" )  
12. IF li_rc <> 1 THEN Return  
13. ls_command += " -filein '" + ls_sourcepath + "' "  
14. li_rc = GetFileSaveName ( "Select destination file", ls_destpath, ls_destfile, "XML", "XML File (*.xml),*.xml" )  
15. IF li_rc <> 1 THEN Return  
16. ls_command += " -fileout '" + ls_destpath + "' "  
17. li_rc = Run ( ls_command )  

In this case, the application prompts the user to select an XML file to process and then provide a name for the "pretty" version of the XML to output.

Without the second argument to Run, you will see the PowerShell process window open momentarily.  If you were to continue to use the Run method, you can pass Minimized! as a second argument to that function to suppress the window.  In addition, the ShellExecute, ShellExecuteEx and CreateProcess Windows API functions have options to suppress the PowerShell process window from displaying.