Develop Reference

Issue with create the subject certificate name

I want to create subject certificate name which contains "," like the image
Example
but always fails because "," is used to separated the contain of -n parameter like
“CA=CARoot,O=My Organization,OU=Dev,C=Denmark”
Anyone know how to add "," into certificate name? Much appreciate for your helping

In a Windows Command Prompt you can use a triple-double-quote to make a literal double quote in a quoted argument (from https://stackoverflow.com/a/15262019/6535399).
The X500 name parser uses commas as separators unless it's in a quoted string. So you need the -n value to be interpreted as OU="Hey, there", ....
So, you can do something like
> makecert.exe (etc) -n "OU="""Hey, there""", O=Hmm, CN="""Hello, Nurse!""""
or, to make the what-looks-like-a-quadruple-quote go away:
> makecert.exe (etc) -n "OU="""Hey, there""", O=Hmm, CN="""Hello, Nurse!""", C=US"

I tried your solution but It did not work, my command:
MakeCert.exe -r -pe -n "OU=(c) 2006 thawte Inc."""Hey, there""" - For authorized use only" -sv "c:\PlaneteersLtd_certificate\XIAMEN_IPRT_TECHNOLOGYLtd1.pvk‌​" -len 2048 "c:\PlaneteersLtd_certificate\XIAMEN_IPRT_TECHNOLOGYLtd1.cer‌​"
When I remove """Hey, there""", it create the cert file successfully
Example

How to know if error from dotnet build command with powershell

I want custom script when my dotnet build command failed.
How to get errors list or not success flag when the 'dotnet build' failed with errors compilation for example, or when 'dotnet test' failed, with powershell.
I want equivalent code
dotnet test
if (!$result.Successful) {
$errorMessage = ""
if ($result.Error -ne $null) {
$errorMessage = $result.Error.Message
}
Write-Host "##vso[task.logissue type=error;] error"
Write-Host "##vso[task.complete result=Failed;]"
Exit -1
}

You can merge the standard output and error streams with the > stream redirection operator, and then inspect the $LASTEXITCODE automatic variable to see if the call succeeded or not:
# Merge all streams into stdout
$result = dotnet test *>&1
# Evaluate success/failure
if($LASTEXITCODE -eq 0)
{
# Success
}
else
{
# Failed, you can reconstruct stderr strings with:
$ErrorString = $result -join [System.Environment]::NewLine
}

For me it worked by just using exec in PS.
exec { dotnet build $projectFile -o $targetDir -c Release }

command line arguments given to a C# program are parsed wrong

I wrote a little program, that has the following command line for example:
prog.exe -p -z "E:\temp.zip" -v "f:\" -r -o -s –c
prog.exe -p -z "E:\temp.zip" -v f:\ -r -o -s –c
prog.exe -p -z "E:\temp.zip" -v "f:\log" -r -o -s –c
This command line is being generated by another program that inserts the quotation marks around the file and path names automatically to prevent spaces being recognized as argument separators.
The first command line is then being parsed by the .Net framework as:
args {string[5]} string[]
[0] "-p" string
[1] "-z" string
[2] "f:\\temp.zip" string
[3] "-v" string
[4] "f:\" -r -o -s -c" string
But it should be ( the result from the second command line):
args {string[9]} string[]
[0] "-p" string
[1] "-z" string
[2] "f:\\temp.zip" string
[3] "-v" string
[4] "f:\\" string
[5] "-r" string
[6] "-o" string
[7] "-s" string
[8] "-c" string
A possible solution would be to check the file and path names in the calling application if they contain spaces and only then append the quotation marks around the names.
But is there another solution?

I created a little batch file that would display the command line parameters. With your first command line, I get
1 -p
2 -z
3 "E:\temp.zip"
4 -v
5 "f:\"
6 -r
7 -o
8 -s
9 –c
as it should. If .NET parses it differently, that would be a major bug. Just to check, I created a test console app. The results were:
0 -p
1 -z
2 E:\temp.zip
3 -v
4 f:" -r -o -s -c
I didn't think that was possible! So I researched a little and I got to this link: Everyone quotes command line arguments the wrong way which explains why the command line parser is essentially flawed. (I know it's for C++, but it applies) which led me to the rules of parsing for command line parameters which says \" is interpreted as an escaped quote, as opposed to how the operating system sees it (which is gross).
Conclusion: if you want to fix the command line, you need to escape the slash before a quote so instead of "f:\" you need "f:\\". The other solution is to use Environment.CommandLine which gets you the entire command line, executable included, and you can parse it yourself. More on this here: Getting raw (unsplit) command line in .NET.
Just for completeness' sake, I'll throw this in: Split string containing command-line parameters into string[] in C#, which discusses how to split a command line string into parameters using system functions.
After some more research, I realized that there are several standards
of command line argument parsing, depending on compiler and operating
system and its version, and that the only way to be consistent is to
parse the raw command line yourself.
For example, using CommandLineToArgvW on Environment.CommandLine replicated exactly a call to Environment.GetCommandLineArgs() which returns the exact same thing as the args array given to the Main method.
I found a very detailed page about this problem: http://daviddeley.com/autohotkey/parameters/parameters.htm which I believe is the definitive answer to the general question of command line parsing.

C# run Powershell script async

I'm trying to run a powershell script using the following method:
> PowerShellInstance.AddScript(
> #"write-output balls;Start-Sleep -s 2;write-output balls;Start-Sleep -s 2;write-output balls;Start-Sleep -s 2");
This works fine, however the following does not. Any ideas?
PowerShellInstance.AddScript(
#"c:\folder\script.ps1");

This is why...
PowerShellInstance.AddScript(
#"& ""c:\folder\script.ps1""");

Having some trouble executing "svn log" with Process.Start() in LINQPad

Process.Start("svn.exe", "log c:\\work\\lidac\\v1\\ -r {2014-09-01}:{2014-09-24} --xml > c:\\work\\commits.xml");
SVN is throwing an error over the >
Error resolving case of >
I am not sure why. The same command works if I type it directly into the command prompt. Any ideas?

You are passing that redirect output symbol to the svn.exe process. He doesn't understand what > c:\work\commits.xml means. If you want to do the redirect output to a file, you can either write code to get the output from the process object, or try something like:
Process.Start("cmd.exe", #"/C svn log C:\work\lidac\v1\ -r {2014-09-01}:{2014-09-24} --xml > c:\work\commits.xml");