C# extension v2.x introduces new file language association, which breaks several things

[DoctorKrolic]

In C# extension version 1.x .csproj files were classified as xml files. I believe, this is default behaviour, and extension didn't change it. However, starting with versions 2.x .csproj files are now classified as dotnetProject, which breaks several things:

1. Default colorization for xml was good enough, but now it is completely gone:
   Before:
   
   After:
   
2. This breaks existing extensions, that provide intellisense for MSBuild files, e.g. https://marketplace.visualstudio.com/items?itemName=tintoy.msbuild-project-tools relies on msbuild association.

So if it is possible, please revert to previous behaviour for better compatability. If such move is not possible/too complicated to do at least bring back xml syntax colorization

[333fred]

@arkalyanms I think this needs to be addressed before GA.

[arunchndr]

@WardenGnaw would you take a look? The association seems to come from 173be18

[WardenGnaw]

Yep. This was added so we can support F5 in a .sln and .csproj

There are two ways to fix this:

1. Enable the coreclr debug engine to work on all xml file types.
2. Port over the xml grammer to the dotnetProject language.

[333fred]

1 sounds like what we need to do. 2 would still leave xml-based extensions (such as tag completion and synchronization) broken.

[timheuer]

1. Enable the coreclr debug engine to work on all xml file types.

Agree with @333fred here that 2 seems bad. But associating a debugger with all xml types seems equally overkill. What is lost here in somehow mapping to the file extension instead rather than some mime-type? Can't we do an if (xml && .csproj) combo instead? (with obviously a better if check ;-))

[WardenGnaw]

1. Enable the coreclr debug engine to work on all xml file types.

Agree with @333fred here that 2 seems bad. But associating a debugger with all xml types seems equally overkill. What is lost here in somehow mapping to the file extension instead rather than some mime-type? Can't we do an if (xml && .csproj) combo instead? (with obviously a better if check ;-))

Yep. Reverting 173be18 maybe the best solution for now and the workaround would be to select a .cs file to start debugging instead of your .csproj or .sln.

Debugging is heavily tied to a language instead of file type for now. I will work with the VS Code team to see if we can get that resolved but maybe require a newer vscode version past GA.

[gaelj]

This issue also breaks version lens, which is a deal-breaker to me