1. If you guys have known this all along then WHY does the builder NOT warn of ALL of these pit falls?
It is quite hard to guess what people know or don't know, so we go by feedback. If a warning is warranted, we add it.
2. Why does it NOT show the best solutions to us or at least a link to the most current stuff like the LINK you sent me?
The output of a command line tool really is not a place to educate users about best practices or coding examples. That's kind of what blogs are for nowadays
That is why we write them and publish them.
3. Why does the EXE build NOT have the ability to automatically switch the switches to your own suggested solution and inform me of the REQUIRED changes?
... (Do you want EVERYONE to report such things?)
Automatically implies always without fail and without user intervention. We learned the hard way that some things are best left to the human brain for processing
rather than applying a "we know best attitude". We do not switch your switches because the tool just makes an exe out of your script, it doesn't analyze your code.
If we add an automatic switch switcher, you or someone will find a case where it switches the wrong switch. Then you ask for a switch to turn off the automatic
switch switcher. The next guy will ask for a default switch to turn off the automatic switch switcher and ask for a switch to just turn warnings into errors so he
can manually switch his switches whenever he wants to switch them. So then I ask you, who switches the switches?
(Sorry, I REALLY REALLY could not resist that one.)
4. ALL command line parameters are strings and always were because the command line arguments are one big string from the OS to the application. Even in VBScript we had to, and still have to, have our own code for an argument to act like a switch.
Yes, all command line arguments are strings, they always have been.
As you can see in the above code the programmer can, or has to, convert the 'string' to a Logical value. Aliases can also be handled, as many as the programmer wants.
Agreed. I think I am missing a point here.
5. In the SAPIEN PowerShell Debugger we/you also pass the command line options as one BIG string and it also has to be properly interpreted. Can't you guys do the same thing inside the EXE file?
No
... What exactly are you calling from inside this EXE?
In the engines titled "SAPIEN PowerShell ..." the PowerShell engine provided by Microsoft though its defined API.
Why is this relevant?
... Does it just start the PowerShell.exe engine giving it the packaged scripts?
Depending on the engine you pick, yes or no.
The description part of the engine selector displays if a temporary file is used or not. Obviously an actual file means the original tool is used (powershell.exe, CScript.exe, WScript.exe etc.), if it says "In memory" the engine is used by means of an API.
... Or is it your own PowerShell libraries?
We do not have 'powershell libraries'.
... Why can't the parameters be passed just like the debugger gets them?
Because an exe is called with command line arguments, the communication with the debugger is different for more reasons than I want to list here.
