Open davkean opened 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 ```
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
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
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.
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.
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.
<Reference/>
items themselves are resolved in relation to the project directory via RAR, however, notice above I'm not using <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.
I guess there's three layers here, really:
From my perspective I'm already downstream of 1 and 2, I just need to make sure I have all the inputs to 3.
Expected: For it to be successfully compiled in both Actual: Command-line compiles sucessfully, IntelliSense filter shows: