dotnet / project-system

The .NET Project System for Visual Studio
MIT License
968 stars 387 forks source link

LanguageServiceHost is not correctly resolving reference paths #1872

Open davkean opened 7 years ago

davkean commented 7 years ago
  1. Compile this via command-line and then open in VS
using System;
using Accessibility;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}
<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 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

<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 commented 6 years ago

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.