Extra " (or \?) in VisualBasicCommandLineParser.FindFileInSdkPath, causing Sdk file not found

[KirillOsenkov]

Version Used: 1.03.1.60621 (https://www.nuget.org/packages/Microsoft.CodeAnalysis/1.3.2)

Steps to Reproduce:

1. Use MSBuildWorkspace on Roslyn.sln itself
2. When loading F:\SourcesToIndex\Roslyn\Open\src\Scripting\VisualBasic\BasicScripting.vbproj, there is an ArgumentException ("Illegal characters in path") with the stack below.

    mscorlib.dll!System.IO.Path.CheckInvalidPathChars(string path, bool checkAdditional) Line 1238  C#
    mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck, int maxPathLength, bool expandShortPaths) Line 377   C#
    mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck, int maxPathLength) Line 357  C#
    mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck) Line 342 C#
    mscorlib.dll!System.IO.Path.GetFullPathInternal(string path) Line 333   C#
    mscorlib.dll!System.IO.File.InternalExistsHelper(string path, bool checkHost) Line 425  C#
    mscorlib.dll!System.IO.File.Exists(string path) Line 402    C#
    Microsoft.CodeAnalysis.VisualBasic.dll!Microsoft.CodeAnalysis.VisualBasic.VisualBasicCommandLineParser.FindFileInSdkPath(System.Collections.Generic.List(Of String) sdkPaths, String fileName, String baseDirectory) Line 1388  Basic
    Microsoft.CodeAnalysis.VisualBasic.dll!Microsoft.CodeAnalysis.VisualBasic.VisualBasicCommandLineParser.LoadCoreLibraryReference(System.Collections.Generic.List(Of String) sdkPaths, String baseDirectory) Line 1349    Basic
    Microsoft.CodeAnalysis.VisualBasic.dll!Microsoft.CodeAnalysis.VisualBasic.VisualBasicCommandLineParser.Parse(System.Collections.Generic.IEnumerable(Of String) args, String baseDirectory, String sdkDirectory, String additionalReferenceDirectories) Line 1156    Basic
    Microsoft.CodeAnalysis.VisualBasic.Workspaces.dll!Microsoft.CodeAnalysis.VisualBasic.VisualBasicCommandLineArgumentsFactoryService.Parse(System.Collections.Generic.IEnumerable(Of String) arguments, String baseDirectory, Boolean isInteractive, String sdkDirectory) Line 27 Basic
>   Microsoft.CodeAnalysis.Workspaces.Desktop.dll!Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.LoadProjectAsync(string projectFilePath, Microsoft.CodeAnalysis.MSBuild.IProjectFileLoader loader, bool preferMetadata, Microsoft.CodeAnalysis.MSBuild.MSBuildProjectLoader.LoadState loadedProjects, System.Threading.CancellationToken cancellationToken) Line 354  C#

This is because in this frame the path contains an extra quote (somehow it's there instead of a backslash?):

The full command line /sdkpath switch the command line parser is parsing:

/sdkpath:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\"

Note the slash at the end. When the sdkDirectory ends up in sdkPaths, magically the end backslash is replaced with a quote?

[KirillOsenkov]

The end path we're trying to find is:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319"\System.Runtime.dll <- note the quote.

[KirillOsenkov]

Actually I think the bug might be here:
http://source.roslyn.io/#Microsoft.CodeAnalysis/CommandLine/CommonCommandLineParser.cs,d879e6c78cb7fac0
Parsing /sdkpath:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\" probably doesn't split the trailing quote.

[AdamSpeight2008]

@KirillOsenkov
Could you provide a link (or paste in this issue) to the section, where the arguments are passed.
So I (we) can check. As I also think there is an error, as that code presumes the C# escaped quote not the VB one. "". This would require a better algorithm to be used.

[gafter]

@jaredpar I suspect this may be related to some recent work you've done to fix related issues in the C# command-line parser.

[jaredpar]

Parsing /sdkpath:"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" probably doesn't split the trailing quote.

Have you checked to see if this behavior is present in the native compiler as well?

Roslyn RTM did not due the necessary amount of rigor when it came to maintaining compatibility with the native compiler around command line argument parsing. Post RTM I ported the native compiler solution to managed code and verified that we maintained compatibility with a number of odd scenarios that came up. This rule in particular was one I remember porting.

[jaredpar]

Closing as this appears to be By Design now (or by design mandated by native compat 😦 )