Remove "workspaceContains:**/*.sln" from activation events?

[JustinGrote]

Starting here before I file issue/PR.

I think .sln should not be in the activation events. If I open a C# project I don't want all of Ionide loading just because I have a .sln in there. .fs/.fsx/.fsproj is enough.

[baronfel]

This has been discussed a few times in the past:

• Remove .sln from activation event #1401
• ionide creates an .ionide directory when not loading F# projects or files #1041 (comment)

To some extent this is a bit of a philosophical argument: sln is a .Net extension, and so us removing it seems like some sort of admission/yielding of turf to C# projects. It's just as reasonably an F# file type as well.

[cartermp]

I thought about this a bit and I'm now on team "yield this to C# and be done with it".

If there's a .sln but no .fsproj, .fs, .fsx, etc. -- then there's no reason for anyone to want the F# extension to load if it's not been loaded. This would be fine if it weren't for creating the .ionide cache.

It's one of those problems that isn't actually a real problem, but people get annoyed with it enough that it's better to not give them a reason to be loud about it.

[baronfel]

Personally I'm more and more tending to agree with you, but I also would like to remove the hard dependency on the c# extension overall. It causes a lot of startup issues seemingly, and we call out in the readme first thing that if you want debugging you have to install it separately.

[cartermp]

Yeah, that's a good point. I think they two points should be considered separately, but the debugging issue has precedent (or at least used to) - if you want to debug shit in JS, you need to install another extension.

[JustinGrote]

The reality is it's far more annoying to open a C# (or other non-F# .sln based project) and have those temp files and extra startup show up and have to update my .gitignore to accomodate F# than it is the weird chance I might open a project with a .sln but no F# files and have the extension not load (to which I can run any command to then initialize F# as an easy workaround).

I'm selectively disabling the F# extension for workspaces anyways, which compeltely defeats the point of the activatation events to selectively enable only when I'm working on F# something.

[smcl]

I didn't see this discussion before. @Krzysztof-Cieslak just closed my issue (#1701) without really addressing the question in hand and I'm a bit puzzled. There are a few of us who are asking why Ionide needs to activate on projects that have nothing to do with F# or even .NET. This seems like a no-brainer to me, but he doesn't seem to want to even give an explanation even if it's a totally subjective one like "I don't feel like doing this" or "C# sucks". At least that way I'd know the only way is to fork and create an extension called "Ionide for F# (fixed)".

The frustrating thing is that this is hampering adoption of F# in a very slight way. In my organization there is tenative interest in F# but we're very much married to C# right now and need to present a very clear case why F# should get a foothold. VS Code with Ionide is good for F#, but if I have to keep explaining to people who work with our existing C# projects why a .ionide folder keeps appearing, why the F# Solution Explorer pops up when it shouldn't or why the Ionide plugin nags you to add F# stuff to your .gitignore on then the F# proposition starts to look like a hacky mess and I lose support.

I want to use Ionide more, this issue is such a tiny and seemingly easy fix. At least communicate something to us, @Krzysztof-Cieslak :) Sorry for tagging you a couple of places, I really love the work you've done on Ionide for F#, but this teeny tiny change could make our lives better and I think helps in a very small way to push F# to a wider audience :)

[JustinGrote]

Seems pretty much like a no-brainer, and I don't think the C# extension should load on SLN files either. csproj and cs should load C#, fsproj and fs should load Ionide, unless someone can give me an example of a project where you only have a SLN file, nothing else, and yet need the extension to load for some bizarre reason (even then it's probably a very ignorable edge case).

There is a performance cost to loading the F# extension, and this is so annoying that I am now disabling it by default and selectively enabling it in workspaces as needed, so if the reasoning is not "losing ground to c#" I hate to break it to you but you're now already losing that battle simply because I'm now not enabling it by default because of this unreasonable behavior.

[smcl]

if the reasoning is not "losing ground to c#"

Ouch yeah I find myself turning it off too, and as I said it kinda hurts to have to explain to someone "yeah there's this extension you need, and it is fantastic but you have to twiddle with it a bit" :( But I think another problem is that we don't really know if that is the reasoning. It's now been mentioned across 3 or 4 issues now, to the point where anyone who cares knows the technical reason why it behaves this way ... but we don't ever here any good reason for it continuing to be this way.

Ionide could be a seamless, excellent stepping stone for VS/C#-only shops to become hybrid VSCode/F#/C# and VS/C# operations (and potentially VSCode/F# only?) ... but this sorta halts that :-/