VSCode Extension should provide better experience for users without MSBuild

[swernli]

See related discussion at https://github.com/microsoft/qsharp-compiler/issues/1235#issuecomment-1029532735.

Without MSBuild, the Language Server cannot load dependencies and falls back to syntactic-only features. We should explore some of the options listed in the linked comment to see how/if we can provide a better experience for users who do not want to install full VS or the .NET SDK (such as those using Q# via conda packages). If none of the options are viable and a hard dependency on manually installing MSBuild into the environment can't be avoided, we need to update the corresponding documentation and error/warning messages from the extension to make this requirement more clear.

@cgranade, @ricardo-espinoza FYI.

[cgranade]

Thanks for tagging me on this and the original discussion, @swernli! Agreed, it would be good to make sure that the VS Code extension works well or at least degrades gracefully for Q# + Python users making use of the conda package installation workflow instead of pip + dotnet. In particular, such users may not have either the dotnet or msbuild commands available, much less on $PATH. This also makes the self-contained deployment used by the VS Code extension somewhat less useful, since the self-contained exe then looks for dotnet.

I think including the approaches you listed at https://github.com/microsoft/qsharp-compiler/issues/1235#issuecomment-1029532735, I can see a few possible paths forward:

• Require dotnet for any use of the VS Code extension. This would mean that our conda packages work and work well for workflows like Jupyter Notebook, but would not on their own be usable for Q# + Python applications developed outside of a notebook interface. We would need to update docs accordingly, and would likely want to clarify error messages to be more actionable for users.
• Support a basic (no project) workflow when dotnet is missing. This would require removing or clarifying error messages in the VS Code extension, and updating docs to indicate that using conda packages for Q# + Python use in IDEs is only partially supported.
• Refactor the language server to not require MSBuild. I don't imagine this is all that feasible, but wanted to list it at least for the sake of completeness.
• Include dotnet or required MSBuild components in the iqsharp conda package. This may technically works, but requires us to own a complex packaging workflow, and makes the already large iqsharp conda package much, much larger.
• Depend on the dotnet conda-forge package. By policy, we can't directly do this from a package hosted on the microsoft anaconda.org channel, but we may at least be able to document that users looking for IDE support can use conda install -c microsoft -c conda-forge qsharp dotnet. Taking this option would also require adapting the VS Code extension to search conda environments for a suitable dotnet command, since Code is not generally launched with conda activated and on its $PATH.
• Suggest publishing a dotnet package to an appropriate anaconda.org channel. We couldn't do this one directly, but we could suggest that the .NET team publish a conda package that we can take a dependency on from the iqsharp package.
• Modify the VS Code extension to download MSBuild if it is missing. This approach follows that used by the C# / OmniSharp extension, and has the advantage that it doesn't increase conda package sizes for non-IDE workflows. To follow this, we would have to adapt the extension itself to detect if MSBuild is installed, and would have to adapt the language server to look for MSBuild where the extension downloads it.