Project-system: LanguageServiceHost is not correctly resolving reference paths

[davkean]

1. Compile this via command-line and then open in VS

``` C#
using System;
using Accessibility;

namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}

``` XML
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AdditionalLibPaths>c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp262\ConsoleApp262\obj\Debug</AdditionalLibPaths>
  </PropertyGroup>

  <ItemGroup>
    <ReferencePath Include="Interop.Accessibility.dll" />
  </ItemGroup>

</Project>

Expected: For it to be successfully compiled in both
Actual: Command-line compiles sucessfully, IntelliSense filter shows:

Severity    Code    Description Project File    Line    Suppression State
Error   CS0246  The type or namespace name 'Accessibility' could not be found (are you missing a using directive or an assembly reference?) ConsoleApp1 c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp262\ConsoleApp1\Program.cs 2   Active

[davkean]

Make note that we're also not reporting "bad references" like the compiler:

Severity Code Description Project File Line Suppression State Error CS0006 Metadata file 'Interop.Accessibility.dll' could not be found ConsoleApp1 c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp262\ConsoleApp1\CSC 1 Active Warning CS1668 Invalid search path 'c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp262\ConsoleApp262\obj\Debuged' specified in '/LIB option' -- 'directory does not exist' ConsoleApp1 c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp262\ConsoleApp1\CSC 1

[davkean]

We're making the assumption that all relative paths should be resolved via the project directory - this is not correct. We should be using the same resolver that the command-line uses to resolve

[Pilchie]

Moving to 15.7 - this feels like something we should fix when changing the API with Roslyn, so that they can resolve relative paths.

Tag @jasonmalinowski

[davkean]

I agree. All consumers of the IWorkspaceProjectContext need to basically mimic command-line resolving - this is something that should be done on the language services side.

[jasonmalinowski]

Fully agree with the intent here, but this did surprise me:

We're making the assumption that all relative paths should be resolved via the project directory - this is not correct. We should be using the same resolver that the command-line uses to resolve

That _isn't_ what it does? @tmat or @jaredpar are there dragons here I need to know about? If we move the command line handling to the language service and it depends on more than project directory we'll need to know what that is.

[jaredpar]

If we move the command line handling to the language service and it depends on more than project directory we'll need to know what that is.

The command line resolution doesn't consider the project directory. Instead it uses the sdk directory (directory containing mscorlib) and directories specified via libpath.

[davkean]

<Reference/> items themselves are resolved in relation to the project directory via RAR, however, notice above I'm not using items - I'm directly setting "resolved" <Reference/> via <ReferencePath/> which are directly passed on the compiler.

The other thing that should happen is that you should get the same errors that the command-line compile produces around references. We get so much feedback around how VS/Build+IntelliSense mode has different behavior than command-line/build mode.

[jasonmalinowski]

I guess there's three layers here, really:

1. How a relative Reference path is resolved by RAR.
2. How a relative ReferencePath is processed by the build task. I presume that follows MSBuild convention where it's relative to the project file?
3. How a relative path is handled by csc.exe.

From my perspective I'm already downstream of 1 and 2, I just need to make sure I have all the inputs to 3.