Broken syntax highlighting for .fsproj files

[SchlenkR]

When I have Ionide enabled and I open a .fsproj file, it looks basically like this:

Same with Dir.Build.props:

Having Ionide disabled, it looks like:

and

Please also note that the file icons in the tab (for Dir.Build.props) changes.

Thank you :)

[baronfel]

We set the language of those files to 'MSBuild' so that tooling and extensions like the TinToy MSBuild service would 'light up'. You can change those files back to ' xml' language if you wish, but I'd personally install TinToy and use it's features.

[SchlenkR]

Thanks for the answer - I didn't know that.

• shall I close the issue then?
• Would it make sense and be possible to let Ionide pop up a recommendation for TinToy in VSCode, so that others will be informed, too?

[baronfel]

I wouldn't encourage Ionide to pop up notifications - VSCode extensions already clutter the notifications area unnecessarily.

I could be convinced to add this extension to our extensionPacks metadata - that would auto-install the extension at the same time that Ionide was installed. What are your thoughts on that? As a user would you be irritated if we installed other extensions? We currently have a hard dependency on the C# extension, but we're about to break that...

[SchlenkR]

As a user would you be irritated if we installed other extensions?

In that case: Yes, I personally wouldn't want to have something like TinToy auto-installed, thus IMHO, it's not a hard dependency (meaning: most of Ionide works well without it), but more like an opinionated choice.

I'd expect to have at least the XML coloring (+ all other XML stuff) working when no other tool is installed. Is it possible to check (at every startup?) if a well-known extension like TinToy (or another) is installed, and conditionally register .fsproj? I also wouldn't expect that Ionide touches Directory.Build.props at all, since it's not an F# thing?

[MangelMaxime]

Directory.Build.props is kind of an extension of *.fsproj / *.csproj files so for me the answer is not as simple as a yes / no.

For example, because I work only with F# I consider Directory.Build.props to be an F# thing in my repositories.

I wouldn't encourage Ionide to pop up notifications - VSCode extensions already clutter the notifications area unnecessarily.

Indeed, there are a lot of notifications in VSCode. Instead of having a popup happening at startup which can create a lot of noise. What is your opinion if the notification was based on the context? What I mean is that if we detect the user opening an fsproj and not having TinToy we could propose choices to the user:

• Recommended: install TinToy
• Use XML
• Ignore and never ask again

[SchlenkR]

Nothing should be bound (to a language) if nothing is or can be provided. That sound like a misalignment. Therefor, I created the linked PR in TinToy; seems tobe the right place for binding .fsproj to MSBuild lang, and when it's merged, remove the binding from Ionide. What do you think?

[SchlenkR]

FYI - the fsproj extension will be bound by TinToy. Also, TinToy binds props files as far as I can see. Perhaps *.fsproj and Dir.Build.props extension binding could be removed from Ionide now, thus merging the responsibilities of registering an extension and provifing actually a working solution.

[davedawkins]

Thanks for the TinToy hint. Can Ionide only switch from XML to MSBUILD if it detects TinToy (maybe upon installation)? I admit I didn't check the docs ,I came straight to the issues to see who else might have logged an issue like this one