Develop Reference

Executing powershell script through c# throws "<comment> is not recognized as the name of a cmdlet" exception

I am using .Net 4.6.1 for a Winform application.
I neet to execute some command to configure user settings through powershell.
The powershell reference that I used is under C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0, so (I guess) its version is 3.0.
I use following to execute powershell command:
System.Management.Automation.PowerShell shell = System.Management.Automation.PowerShell.Create();
shell.AddScript("Get-LocalUser -Verbose");
then check
shell.Streams.Error[0].Exception;
and see following error:
The term 'Get-LocalUser' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I also tried executing the command through a powershell file like:
var psi = new ProcessStartInfo();
psi.CreateNoWindow = false;
psi.RedirectStandardError = true;
psi.UseShellExecute = false;
psi.RedirectStandardOutput = true;
psi.Verb = "runas";
psi.FileName = #"powershell.exe";
psi.Arguments = $" -File \"<path-to-file>\\MyScript.ps1\"";
try
{
Process proc = new Process();
proc.StartInfo = psi;
proc.Start();
string f = proc.StandardError.ReadToEnd();
proc.WaitForExit();
exitCode = proc.ExitCode;
}
But I got the same error.
How can I call a powershell script or powershell within c#?
EDIT: it turns out to be 32-64 bit issue. When I switched to x64, it worked just fine.

You should ensure you compile your C# code to target x64 (i.e. 64-bit) as most PowerShell modules will only work in 64-bit mode. If your C# code runs in 32-bit mode, it will invoke a 32-bit PowerShell environment, which will cause problems.

I had the similar experience and succeeded only after changing ExecutionPolicy. The error was equal, but all the details seemed fine.
PS 7.1.3, Microsoft.Powershell.SDK.
Use this:
PowerShell.Create().AddCommand("Set-ExecutionPolicy")
.AddParameter("-ExecutionPolicy", "Bypass")
.Invoke();
Run this code once before doing anything with the PowerShell.

Cannot launch .exe with another .exe

I wrote a program to get rid of unexpected errors like NULLs or zeros in .xml file after crash but the "restart" part of code isn't working. It's all good when I run the code in Visual Studio Code but when I use .exe file from dotnet publish function the program just crashes.
I've already tried setting UAC at level 0, UseShellExecute true/false, System.Diagnostics.Process.Start();, running as administrator.
static string exeAdress = #"C:\Program Files (x86)\NaturalPoint\SmartNav\SmartNAV.exe";
// Process.Start(exeAdress); // this isn't working either
Process p = new Process();
p.StartInfo.FileName = exeAdress;
p.StartInfo.UserName = "User";
p.StartInfo.Domain = "Domain";
p.StartInfo.UseShellExecute = true;
p.StartInfo.CreateNoWindow = false;
Actual output is throwing exception but I expect to run the exe without errors:
Unhandled Exception: System.ComponentModel.Win32Exception: The requested operation requires elevation
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)

You need to run your main application as administrator (with elevated permission).
If you can run your application with elevated user then you do not need to supply
p.StartInfo.UserName = "User";
p.StartInfo.Domain = "Domain";
parameters.

Git for windows stops working after "verify bundle" inside a process

Using .NET4 on Microsoft Visual Studio 2015
I have a function to validate bundle files. The Git command is running inside a process, like so:
public VerifyBundle(String bundlePath, String repositoryPath){
Directory.SetCurrentDirectory(repositoryPath);
Process p = new Process
{
//set process configuration
StartInfo = new ProcessStartInfo
{
UseShellExecute = false,
FileName = "cmd.exe",
RedirectStandardInput = true,
RedirectStandardOutput = true,
RedirectStandardError = true,
WorkingDirectory = path,
Arguments = "/C git bundle verify " + bundlePath,
WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden
}
};
p.Start();
string output = p.StandardOutput.ReadToEnd();
}
Whenever the .bundle file is not valid, right after the p.Start, Git stops, and opens a popup saying: "Git for windows stopped working".
Why is it breaking GIT during the process? What can I do to intercept this error and avoid disrupting my application during run time?
EDIT: Running the command manually on Git Bash against the same file outputs
Segmentation Error

It seems to be a bug with the mingw version of Git for Windows, it does not happen with Cygwin's version.
If possible use Cygwin's version although it's an earlier version of git as it does not have this issue.

System.diagnostics.process.start -System.ComponentModel.Win32Exception

This is my code block:
Process myProcess = new Process();
myProcess.StartInfo.FileName = fullpath;
myProcess.StartInfo.Arguments = " " + strNewFilePath;
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.RedirectStandardOutput = true;
myProcess.Start();
I am running an exe file using the System.diagnostics.process and i am keep getting this error:
System.ComponentModel.Win32Exception (0x80004005): The application has
failed to start because its side-by-side configuration is incorrect
The machine i am running this on is x64.
Googled it for a couple of hours, not much info on this. Any ideas?

Which application are you trying to run? Is it a 32-bit or 64-bit app?
You can check the event viewer Application log to figure out more information about this error.
If it due to some VC runtime then you can install the appropriate x86/x64 VCredist package (2005/2008/2010/2013) and see if it works for the application that you are trying to launch.

process.start: new process has different files rights then the parent, why?

i'm starting a child application from my main process with the following code:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = DestinationNameEXE;
startInfo.WorkingDirectory = Toolbox.AssemblyDirectory;
startInfo.UseShellExecute = true;
startInfo.Arguments =
binParameter + #" """ + _BINPath + #" """
+ tmpParameter + #" """ + binFolder_ForExtration + #" """;
Process.Start(startInfo);
before i do this i check if the process has write rights in the binFolder_ForExtration and _BInPath with following code (source) and a simple write file check:
try
{
using (File.Create(tmpfile)) { }
File.Delete(tmpfile);
createFilesAllow = true;
}
catch
{
createFilesAllow = false;
}
in the main process i can write & create files. also the function HasWritePermissionOnDir returns true.
in the new process i'm doing the same test, but in this case i got from HasWritePermissionOnDir true, but if i try to create a file, i got an exception. the new process has the rights to change existing files.
how can this be? what i'm doing wrong?
how can the new process have less rights then the first process?
i don't change the user context.
i' have also tested to start the process with ProcessAsUser.Launch (source) but without any change. the new process dond't have the right to create new files in the given folder.
if i start the process with elevated rights:
startInfo.Verb = "runas";
everything works finde. the new process can write, create and change files in the given folder.
thx for any help
Update:
i'm testing on a windows 7 x86
the main process is compiled with target x86 and .Net 4.5. its a dll called from a vb6 application
the user i'm testing with has admin rights (but it's not the user administrator). the main process is started with normal rights settings (not elevated rights)
the new process is compiled with target any CPU and .Net 4.5.
since i require access to Process.GetProcesses in the new process it should be compiled as any CPU to be used on x86 and x64 systems (as far as i know)
currently all folder tests and occured errors happend in the folder *c:\Program Files (x86)\appname\BIN*. in the code i'm using full path and test the correctness of the path with direcotry.exist() bevore any execution.