Is there any difference between running a Powershell script:
From the command line powershell.exe -File my_scipt.ps1
From Powershell ISE (Open the script in the editor and press the green play button to run)
From a Windows Powershell Host application?
And if there is a difference, is there a way in Powershell to check it?
The reason for asking this is that we are seeing one script have slightly different behaviour in these three environments, even though we had expected to see the same outcome. The behaviour is that a (3rd party non-public) .Net library we are using crashes in the second two environments, but works fine in the first one.
We have checked the obvious things, such as:
directory of the powershell process set the same (which we set via [System.IO.Directory]::SetCurrentDirectory($my_path) in the script)
Powershell and .Net version (confirmed via identical $PSVersionTable)
System path
My hope in asking this question is that there is some difference which we are unaware of, and that by identifying it we can resolve the crash we are seeing. I'd also be interested to hear of similar experiences from anyone here.
Related
we have application that needs to simply copy somefiles from source to destination and manipulate config files based on the environment. We use Jenkins for deployment. Since i am comfortable with C# i thought of writing simple console application (.exe ) and invoke that exe on post-deployment by passing some command line argument. and i think this would work.
But i see people are recommending power-shell for deployment. and i have used PS for other projects for deployment.
i just wanted to know what powershell can do that windows console application cannot do?
Since PowerShell could be wholly embedded (not really the right term but it works for this explanation) in C# , there's nothing you could do in PowerShell that couldn't also be achieved in C#.
You can also embed C# in PowerShell, but for various reasons you don't get exactly the same scope of functionality that you can with an .exe.
The point of using PowerShell has to do with the context of it being part of a deployment step.
A PowerShell command or script is more easily changed. A build process is not required.
Its contents are more readily visible and readable to someone who wants to understand the process.
The code written will (likely) be less verbose, further making it easier to understand, and for deployment steps it may be much more straightforward to do those steps in PowerShell (a single cmdlet may do what would be several (dozen) lines in C#).
I will try this again. I can only get my .exe to run on the computer which created it and select other ones. Even once a application has been built into an .exe is it necessary that the computer it is run on still has powershell studio? Right now the executable will only run on computers with powershell studio, I am not sure if it is because these other computers are lacking a library or something along those lines or if every computer that I want to run it needs powershell studio. This as I have asked around is actually an issue with other executables which have been made from powershell studio so the problem is not exclusive to my code, which if necessary I can show some of. However I think it is more of an issue with the settings in the .exe builder which is something I am very new to and do not fully understand what or if I need to get it to work properly.I currently have left all the settings in the builder as the default settings so I am sure it is something in there that needs to be looked at I am just at a loss as for what.
Not a problem, just recompile it targeting the lowest common denominator. If you are on Powershell v3, but have some clients on v2, you'll need to recompile targeting v2.
To recompile, go into Sapien Studio and look for the drop down box on the ribbon, it probably says v3 - 64bit, change that to v2 -64bit and recompile. Good luck.
Alternatively you could install powershell v3 on those other machines and not need to recompile. That would also be the answer if you have to use a v3 cmdlet that simply does not exist in v2.
Noted: Future readers may also run into issues with x86/x64 bitness and system32 folder, if you are getting redirected into syswow64 sandbox, recompile 2 versions, one for 32bit, one for 64.
I have a PowerShell script that orchestrates a deployment to servers all over the place, but don't fear, it never gets past line 2.
Its the same setup on two project build configurations. However, while it works on one, it fails immediately on another when performing a very early check for a required component.
The script runs a Get-Command New-SshSession and checks the output to see if that cmdlet is available, whether the SSH module is setup.
Considering that the same script runs under the same .. I've just worked it out. I'm going to continue on a post an answer!
Anyway, considering the script path is the same, the params are almost the same, how can it fail on one and not on another?
Luke
Have you checked the x86|x64 combobox for the build step is the same for both? Otherwise PowerShell will run from SysWow64 which has a different modules folder than the 'normal' 64-bit version under System32.
Good luck,
Luke
I want to run some system commands (to fix things) before running an executable. I have a reasonably locked down (work) Windows XP system and so can't change what a shortcut points to. For my users' convenience, I must keep the same shortcut. However, I am able to swap out the .exe (renaming) and potentially replace it with another .exe (of the same name) which runs my system commands and then runs the original .exe.
What would be the easiest and quickest language/compiler to do this in? Previously, I've done this sort of thing in C (and tried it today in Python using py2exe without much success). Preferably free solutions.
Visual C# 2008 Express Edition is
free
comes with a compiler
outputs exes
C# is a good choice if you have C
experience
.net currently is the "canonical"
Windows platform
We were just today discussing it, so I went on a little search but found nothing, zip, nada.
What is the future of ms's cmd shell? Do they intend to replace it completely with powershell in the future versions of windows, or just ship powershell as a parallel alternative ?
Does anyone have any links, articles, ... whatever regarding the above mentioned, cause I haven't been able to mind ms's stand regarding.
The latest build of Windows 7 has the two shells separately. I believe they won't replace the good-ol' cmd.exe. They need it mainly for compatibility reasons. A lot of programs call cmd /c, and replicating the exact same mechanism for powershell would be a duplication of effort. So, I suppose the cmd.exe remains.
cmd.exe is not going anywhere (it's far too widely used).
However, I don't think you'll be seeing any enhancements to it (not that they've been burning through them anyway).
Powershell is extremely good at doing complex tasks. However it is harder to learn and it runs much, much slower.
CMD will remain because you can run batch files and command line ops EXTREMELY quickly. Additionally it is extremely inexpensive to pop up a command shell and execute a command.
Imagine how many login scripts would break if they removed cmd.exe? Even if Powershell could run all cmd commands seamlessly (which it can't), login scripts running under Powershell would be far too slow during user login, as you would need to wait while .NET loaded up as well.
I once heard of a Citrix Admin who converted his login scripts to Powershell and then quickly realised that this was a bad idea.