#r/#load is only allowed in scripts.

[cameronsjo]

I get the following error messages in VS Code when I have csx script files opened.

Environment data

dotnet --info output:

bash-3.2$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

VS Code version: 1.9.1
C# Extension version: 1.7.0

[filipw]

Thanks for the report. These are diagnostics 7011 and 8097 which are raised only when a CSX file is attempted to be treated as regular source code.

Do you by any chance try to include the CSX files in the same compilation as regular CS files (i.e. made them part of the csproj file)?
Perhaps you can provide some repro project?

[cameronsjo]

Here's a repro repo: https://github.com/cameron-sjo/VSCodeRepro.

I found out that if I have OmniSharp switch project to an individual project.json via the Switch Projects button in the bottom left corner of VS Code, a bunch of (false-positive) errors show up. However, if I change it to be the root directory/repo then it resolves the #r and #load errors.

There's still a few other issues because I assume OmniSharp isn't taking the into account the different dependencies from #r or #load compiler directives.

[filipw]

Thanks. So there a few things here.

1. The main error (diagnostics 7011 and 8097) you showed on the screenshot should be resolved in the latest beta already (I can't reproduce it anymore) installation instructions
2. You mention you are on Mac OS X, but your sample project uses Windows path delimiters - this will not work on OS X; instead of #load "..\Shared\ConnectionStrings.csx" you should be saying #load "../Shared/ConnectionStrings.csx"
3. Now the real issue: The CSX you are trying edit is not a "standard" CSX but Azure Functions. At the moment VS Code C# Extension and OmniSharp only supports stand alone CSX files and don't really support Azure Functions development. The reason is the Azure Functions runtime injects a bunch of its own implicit dependencies (such as Microsoft.WindowsAzure.Storage or Microsoft.ServiceBus and so on) as well as it's own set of using statements, which OmniSharp doesn't know how to resolve (to do so, it would have to "imitate" the Azure Functions runtime). This is the main reason for the errors you are seeing.

I think supporting Azure Functions is a good idea but it would have to be developed as an extra feature on top of the exist CSX supporting OmniSharp. It shouldn't be too difficult to do, and would add some nice value, the biggest challenge would be how to distinguish that this CSX is Azure Functions but that other CSX is not.

[cameronsjo]

1. Awesome :)
2. Hmm. That makes sense. I don't think that's something I can change because Azure Functions run on a Windows platform. Thanks for pointing that out.
3. Makes sense. I thought I mentioned in my original issue that I was using Azure Functions, but I guess I removed it when I proofread.

I can't think of a way to detect whether or not it's an Azure Function CSX vs a normal CSX. My best idea would be to check for a *.funproj, but that's hacky at best.

Thanks for your response!

[cameronsjo]

@filipw Should we close this issue?

[filipw]

I think this can be closed, let's open one in https://github.com/OmniSharp/omnisharp-roslyn for adding support for Azure Functions Development