Publish fails when the output folder passed as argument has spaces

[Sridhar-MS]

ddcloud@ddsridhper028:~/cli/artifacts/ubuntu.14.04-x64/stage2/bin$ ./dotnet publish /home/ddcloud/cli/test/TestProjects/TestApp -o "/home/ddcloud/dir with spaces"
Specify --help for a list of available options and commands.
Microsoft.Dnx.Runtime.Common.CommandLine.CommandParsingException: Unrecognized command or argument 'with'
at Microsoft.Dnx.Runtime.Common.CommandLine.CommandLineApplication.HandleUnexpectedArg(CommandLineApplication command, String[] args, Int32 index, String argTypeName)
at Microsoft.Dnx.Runtime.Common.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.DotNet.Tools.Publish.Program.Main(String[] args)

[brthor]

Ran into this today resolving dotnet/cli#529

I think this is happening because when args are passed into a program string[] args, quoted parameters will be treated as one item in this array but with outer quotes stripped. These args then get forwarded by the driver to dotnet publish without the outer quotes, and are treated as separate args.

[brthor]

Some notes on the progress here.

This is more complex than just quoting args before forwarding them. There are a number of cases to consider. Args are processed before receiving them in our string[] args array in main. We need to make sure that the next process the driver forwards to receives the exact same string[] args. To do this we need to undo the processing which took place, or find a way to get the exact command line passed to this process from the system.

On Windows this processing takes place: https://msdn.microsoft.com/en-us/library/17w5ykft.aspx
Discussion and solution to this problem (Windows Only) here: http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx

Working through this problem revealed some inconsistencies between System.Diagnostics.Process handling of args between Windows and Linux.

Tracked here: https://github.com/dotnet/corefx/issues/5348

[NickCraver]

Is this resolved by dotnet/corefx#5369? I just hit it with the latest installer posted but it looks like the fix landed after that was last updated, is that accurate?

[brthor]

This issue is still open to track changes required in the CLI. Changes are on the way.

dotnet/corefx#5369 was an associated blocking issue.

[NickCraver]

@brthor gotcha, thanks! Might I suggest putting this on the known issues list since it affects everyone using the installer with default options? I'd call this one pretty impactful until the installer is updated.

[brthor]

cc @blackdwarf

[brthor]

Fixed via dotnet/cli#985