Do PowerShell scripts run under Mono?
I would like to run them on a Mac.
There is an open source version of PowerShell called Pash designed for Mono. It is not complete, but may be able to do what you need:
http://pash.sourceforge.net/ (this project has not been active for quite some time)
Checkout the re-start at: Pash-Project on GitHub.
Powershell has now been open-sourced and is available here.
As of right now it is V6.0 alpha. I've been running it on OS X for a lot of file operations and it has been working very well.
Note that you may need to install .Net Core to get Powershell to behave properly. Also note that system.management.automation.runspaces works right out of the box (for runspacepools).
The powershell.exe stub is actually a native win32 program, not a managed assembly. It may be possible in the future to host the System.Management.Automation assembly in Mono, but I'm fairly sure it doesn't work at the moment.
Related
My company has a .NET Powershell module, written in C# to allow advanced users to automate tasks in our product. Currently it targets Powershell 5 using .NET 4.6.1. We would like to allow customers using other operating systems to use it as well, and as it has no OS-specific code, porting it was straightforward.
However, I cannot find documentation on a debugging workflow that should be followed. In standard .NET Powershell, this was quite simple and required a one-time setup procedure:
Configure the debug executable to be the Powershell path
Set debug arguments to be a short script that loads the module and if appropriate, executes the function that is being tested.
Hit F5
However, this doesn't work for Powershell Core. Because the project depends on NuGet packages, the module registration fails with a dependency error. I was able to figure out another workflow but it's a bit more obtuse:
Navigate to the project directory
Execute dotnet publish -f netstandard2.0 -c debug
Execute Import-Module ./bin/Debug/netstandard2.0/publish/MyModule.dll
Execute $pid to find the PID
Attach to the PID via Attach to Process in Visual Studio
This works and I have debugged a few issues with this method, but it's not the most pleasant or efficient way to do it. I believe that there must be a better way that is just not well documented.
I originally came up with a script based approach that you can see in this post's history, but what I didn't know at the time was the CopyLocalLockFileAssemblies property which makes the debug directory look like how it used to look when working on .NET Framework. You just need to add this to your .csproj in a <PropertyGroup>:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then, the debugging setup is just the same as any other .NET module loaded into a third party application:
Right click on your Powershell module project and click properties
Select Debug
Set Launch to Executable
Executable: C:\Program Files\PowerShell\6\pwsh.exe
Arguments: -NoExit -Command "Import-Module C:\dev\my-module\bin\Debug\netstandard2.0\my-module.dll"
Set your module as the startup project
Hit F5 to begin debugging.
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 need to know can I use PowerShell to burn ISO file on windows XP without any other addition software like MagicISO or others? I mean .NET framework is on top of Windows XP.
So if it is possible, then I need to know which commands allows me to do such a job?
Especially I need a command, not a whole script.
It appears this link: Burning and Erasing CD/DVD/Blu-ray Media with C# and IMAPI2 has sample code. It also has a link to the Update required to use this API on XP. Overall, it appears that a SHIM is required and it's all done using a an interop library whose source is included at the referenced link.
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