Add activation events for *.csproj and *.sln

[DustinCampbell]

Should fix #1375 and improve #1150.

[DustinCampbell]

cc @eamodio

[filipw]

can we also add *.csx?
it's already included as a launch target https://github.com/OmniSharp/omnisharp-vscode/blob/dd8c7e188e6025b6ba9f0302f5474ab067a4eb8e/src/omnisharp/launcher.ts#L48 and https://github.com/OmniSharp/omnisharp-vscode/blob/dd8c7e188e6025b6ba9f0302f5474ab067a4eb8e/src/features/status.ts#L30

[DustinCampbell]

Is this actually a problem for *.csx? Note that the extension already activates on *.csx files when they're opened because that's how the "csharp" language is defined in VS Code (link).

Note I'm not adding *.cs because that seems a bit too invasive. Could you explain how *.csx would be different.

[DustinCampbell]

Note I'm not adding *.cs because that seems a bit too invasive.

I'm totally willing to discuss this bit. That's my first gut feeling, but I'm not 100% certain it's something I should be concerned about. I definitely wouldn't want to add **/*.cs because a random C# file somewhere in a subfolder could cause OmniSharp to launch. However, if there's a .cs file in the root?

[filipw]

I think csx case would be different than cs, because csx is a de facto project file - either as a fully self contained app or as an entry point that may contain references to other csx files (so other compilation items) as well as assembly references.

A standalone cs file could indeed have no meaning if it doesn't have a project file, as it would not know how to compile itself (plus, Omnisharp wouldn't even know how to treat such loose cs files). OTOH, a loose csx file (or a bunch of them) is always a valid start point for the server, and we can always provide proper language services.

It would be nice to open a folder with some csx scripts in there and have Omnisharp light up immediately so that:

• you avoid the little delay to start the server when a csx is actually open
• you can immediately do things like i.e. go to definition

[DustinCampbell]

you can immediately do things like i.e. go to definition

How does this help that? After all, you have to have a file open to go to definition, no?

[filipw]

sorry, I meant "go to symbol"

[DustinCampbell]

I suppose that's true. OK. I'll add *.csx as well. I still think *.cs is too much though. Do you disagree?

[filipw]

no, I think you right about that 👍
thanks!

[eamodio]

@DustinCampbell
I'm not 100% sure, but should those be workspaceContains:**/*.csproj so that it could be in any folder? It may already be handled though

[DustinCampbell]

I intentionally didn't do that but I'm open to discussing it. I feared that this might be a bit invasive.

[eamodio]

Ah -- personally I would definitely want that. We typically open vscode to the root of the repository, and it doesn't have any projects or anything in it -- they are all nested under sub-folders. What are the cases you are thinking about where you wouldn't want that behavior?

[DustinCampbell]

I was thinking of scenarios like the one described by #1328.

[DustinCampbell]

OK. I've added patterns for *.csx and globs to search subfolders. I'm planning to ship 1.11 shortly and would like to hold this change for 1.12 to let folks play with it to ensure it feels good. Does that work for everybody?

[filipw]

sounds like a plan 👍

[DustinCampbell]

OK. I'm going to go ahead and merge this for 1.12.